Security Context, Contrôler les permissions des Pods

Le Security Context définit les privilèges et restrictions d'exécution pour vos Pods et conteneurs. Il contrôle l'identité d'exécution, les capabilities Linux, l'accès au système de fichiers et les restrictions de privilèges. C'est votre outil principal pour appliquer le principe du moindre privilège au niveau des workloads Kubernetes.

Une précision avant d'entrer dans les réglages : le Security Context définit un cadre de privilèges d'exécution, il ne sécurise pas un Pod à lui seul. Il suppose une image adaptée, qui accepte un UID arbitraire et ne lance pas de processus root en interne, des volumes compatibles avec fsGroup, un ServiceAccount correctement restreint, des NetworkPolicies pour l'isolation réseau et des Pod Security Standards appliqués au namespace. Chacun de ces points fait l'objet d'une leçon de ce parcours.

Ce guide couvre les paramètres essentiels pour la CKAD et les bonnes pratiques de production.

Ce que vous allez apprendre

• Ce qu'est un Security Context et où il s'applique (Pod vs conteneur)
• Contrôler l'identité d'exécution avec runAsUser, runAsGroup, runAsNonRoot, supplementalGroups
• Gérer les capabilities Linux (add/drop)
• Protéger le filesystem avec readOnlyRootFilesystem et fsGroup
• Bloquer l'escalade de privilèges avec allowPrivilegeEscalation

Qu'est-ce qu'un Security Context ?

Un Security Context est un ensemble de paramètres de sécurité qui définissent les privilèges et restrictions d'un Pod ou d'un conteneur :

Ce que ça contrôle	Exemples de paramètres
Identité d'exécution	runAsUser, runAsGroup, runAsNonRoot, supplementalGroups
Capabilities Linux	capabilities.add, capabilities.drop
Accès filesystem	readOnlyRootFilesystem, fsGroup
Escalade de privilèges	allowPrivilegeEscalation, privileged
Profils de sécurité	seccompProfile, seLinuxOptions, procMount

Glissez pour voir

Ces paramètres se posent à deux endroits, et la distinction gouverne tout le reste : spec.securityContext s'applique à tous les conteneurs du Pod, spec.containers[].securityContext à un seul, dont il redéfinit les valeurs.

Pod Security Context vs Container Security Context

Les deux niveaux ne portent pas les mêmes paramètres. fsGroup et supplementalGroups n'existent qu'au niveau Pod ; capabilities, readOnlyRootFilesystem, allowPrivilegeEscalation et privileged n'existent qu'au niveau conteneur. Seuls runAsUser, runAsGroup, runAsNonRoot et les profils de sécurité acceptent les deux emplacements. Le manifeste ci-dessous montre les deux blocs côte à côte, disposition la plus courante en production.

apiVersion: v1
kind: Pod
metadata:
  name: security-demo
spec:
  # ─── Security Context au niveau POD ───
  securityContext:
    runAsUser: 1000           # UID pour tous les conteneurs
    runAsGroup: 3000          # GID pour tous les conteneurs
    fsGroup: 2000             # GID pour les volumes montés
    supplementalGroups:       # Groupes secondaires
      - 4000
      - 5000

  containers:
  - name: app
    image: nginx:1.28@sha256:146adea4768b83c607d0bdfa4188464e3da6e0a3ad4475db1d1d8f64f27c29cc
    # ─── Security Context au niveau CONTENEUR ───
    securityContext:
      runAsNonRoot: true              # Refuse démarrage si root
      readOnlyRootFilesystem: true    # Filesystem en lecture seule
      allowPrivilegeEscalation: false # Bloque setuid/setgid
      capabilities:
        drop:
          - ALL
        add:
          - NET_BIND_SERVICE

Règle de priorité

Quand un paramètre est présent aux deux endroits, c'est toujours le plus proche du processus qui l'emporte. Le niveau Pod joue donc le rôle de valeur par défaut, que chaque conteneur peut redéfinir pour lui seul.

