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

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

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

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. Il constitue le socle minimal attendu sur un workload 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é.

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

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

À 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

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

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

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"

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.

User Namespaces (hostUsers)

Depuis Kubernetes 1.36, les User Namespaces sont GA et activés par défaut (KEP-127). 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

Prérequis runtime

L'effet réel dépend du runtime conteneur : containerd 1.7+ ou CRI-O 1.25+ sont requis. Sur des runtimes plus anciens, le pod démarre mais le mapping UID/GID n'est pas appliqué, un audit crictl inspect ou un lecteur de /proc/<pid>/uid_map sur le nœud confirme la prise en compte effective.

Certaines fonctionnalités sont incompatibles avec hostUsers: false : 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

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

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, à savoir l'identité du processus, les capabilities conservées et la possibilité d'écrire.

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

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 capabilities 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 constitue 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, les commandes qui suivent permettent de confirmer le diagnostic.

Problèmes courants

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

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

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

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 →