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.

Ce que le Security Context ne fait pas

Le Security Context définit un cadre de privilèges d’exécution, mais il ne “sécurise” pas magiquement un Pod. Il doit être combiné avec :

• Une image adaptée (supporte UID arbitraire, pas de process root internal)
• Des volumes compatibles (emptyDir, PVC avec fsGroup supporté)
• Des ServiceAccounts correctement configurés
• Des NetworkPolicies pour l’isolation réseau
• Des Pod Security Standards appliqués au namespace

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

Deux niveaux d'application

Le Security Context peut être défini à deux niveaux :

• spec.securityContext — s’applique à tous les conteneurs du Pod
• spec.containers[].securityContext — s’applique à un conteneur spécifique (et écrase les valeurs Pod)

Pod Security Context vs Container Security Context

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
    # ─── 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é

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

Bonne pratique

Définissez les paramètres communs au niveau Pod (runAsUser, fsGroup, supplementalGroups) et les paramètres spécifiques au niveau conteneur (capabilities, readOnlyRootFilesystem).

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

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
    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
    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
    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é

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
    securityContext:
      allowPrivilegeEscalation: false

Protéger le filesystem et les volumes

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
    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
    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é.

Comportement variable selon le type de volume

fsGroup s’applique aux volumes compatibles, mais le comportement exact dépend du type de volume et du backend de stockage :

Type de volume	Support fsGroup
emptyDir	✅ Fonctionne bien
hostPath	⚠️ Pas de changement de GID
CSI volumes	Dépend du driver CSI
NFS	Dépend de la configuration du serveur

Glissez pour voir

Vérifiez toujours le comportement réel sur vos volumes persistants, surtout avec des backends de stockage spécifiques.

Contrôler les privilèges

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
    securityContext:
      allowPrivilegeEscalation: false

À définir explicitement

allowPrivilegeEscalation: false doit être défini explicitement si vous voulez bloquer les gains de privilèges via des binaires setuid ou setgid.

Attention : utiliser capabilities.drop: [ALL] réduit les capabilities disponibles, mais ne remplace pas ce réglage. Un processus pourrait toujours potentiellement exploiter un binaire setuid si allowPrivilegeEscalation n’est pas à false.

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

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
    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

Décoder les capabilities

Pour traduire la valeur hexadécimale en capabilities lisibles :

capsh --decode=0000000000000400
# 0x0000000000000400=cap_net_bind_service

Capabilities par défaut des runtimes

Les runtimes de conteneurs (Docker, containerd, CRI-O) accordent souvent un ensemble de capabilities par défaut. Cette liste varie selon le runtime et sa configuration.

Pour éviter les hypothèses hasardeuses, adoptez la stratégie drop: [ALL] puis réajoutez uniquement ce qui est strictement nécessaire à votre application.

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
    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

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"

procMount

Le paramètre procMount contrôle comment /proc est monté dans le conteneur. Par défaut, /proc est masqué partiellement pour la sécurité. Les Pod Security Standards contraignent ce paramètre au niveau Baseline et Restricted.

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é

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

Restricted est plus qu'un simple trio de settings

Le niveau Restricted impose un ensemble plus large d’exigences de durcissement, dont un securityContext strict fait partie. Il ne se limite pas à “runAsNonRoot + drop ALL + readOnlyRootFilesystem”.

Consultez la documentation officielle pour la liste complète des contraintes.

Pod Security Admission

Depuis Kubernetes 1.25, le Pod Security Admission controller applique automatiquement les PSS au niveau des namespaces. Vos Security Context doivent être conformes au niveau configuré.

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

Commande rapide CKAD

Générez un Pod avec Security Context :

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

# Éditer pour ajouter le securityContext

Vérifier l’utilisateur effectif

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

Vérifier les capabilities

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

Vérifier readOnlyRootFilesystem

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

Dépannage

Problèmes courants

Symptôme	Cause probable	Solution
Error: container has runAsNonRoot and image will run as root	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

# 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 --image=busybox --rm -it -- 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

Prochaines étapes

Requests et Limits Compléter la sécurité avec la gestion des ressources

ServiceAccounts Identité et permissions des Pods

Network Policies Isolation réseau des workloads

CKAD — Application Environment Security Context dans le blueprint CKAD

×

📖 Voir la documentation →