Paramètre défini au niveau...	Comportement
Pod uniquement	S'applique à tous les conteneurs
Conteneur uniquement	S'applique à ce conteneur
Pod ET conteneur	La valeur du conteneur écrase celle du Pod

Glissez pour voir

La répartition qui fonctionne en pratique découle de cette règle : les paramètres communs au niveau Pod, runAsUser, fsGroup et supplementalGroups, et les paramètres propres à un conteneur au niveau conteneur, capabilities et readOnlyRootFilesystem. Un sidecar a rarement besoin des mêmes capabilities que l'application qu'il accompagne.

Contrôler l'identité d'exécution

L'identité d'exécution répond à une seule question : sous quel UID et quel GID le processus tourne-t-il une fois le conteneur démarré ? Sans réglage, c'est l'utilisateur déclaré par l'instruction USER de l'image, et si l'image n'en déclare aucun, c'est root. Les paramètres qui suivent permettent d'imposer cette identité depuis le manifeste, sans avoir à reconstruire l'image.

runAsUser et runAsGroup

Ces paramètres définissent l'UID et le GID sous lesquels le processus principal du conteneur s'exécute :

apiVersion: v1
kind: Pod
metadata:
  name: user-demo
spec:
  securityContext:
    runAsUser: 1000     # UID 1000 (non-root)
    runAsGroup: 3000    # GID 3000
  containers:
  - name: app
    image: busybox:1.36@sha256:73aaf090f3d85aa34ee199857f03fa3a95c8ede2ffd4cc2cdb5b94e566b11662
    command: ["sh", "-c", "id && sleep 3600"]

Vérification :

kubectl apply -f user-demo.yaml
kubectl logs user-demo
# uid=1000 gid=3000 groups=3000

runAsNonRoot

Ce paramètre demande à Kubernetes de refuser le démarrage si le conteneur s'exécuterait en root :

spec:
  containers:
  - name: app
    image: nginx:1.28@sha256:146adea4768b83c607d0bdfa4188464e3da6e0a3ad4475db1d1d8f64f27c29cc
    securityContext:
      runAsNonRoot: true

Validation plus stricte qu'elle n'y paraît

runAsNonRoot: true ne fait pas simplement un test "UID != 0". Kubernetes vérifie que :

1. L'image définit un utilisateur non-root dans son USER Dockerfile, OU
2. Le Pod spécifie explicitement un runAsUser non-root

Si Kubernetes ne peut pas valider qu'un utilisateur non-root sera effectivement utilisé, le conteneur ne démarre pas :

Error: container has runAsNonRoot and image will run as root

Solution : Ajoutez runAsUser: 1000 explicitement, ou utilisez une image qui définit un USER non-root.

supplementalGroups

Ce paramètre définit les groupes secondaires ajoutés à tous les processus des conteneurs du Pod :

apiVersion: v1
kind: Pod
metadata:
  name: groups-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 1000
    supplementalGroups:
      - 4000  # Groupe pour accéder à certains fichiers
      - 5000  # Groupe pour accéder à d'autres ressources
  containers:
  - name: app
    image: busybox:1.36@sha256:73aaf090f3d85aa34ee199857f03fa3a95c8ede2ffd4cc2cdb5b94e566b11662
    command: ["sh", "-c", "id && sleep 3600"]

Vérification :

kubectl logs groups-demo
# uid=1000 gid=1000 groups=1000,4000,5000

Paramètre	Rôle
runAsGroup	Groupe principal du processus
fsGroup	Groupe propriétaire des volumes montés
supplementalGroups	Groupes secondaires du processus

Glissez pour voir

Exemple complet identité

Ce manifeste réunit les trois paramètres précédents et y ajoute le blocage de l'escalade de privilèges. C'est le socle minimal attendu sur une charge de travail de production.

apiVersion: v1
kind: Pod
metadata:
  name: secure-user
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 1000
    runAsNonRoot: true
    supplementalGroups: [4000]
  containers:
  - name: app
    image: nginx:1.28@sha256:146adea4768b83c607d0bdfa4188464e3da6e0a3ad4475db1d1d8f64f27c29cc
    securityContext:
      allowPrivilegeEscalation: false

Protéger le filesystem et les volumes

Un conteneur dispose par défaut d'un système de fichiers racine inscriptible. Il est effacé à chaque redémarrage, mais bien réel entre-temps : un attaquant peut y déposer un binaire ou modifier une configuration. Les deux paramètres suivants traitent des problèmes distincts, readOnlyRootFilesystem verrouillant cette racine tandis que fsGroup règle l'accès aux volumes montés, qui restent, eux, inscriptibles.

readOnlyRootFilesystem

Ce paramètre rend le système de fichiers racine du conteneur en lecture seule :

apiVersion: v1
kind: Pod
metadata:
  name: readonly-demo
spec:
  containers:
  - name: app
    image: nginx:1.28@sha256:146adea4768b83c607d0bdfa4188464e3da6e0a3ad4475db1d1d8f64f27c29cc
    securityContext:
      readOnlyRootFilesystem: true
    volumeMounts:
    - name: tmp
      mountPath: /tmp
    - name: cache
      mountPath: /var/cache/nginx
    - name: run
      mountPath: /var/run
  volumes:
  - name: tmp
    emptyDir: {}
  - name: cache
    emptyDir: {}
  - name: run
    emptyDir: {}

Toutes les images ne supportent pas readOnly

Avec readOnlyRootFilesystem: true, l'application ne peut plus écrire nulle part sauf dans les volumes montés. Problèmes courants :

• L'image écrit des logs dans /var/log
• L'image crée des fichiers temporaires ailleurs que /tmp
• L'image stocke des PID files dans des dossiers non montés

Testez toujours le comportement réel de l'image avant de l'utiliser en production avec ce paramètre.

fsGroup

Le paramètre fsGroup définit le GID propriétaire des volumes montés :

apiVersion: v1
kind: Pod
metadata:
  name: fsgroup-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 1000
    fsGroup: 2000      # Les fichiers des volumes appartiennent au groupe 2000
  containers:
  - name: app
    image: busybox:1.36@sha256:73aaf090f3d85aa34ee199857f03fa3a95c8ede2ffd4cc2cdb5b94e566b11662
    command: ["sh", "-c", "ls -la /data && sleep 3600"]
    volumeMounts:
    - name: data
      mountPath: /data
  volumes:
  - name: data
    emptyDir: {}

Vérification :

kubectl logs fsgroup-demo
# drwxrwsrwx 2 root 2000 4096 Mar 22 10:00 .

Le dossier /data appartient au groupe 2000, et le bit setgid (s) est activé.

Le mot important est compatibles : fsGroup ne s'applique pas de la même façon partout. Sur un emptyDir, il fonctionne comme décrit ci-dessus. Sur un hostPath, aucun changement de GID n'a lieu, les fichiers gardant le propriétaire qu'ils ont sur le nœud. Sur un volume CSI, tout dépend du driver, et sur NFS, de la configuration du serveur. Vérifiez donc le comportement réel sur vos volumes persistants avant de compter dessus : c'est une cause classique d'application qui démarre mais ne peut rien écrire.

Contrôler les privilèges

Les paramètres précédents désignaient qui exécute le processus. Ceux-ci définissent ce qu'il a le droit de faire une fois lancé. Trois leviers se combinent : le blocage de l'escalade de privilèges, la granularité des capabilities Linux, et le mode privileged qui annule à peu près tout le reste.

allowPrivilegeEscalation

Ce paramètre contrôle si un processus peut obtenir plus de privilèges que son parent (via setuid/setgid binaries) :

spec:
  containers:
  - name: app
    image: nginx:1.28@sha256:146adea4768b83c607d0bdfa4188464e3da6e0a3ad4475db1d1d8f64f27c29cc
    securityContext:
      allowPrivilegeEscalation: false

Ce réglage doit être posé explicitement : ne pas l'écrire ne revient pas à le mettre à false. Et il ne se remplace pas par autre chose, c'est le piège : capabilities.drop: [ALL] réduit bien les capabilities disponibles, mais un processus peut toujours tirer parti d'un binaire setuid tant que allowPrivilegeEscalation n'est pas à false. Les deux réglages traitent de problèmes différents et se posent tous les deux.

capabilities

Les capabilities sont des permissions granulaires qui remplacent le modèle binaire "root ou pas root". Au lieu de donner tous les droits root, vous accordez uniquement les capabilities nécessaires.

Capabilities courantes

Linux découpe les pouvoirs historiques de root en une quarantaine de capabilities indépendantes. Voici celles que vous croiserez le plus souvent dans un manifeste ; les deux dernières du tableau sont à traiter comme des signaux d'alerte lors d'une revue, car elles permettent de contourner les permissions de fichiers.

Capability	Ce qu'elle permet
NET_BIND_SERVICE	Écouter sur un port < 1024
NET_RAW	Créer des raw sockets (ping, tcpdump)
SYS_PTRACE	Tracer des processus (debug)
CHOWN	Changer le propriétaire des fichiers
SETUID / SETGID	Changer d'identité (escalade potentielle)
DAC_OVERRIDE	Ignorer les permissions de fichiers

Glissez pour voir

Drop ALL + add spécifique

La bonne pratique est de supprimer toutes les capabilities puis d'ajouter uniquement celles nécessaires :

apiVersion: v1
kind: Pod
metadata:
  name: cap-demo
spec:
  containers:
  - name: app
    image: nginx:1.28@sha256:146adea4768b83c607d0bdfa4188464e3da6e0a3ad4475db1d1d8f64f27c29cc
    securityContext:
      capabilities:
        drop:
          - ALL
        add:
          - NET_BIND_SERVICE  # Nginx écoute sur port 80

Vérification des capabilities actives :

kubectl exec -it cap-demo -- cat /proc/1/status | grep Cap
# CapPrm: 0000000000000400
# CapEff: 0000000000000400

La valeur hexadécimale ne se lit pas à l'œil. capsh la traduit :

capsh --decode=0000000000000400

Sortie

0x0000000000000400=cap_net_bind_service

Une mise en garde sur ce qu'un conteneur reçoit sans rien demander : les runtimes, Docker, containerd, CRI-O, accordent un jeu de capabilities par défaut dont la composition varie d'un runtime et d'une configuration à l'autre. C'est précisément pourquoi la stratégie drop: [ALL] puis add explicite est la seule qui donne un résultat prévisible : elle ne suppose rien de l'environnement.

privileged (à éviter absolument)

Le mode privileged: true désactive une grande partie de l'isolation habituelle du conteneur :

# ⚠️ NE JAMAIS FAIRE EN PRODUCTION
spec:
  containers:
  - name: dangerous
    image: busybox:1.36
    securityContext:
      privileged: true  # Désactive l'isolation conteneur

privileged = risque de compromission de l'hôte

Un conteneur privileged: true peut potentiellement :

• Monter n'importe quel device de l'hôte
• Accéder à des parties sensibles du filesystem hôte
• Charger des modules kernel

Dans la pratique, cela rapproche fortement le conteneur des privilèges de l'hôte. Le risque exact dépend du runtime, des mounts et de l'isolement réel, mais considérez-le comme extrêmement risqué.

Utilisez-le uniquement pour des outils système très spécifiques (monitoring réseau bas niveau, agents de nœud) et jamais pour des applications.

Profils de sécurité complémentaires

Les réglages vus jusqu'ici portent sur l'identité et les permissions. Ceux qui suivent activent des mécanismes du noyau Linux relayés par le runtime : filtrage des appels système, étiquetage SELinux, isolation des identifiants utilisateur. On les configure moins souvent à la main, mais le niveau Restricted des Pod Security Standards en réclame une partie.

seccompProfile

Le profil Seccomp limite les appels système (syscalls) qu'un conteneur peut effectuer :

spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault  # Utilise le profil par défaut du runtime

Type	Description
RuntimeDefault	Profil par défaut du runtime (recommandé)
Unconfined	Pas de restriction (déconseillé)
Localhost	Profil personnalisé sur le nœud

Glissez pour voir

seLinuxOptions

Pour les clusters avec SELinux activé (RHEL, OpenShift) :

spec:
  securityContext:
    seLinuxOptions:
      level: "s0:c123,c456"

Des Pods qui ne démarrent plus après un passage en 1.37

Sur un cluster où SELinux est activé, deux Pods qui partagent un volume avec des étiquettes SELinux incompatibles ne démarrent plus depuis Kubernetes 1.37. Avant, le conflit passait inaperçu : le contenu du volume était réétiqueté à chaque montage, et le second Pod écrasait silencieusement le travail du premier.

Si vous rencontrez ce cas et devez rétablir l'ancien comportement, le réglage se pose par Pod :

spec:
  securityContext:
    seLinuxChangePolicy: Recursive

La vraie correction reste d'accorder les étiquettes entre les Pods qui partagent le volume. Un cluster sans SELinux n'est pas concerné.

procMount

Le paramètre procMount contrôle comment /proc est monté dans le conteneur. Par défaut, il est partiellement masqué, précisément pour des raisons de sécurité. Les Pod Security Standards le contraignent aux niveaux Baseline et Restricted : ce n'est pas un réglage qu'on relâche à la légère.

User Namespaces (hostUsers)

Depuis Kubernetes 1.36, les User Namespaces sont GA et activés par défaut. Ils permettent à un pod de tourner dans son propre namespace utilisateur Linux, distinct de celui de l'hôte. Conséquence : un processus qui se croit root (UID 0) à l'intérieur du conteneur correspond en réalité à un UID non privilégié côté hôte. Une évasion de conteneur ne donne plus root sur le nœud.

Le champ s'écrit spec.hostUsers (au niveau pod, pas dans securityContext) :

apiVersion: v1
kind: Pod
metadata:
  name: app-with-userns
spec:
  hostUsers: false        # nouveau namespace utilisateur pour ce pod
  securityContext:
    runAsUser: 1000
    runAsNonRoot: true
  containers:
  - name: app
    image: myapp:1.0.0

Valeur	Effet
true (défaut)	Le pod partage le namespace utilisateur de l'hôte (comportement historique)
false	Kubernetes crée un namespace utilisateur dédié et map les UIDs/GIDs du pod vers une plage non privilégiée de l'hôte

Glissez pour voir

Ce réglage ne fonctionne pas sur un cluster kind

Autant le dire avant que vous ne perdiez une heure : sur le cluster kind de cette formation, hostUsers: false ne démarre pas. Le Pod reste en ContainerCreating et le nœud rapporte :

Warning  FailedCreatePodSandBox  kubelet
OCI runtime create failed: runc create failed: error during container init:
error mounting "sysfs" to rootfs at "/sys": operation not permitted

Ce n'est pas une erreur de manifeste, et ce n'est pas une question de version de runtime : le cluster tourne en containerd 2.3.4, largement au-dessus du minimum. La cause est ailleurs : un nœud kind est lui-même un conteneur, et imbriquer un namespace utilisateur dans un conteneur demande une configuration de l'hôte que kind ne fournit pas. Éprouver hostUsers: false réclame des nœuds réels, machines physiques ou virtuelles.

Deux réserves valent en revanche partout. Le runtime doit être containerd 1.7+ ou CRI-O 1.25+ ; sur plus ancien, le Pod démarre mais le mapping n'est pas appliqué, ce que /proc/<pid>/uid_map sur le nœud permet de confirmer. Et certaines fonctionnalités sont incompatibles avec ce mode : les volumes hostPath partagés avec des processus hors du Pod, CAP_SYS_MODULE, ou tout besoin d'agir sur le namespace utilisateur de l'hôte.

Template de départ pour la production

Voici un template de Security Context comme point de départ pour les workloads de production :

apiVersion: v1
kind: Pod
metadata:
  name: production-secure
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 1000
    runAsNonRoot: true
    fsGroup: 1000
    seccompProfile:
      type: RuntimeDefault

  containers:
  - name: app
    image: myapp:1.0.0
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
          - ALL
    resources:
      requests:
        memory: "64Mi"
        cpu: "100m"
      limits:
        memory: "128Mi"
        cpu: "500m"
    volumeMounts:
    - name: tmp
      mountPath: /tmp

  volumes:
  - name: tmp
    emptyDir: {}

Ce template n'est pas universel

Ce template est un point de départ, pas une recette universelle :

• L'image doit supporter un UID arbitraire et un root filesystem en lecture seule
• fsGroup n'est pas toujours nécessaire selon vos volumes
• Les capabilities nécessaires dépendent de votre application

Testez toujours le comportement réel de votre image avec ces restrictions.

Checklist de sécurité

Ces sept réglages sont ceux qu'un audit de conformité contrôle en premier. La dernière colonne rappelle ce que chacun empêche : c'est elle qui permet d'arbitrer quand une application refuse de démarrer et qu'on est tenté de relâcher un paramètre.

Paramètre	Valeur recommandée	Pourquoi
runAsNonRoot	true	Refuse le démarrage si root
runAsUser	>= 1000	UID non-root explicite
allowPrivilegeEscalation	false	Bloque setuid/setgid (à définir explicitement)
readOnlyRootFilesystem	true	Empêche l'écriture non contrôlée
capabilities.drop	ALL	Supprime toutes les capabilities
privileged	false (ou absent)	Jamais true en production
seccompProfile	RuntimeDefault	Limite les syscalls autorisés

Glissez pour voir

Relation avec Pod Security Standards

Les Pod Security Standards (PSS) définissent trois niveaux de restriction :

Niveau	Ce qui est autorisé
Privileged	Tout, aucune restriction
Baseline	Restrictions minimales, pas de privileged, pas de hostNetwork, procMount limité
Restricted	Hardening complet, ensemble plus large de contraintes

Glissez pour voir

Attention au raccourci courant : Restricted ne se résume pas à « runAsNonRoot + drop: ALL + readOnlyRootFilesystem ». Le niveau impose un ensemble de contraintes nettement plus large, dont un securityContext strict n'est qu'une partie. La liste complète vit dans la documentation officielle, et elle évolue d'une version à l'autre.

Depuis Kubernetes 1.25, le Pod Security Admission applique ces standards au niveau du namespace, sans que vous ayez à surveiller chaque Pod. Un label suffit, et tout Pod non conforme est alors refusé à l'admission :

kubectl label namespace my-ns pod-security.kubernetes.io/enforce=restricted

Pod Security Standards Documentation officielle des 3 niveaux et leurs contraintes

Tester la configuration

Un securityContext accepté par l'API n'est pas pour autant appliqué comme vous l'imaginez : l'image, le runtime ou le type de volume peuvent en modifier l'effet réel. Les commandes suivantes s'exécutent depuis l'intérieur du conteneur et montrent l'état effectif : l'identité du processus, les capacités conservées et la possibilité d'écrire.

Commande rapide CKAD

À l'examen, personne n'écrit un manifeste de Pod à la main : on le fait générer, puis on l'édite. --dry-run=client -o yaml produit le squelette sans rien créer dans le cluster, soit deux minutes gagnées sur une épreuve chronométrée. Le securityContext s'ajoute ensuite à l'endroit voulu : sous spec pour le niveau Pod, sous le conteneur pour le niveau conteneur.

# Créer un Pod de base
kubectl run secure-test \
  --image=nginx:1.30@sha256:d5792f71a9496b833bc08ea834a758c46e2b6a6306c10f4be926f38a656cdc1c \
  --dry-run=client -o yaml > secure-pod.yaml

# Éditer pour ajouter le securityContext

Vérifier l'utilisateur effectif

La commande id affiche l'identité effective du processus. Les valeurs doivent correspondre exactement à runAsUser, runAsGroup et supplementalGroups déclarés dans le manifeste.

kubectl exec -it secure-test -- id
# uid=1000 gid=1000 groups=1000

Vérifier les capabilities

Les capacités apparaissent en hexadécimal dans /proc/1/status. La ligne CapEff est celle qui compte : elle représente l'ensemble réellement utilisable par le processus à cet instant.

kubectl exec -it secure-test -- cat /proc/1/status | grep -i cap

Vérifier readOnlyRootFilesystem

Un touch à la racine est le test le plus rapide : il doit échouer. S'il réussit, le paramètre n'a pas été pris en compte.

kubectl exec -it secure-test -- touch /test.txt
# touch: /test.txt: Read-only file system

Dépannage

La quasi-totalité des incidents liés au securityContext se déclarent à deux moments : au démarrage du Pod, quand Kubernetes refuse la configuration, ou à la première écriture, quand l'application découvre ses restrictions. Le tableau associe chaque symptôme à sa cause, et les commandes qui suivent confirment le diagnostic.

Problèmes courants

Ces messages remontent dans la section Events de kubectl describe pod, pas dans les journaux du conteneur : quand le démarrage est refusé, aucun journal n'existe encore.

Symptôme	Cause probable	Solution
container has runAsNonRoot and image will run as root, avec reason: CreateContainerConfigError	Image définit USER 0, ou Kubernetes ne peut pas valider	Ajouter runAsUser: 1000 explicitement
Pod ne démarre pas, permission denied	runAsUser incompatible avec l'image	Vérifier l'UID attendu par l'image
Application ne peut pas écrire	readOnlyRootFilesystem: true	Monter des emptyDir pour les dossiers d'écriture
Bind port 80 échoue	capabilities.drop: ALL	Ajouter NET_BIND_SERVICE ou utiliser port > 1024
Fichiers volumes non accessibles	fsGroup non supporté par le volume	Vérifier la compatibilité du backend de stockage

Glissez pour voir

Debug avec kubectl

Quand le tableau ne suffit pas, ces trois commandes donnent l'état complet : les événements du Pod, le securityContext réellement enregistré par l'API après fusion des niveaux Pod et conteneur, puis un conteneur jetable qui sert de point de comparaison sans restriction.

# Voir les événements
kubectl describe pod <pod-name>

# Vérifier les paramètres de sécurité appliqués
kubectl get pod <pod-name> -o yaml | grep -A 20 securityContext

# Tester interactivement
kubectl run debug --rm -it \
  --image=busybox:1.37@sha256:9db7b59979c38555a39def84a31fb98b5296952f9e3afd4f6f11f05b07adfab0 \
  -- sh

À retenir pour la CKAD

Pour l'examen CKAD, maîtrisez ces paramètres essentiels :

1. runAsNonRoot: true, refuse le démarrage si Kubernetes ne peut pas valider un utilisateur non-root
2. runAsUser: 1000, définit explicitement l'UID (souvent requis avec runAsNonRoot)
3. allowPrivilegeEscalation: false, à définir explicitement pour bloquer les escalades
4. capabilities.drop: [ALL], supprime toutes les capabilities, puis add si nécessaire
5. readOnlyRootFilesystem: true, avec des emptyDir pour les dossiers d'écriture

Différence Pod vs conteneur : les valeurs conteneur écrasent les valeurs Pod.

À retenir pour la production

Au-delà de la CKAD, ajoutez ces pratiques :

1. seccompProfile: RuntimeDefault, limite les syscalls autorisés
2. supplementalGroups, pour les accès à des groupes secondaires
3. fsGroup avec vérification, testez la compatibilité avec vos volumes
4. Combinaison avec PSS/PSA, appliquez les standards au niveau namespace
5. Test des images, vérifiez que l'image supporte vraiment vos contraintes

Testez vos connaissances

Sept questions tirées de ce guide, avec un seuil de réussite fixé à 80 %.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

7 questions

5 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

Pour aller plus loin

• AppArmor et Seccomp : La restriction des appels système, un cran au-dessus des capabilities.
• Pod Security Standards : Le même durcissement imposé à tout un namespace plutôt que Pod par Pod.

×

📖 Voir la documentation →