Contexte de sécurité Kubernetes : configuration et bonnes pratiques

Un Kubernetes security context définit les privilèges et contrôles d’accès runtime pour les pods et les conteneurs. C’est l’un des leviers essentiels pour appliquer le principe du moindre privilège et réduire la surface d’attaque. En configurant soigneusement ces contextes, vous renforcez la posture de sécurité de vos workloads, atténuez les menaces et simplifiez la conformité aux réglementations du secteur.

Avantages de la mise en place de security contexts

En déployant des security contexts, les équipes bénéficient de contrôles fins au niveau du pod et du conteneur. Cette pratique permet de réduire les vulnérabilités courantes et d’appliquer des politiques de moindre privilège via des paramètres comme runAsNonRoot, readOnlyRootFilesystem et des capacités Linux limitées. Elle renforce également les défenses au niveau du cluster grâce aux options SELinux et aux profils AppArmor.

Voici les principaux atouts des Kubernetes security contexts :

Posture de sécurité renforcée

Les security contexts fournissent des contrôles stricts au niveau du runtime sur les conteneurs et les pods :

exécution des processus en tant qu’utilisateurs non-root ;
restriction de l’accès au système de fichiers racine ;
limitation des capacités Linux.

Ainsi, ils limitent l’escalade de privilèges et les mouvements latéraux, même si des conteneurs individuels sont compromis.

Conseil pro

Définissez readOnlyRootFilesystem: true pour bloquer les écritures non autorisées et empêcher les attaquants de modifier les fichiers de l’application ou d’installer des outils malveillants.

Surface d’attaque réduite au sein des clusters Kubernetes

Les conteneurs fonctionnent souvent avec plus d’autorisations que nécessaire, offrant aux attaquants des voies d’exploitation supplémentaires. Pour remédier à cette faiblesse, les security contexts appliquent le principe du moindre privilège afin que les workloads des conteneurs ne s’exécutent qu’avec les permissions strictement nécessaires.

Conseil pro

Supprimez les capacités de noyau inutiles et définissez allowPrivilegeEscalation: false dans vos Pod Security Policies (PSP) pour empêcher les conteneurs d’obtenir des privilèges élevés ou de dépasser le niveau de privilège de leur processus parent.

Conformité et préparation aux audits améliorées

Les secteurs réglementés doivent respecter des normes strictes de protection et de stockage des données des consommateurs. Les security contexts aident à se conformer à ces exigences en appliquant des limitations de sécurité pendant le runtime des conteneurs. En combinant ces paramètres avec des contrôleurs d’admission comme Wiz, PSA ou OPA, vous pouvez appliquer de façon homogène les règles à tous les workloads et bloquer automatiquement les pods non conformes aux exigences de configuration de sécurité.

Kubernetes Security Context Best Practices [Cheat Sheet]

A comprehensive guide to configuring security contexts for pods and containers in Kubernetes.

Types de contextes de sécurité

Vous pouvez utiliser les security contexts dans Kubernetes à deux niveaux distincts : pod et conteneur. Voici leur fonctionnement et les security controls qu’ils offrent :

Contextes de sécurité des pods

Les pod security contexts s’appliquent à tous les conteneurs d’un pod et se définissent dans le fichier de spécification du pod. Les options courantes incluent :

Options SELinux : isoler les processus du pod entre eux et de l’hôte pour renforcer la séparation des processus ;
fsGroup : définir l’ID de groupe (GID) des volumes pour gérer l’accès au stockage partagé dans le pod ;
runAsUser et runAsGroup : spécifier les UID et GID de vos conteneurs et garantir que les workloads ne s’exécutent pas en root.

Voici un exemple minimal de security context au niveau du pod :

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    runAsUser: 1000
  containers:
  - name: app
    image: nginx

Cette configuration garantit que seuls les utilisateurs avec l’UID 1000 peuvent exécuter des workloads dans ce pod.

Contextes de sécurité des conteneurs

Les container security contexts offrent un contrôle plus granulaire, car vous pouvez définir des paramètres de sécurité pour chaque conteneur. Utilisez ces fonctionnalités pour remplacer les métadonnées de sécurité du pod :

Gestion des capacités : contrôler les capacités du noyau Linux à ajouter ou à supprimer pour conserver une empreinte système minimale.
readOnlyRootFilesystem : rendre le système de fichiers racine en lecture seule pour empêcher les modifications système et limiter l’impact d’une compromission.
allowPrivilegeEscalation : définir si un processus peut obtenir plus de privilèges que son parent afin de contenir les conteneurs privilégiés.

Il est essentiel de garder en tête que les paramètres au niveau du conteneur priment sur les security contexts au niveau du pod. En combinant des métadonnées de sécurité aux niveaux de pod et de conteneur dans Kubernetes, vous pouvez adapter votre posture de sécurité aux exigences spécifiques de vos applications tout en minimisant les risques. Or, une utilisation non maîtrisée de ces paramètres peut introduire, à votre insu, des risques de sécurité dans vos workloads.

Le blog de Wiz

Kubernetes API limitations in finding non-standard pods and containers

Erreurs de configuration fréquentes des security contexts

Des erreurs de configuration au niveau des security contexts peuvent entraîner des problèmes de sécurité graves pour vos ressources Kubernetes. C’est le cas si vous déployez des workloads avec des permissions par défaut qui restent exposées aux attaques. Soyez donc attentif aux erreurs clés suivantes :

Exécuter les conteneurs en root

Des conteneurs exécutés avec des permissions root accordent aux processus applicatifs des droits d’administration complets. Cette pratique est risquée, car elle facilite l’évasion du runtime du conteneur, la modification de fichiers système, voire la compromission du nœud hôte sous-jacent.

🛠️ Mesure à prendre : configurez vos workloads pour s’exécuter avec des utilisateurs non-root en définissant runAsNonRoot: true dans le champ de métadonnées securityContext.

Ne pas définir readOnlyRootFilesystem

L’utilisation de readOnlyRootFilesystem: true empêche vos processus d’écrire dans le système de fichiers racine, compliquant ainsi la tâche des attaquants qui voudraient altérer des fichiers système, stocker des binaires malveillants ou maintenir une persistance.

🛠️ Mesure à prendre : rendre le système de fichiers racine en lecture seule afin de contenir les attaques et d’imposer l’immutabilité pour les applications qui n’ont pas besoin de privilèges root en runtime.

Utiliser des conteneurs privilégiés

Définir privileged: true dans les métadonnées securityContext accorde aux conteneurs un accès root dans les conteneurs ainsi que sur le nœud hôte. Ainsi, ces conteneurs peuvent interagir directement avec le matériel de l’hôte, les montages de volumes et les paramètres du noyau, ouvrant la voie à une compromission système complète.

🛠️ Mesure à prendre : évitez d’utiliser des conteneurs privilégiés en veillant à ce que privileged: true ne soit pas défini dans votre securityContext et examinez régulièrement les workloads pour supprimer les privilèges inutiles.

Autoriser l’escalade de privilèges

La configuration allowPrivilegeEscalation: false empêche les processus des conteneurs d’obtenir plus de privilèges que leur processus parent. Or, ce champ est vrai par défaut, rendant vos workloads vulnérables à des chaînes d’exploitation où un attaquant peut élever ses accès après la compromission d’un pod.

🛠️ Mesure à prendre : définissez ce champ à false pour empêcher l’escalade de privilèges.

Accorder des capacités Linux excessives

Accorder à des conteneurs des capacités Linux inutiles est une erreur de configuration courante. En effet, des capacités comme CAP_SYS_ADMIN fournissent bien plus de fonctionnalités que nécessaire pour la plupart des workloads. Or, une surallocation accroît le risque d’escalade de privilèges et amplifie l’impact d’une compromission.

🛠️ Mesure à prendre : supprimez toutes les capacités système inutiles et appliquez le principe du moindre privilège à vos conteneurs.

🚨Kubernetes Security Report 2025

New insights from 200,000+ cloud accounts uncovers the latest risks, attack trends, and security gaps in Kubernetes environments.

Download PDF

5 bonnes pratiques pour les Kubernetes security contexts

Voyons cinq bonnes pratiques actionnables et leur impact sur la sécurité de votre cluster :

1. Définir des security contexts aux niveaux pod et conteneur

Appliquer des security contexts au niveau du pod et du conteneur vous permet d’imposer des contrôles granulaires à l’ensemble de vos workloads. Voici comment exploiter ces contextes pour renforcer la protection à chaque couche :

Security contexts au niveau du pod

Appliquez des contrôles de base à tous les conteneurs d’un pod. Cela inclut l’utilisation des options SELinux, la configuration des groupes de fichiers (fsGroup) et la définition d’UID/GID par défaut (runAsUser, runAsGroup).

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  securityContext:
    runAsUser: 1000
    fsGroup: 2000
  containers:
  - name: example-container
    image: example/image

Ce YAML définit un utilisateur non-root (UID 1000) et associe un groupe de fichiers (GID 2000) pour tous les conteneurs du pod.

Security contexts au niveau du conteneur

Utilisez des paramètres de sécurité au niveau du conteneur pour remplacer les métadonnées du pod pour des workloads spécifiques. Par exemple, vous pouvez attribuer à chaque conteneur des capacités Linux, des privilèges utilisateur ou des restrictions de système de fichiers différentes selon son rôle ou sa fonction.

spec:
  containers:
  - name: example-container
    image: example/image
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true

Cette définition empêche les processus du conteneur d’obtenir des privilèges supplémentaires avec allowPrivilegeEscalation: false et rend le système de fichiers racine en lecture seule avec readOnlyRootFilesystem: true.

Le security context au niveau du pod prend également en charge :

Profils SELinux/AppArmor : configurez seLinuxOptions dans le securityContext du pod pour spécifier des labels SELinux imposant des contrôles d’accès obligatoires. Utilisez des annotations de pod pour affecter des profils AppArmor pour le filtrage des syscalls et le confinement des processus.
fsGroup : définissez fsGroup pour fixer le GID de tous les fichiers partagés par vos conteneurs et garantir des permissions correctes sur les volumes partagés.
Profils seccomp : activez seccomp via le champ seccompProfile pour limiter les appels système disponibles pour les conteneurs.

Ainsi, ces fonctionnalités assurent une isolation en couches et renforcent la sécurité de tous les conteneurs du pod.

Les paramètres de security context au niveau du conteneur remplacent ceux du niveau pod. Or, si vous ne faites pas preuve de vigilance lors des remplacements dans les métadonnées du conteneur, vous pouvez, à votre insu, désactiver ou affaiblir des politiques de sécurité importantes définies au niveau du pod.

Par exemple, vous pouvez définir des valeurs par défaut strictes comme la désactivation de l’escalade de privilèges et le passage en lecture seule des systèmes de fichiers sur le pod applicatif. Toutefois, si un sidecar de logging a besoin d’écrire des logs, remplacez le security context uniquement pour ce sidecar tout en conservant les restrictions pour le pod applicatif.

Des contrôles granulaires par conteneur sont également précieux pour réussir des audits et rester conforme à des normes comme PCI DSS ou HIPAA, car ils permettent d’associer précisément des contrôles de sécurité aux exigences réglementaires de chaque workload.

Cependant, des paramètres de sécurité incohérents entre conteneurs (drift de configuration) peuvent affaiblir les protections au fil du temps. Utilisez donc des outils d’application de politiques comme OPA Gatekeeper ou PSA. Autrement, intégrez des checks CI lors des déploiements pour garantir des security contexts homogènes sur tous vos workloads. Vous pouvez ensuite envoyer les métriques, les logs et les rapports de violation de politiques de ces plateformes vers votre pile d’observabilité. Vous pourrez visualiser en détail l’usage des security contexts et recevoir des alertes en temps réel.

Académie Wiz

Les 11 meilleurs outils open source de sécurité Kubernetes

Il est judicieux d'envisager l'utilisation de plusieurs outils de sécurité Kubernetes. Les solutions open source peuvent considérablement améliorer la sécurité de vos clusters Kubernetes ; cette section présente donc les 11 meilleurs outils de sécurité open source pour Kubernetes, capables de protéger votre environnement.

2. Exploiter readOnlyRootFilesystem pour des conteneurs immuables

Les attaquants ciblent régulièrement des conteneurs modifiables qu’ils exploitent pour déposer des web shells ou persister après une attaque par malware. Pour empêcher l’écriture dans le système de fichiers racine, définissez readOnlyRootFilesystem: true dans le security context de votre YAML. Cette mesure bloque la modification de fichiers applicatifs, le stockage d’exécutables malveillants et la persistance en cas de compromission.

securityContext:
  readOnlyRootFilesystem: true

Si vos applications doivent écrire sur ces systèmes de fichiers, utilisez à la place des volumes montés avec contrôle d’accès. Assurez-vous que les applications n’écrivent que dans les volumes montés en procédant comme suit :

Définir et monter des volumes avec les bons droits dans la spec du Pod.
Mettre à jour la configuration des applications pour utiliser ces volumes pour toutes les écritures.
Monter des volumes sur les chemins nécessaires pour les applications legacy qui dépendent d’un root modifiable, puis refactorer dès que possible.

Utilisez des outils comme kube-bench et des scanners de sécurité dans les pipelines CI/CD pour vérifier la conformité. Vous pouvez aussi les configurer pour produire des alertes JSON structurées, puis les transférer via des webhooks ou des API vers votre SIEM afin de recevoir des alertes de violation dans vos workflows SOC.

Pour renforcer davantage vos défenses, combinez des systèmes de fichiers en lecture seule avec des security controls supplémentaires comme :

la liste blanche des processus ;
la signature d’images de conteneurs ;
l’application de l’immutabilité dans votre pipeline CI/CD.

Cette approche en couches protège mieux contre les attaques sur les conteneurs et les changements non autorisés.

3. Imposer l’usage de conteneurs non-root

Exécuter les conteneurs en tant qu’utilisateurs non-root limite l’impact potentiel d’une compromission, car les attaquants n’obtiendront que des permissions restreintes sur les conteneurs. Pour cela, définissez le champ runAsUser dans votre security context afin de spécifier un UID non-root.

securityContext:
  runAsUser: 1000

Si vous ne spécifiez pas d’UID non-root, la plupart des conteneurs s’exécuteront par défaut en root (UID 0), sauf si l’image définit un autre utilisateur. Ainsi, envisagez d’ajouter runAsNonRoot: true pour empêcher l’exécution en root, même si l’entrypoint par défaut de l’image tente de le faire.

Étant donné que la plupart des images publiques tentent de s’exécuter en root, des outils d’analyse d’images comme Trivy, Grype ou Snyk peuvent détecter ces images et imposer des utilisateurs non-root. Choisir des images qui n’exigent que des utilisateurs non-root est une autre façon d’atténuer ce problème.

Les normes et recommandations comme le CIS Kubernetes Benchmark déconseillent également l’usage de root en production (policy essentials). Auditez donc vos workloads pour détecter l’usage de root en mettant en place des checks CI ou en déployant des agents de monitoring pour vous aligner proactivement sur ces recommandations.

Container Security Best Practices [Cheat Sheet]

Learn to secure containers end-to-end with zero trust, intrusion detection, and the right tools for Kubernetes, Docker, and cloud-native environments.

4. Désactiver l’escalade de privilèges

Pour un attaquant, l’objectif ultime est l’escalade de privilèges depuis un conteneur compromis vers un conteneur plus critique ou vers l’hôte. Par défaut, certains conteneurs peuvent autoriser des processus enfants à obtenir des privilèges root élevés à runtime.

Pour contrer cela, définissez allowPrivilegeEscalation: false dans le security context de votre conteneur. Ce champ s’appuie sur le flag no_new_privs du noyau Linux pour interdire l’escalade de privilèges des processus enfants via des binaires setuid ou setgid.

securityContext:
  allowPrivilegeEscalation: false
  privileged: false

Vous devez également définir privileged: false dans vos specs de pod pour empêcher des conteneurs d’obtenir un accès illimité à l’hôte. Ce champ est plus permissif que allowPrivilegeEscalation, car il accorde un accès root sans restriction à la machine hôte qui exécute tous vos conteneurs.

De récentes CVE d’évasion de conteneur et d’escalade de privilèges montrent pourquoi ces réglages sont essentiels :

CVE-2024-21626 : une vulnérabilité a permis une évasion de conteneur via des fuites de descripteurs de fichiers, menant à une escalade de privilèges et à un accès à l’hôte ;
CVE-2023-2640 et CVE-2023-32629 : des attaquants ont enchaîné ces vulnérabilités pour obtenir un accès root depuis un conteneur non-root via une escalade de privilèges.

Le paramètre privileged: false bloque ces vecteurs d’attaque qui visent un accès complet au noyau de l’hôte. Afin de rendre cette étape non optionnelle sur l’ensemble de vos clusters Kubernetes, vous pouvez aussi exploiter des outils d’application de politiques d’admission comme Pod Security Admission (PSA), Open Policy Agent (OPA) ou des webhooks personnalisés.

Pod Security Admission (PSA) : activez un profil de politique « restricted » au niveau du cluster pour imposer par défaut allowPrivilegeEscalation: false et privileged: false à tous les conteneurs.
OPA Gatekeeper : déployez des politiques personnalisées (ConstraintTemplates) pour refuser tous les pods avec allowPrivilegeEscalation: true ou privileged: true.
Webhooks d’admission : implémentez des webhooks qui inspectent les specs des pods lors de la création ou de la mise à jour et rejettent toute workload demandant une escalade de privilèges.

Si un conteneur demande allowPrivilegeEscalation: true en violation de ces politiques, l’outil de politique ou le webhook peut donc refuser le déploiement de la workload.

5. Gérer les capacités Linux avec drop et add

Le contrôle des capacités Linux est crucial pour limiter les privilèges au strict nécessaire de votre workload. Utilisez le champ capabilities du security context de votre conteneur pour supprimer explicitement les permissions inutiles telles que CAP_SYS_ADMIN et n’ajouter que celles indispensables.

securityContext:
  capabilities:
    drop:
    - ALL
    add:
    - NET_BIND_SERVICE

Parmi les capacités Linux à haut risque à surveiller :

CAP_NET_ADMIN : modifier la configuration réseau
CAP_SYS_MODULE : charger/décharger des modules noyau
CAP_SYS_PTRACE : activer le traçage et le débogage des processus
CAP_SYS_RAWIO : effectuer des opérations d’E/S brutes

Des capacités Linux généralement sûres et souvent nécessaires incluent :

CAP_CHOWN : changer le propriétaire d’un fichier
CAP_SETUID : définir des UID
CAP_SETGID : définir des GID
CAP_NET_BIND_SERVICE : se lier à des ports inférieurs à 1024

Vous pouvez définir un jeu clair de capacités requises pour chaque conteneur grâce à des tests itératifs, au profilage applicatif et à la documentation de sécurité de vos éditeurs.

Tests itératifs : commencez par supprimer toutes les capacités (drop: ["ALL"]) puis ajoutez progressivement uniquement celles sans lesquelles l’application ne peut pas fonctionner.
Profilage applicatif : utilisez des outils comme strace ou auditd pour surveiller les syscalls et identifier les capacités demandées par vos workloads à runtime.

Octroyer des capacités Linux excessives augmente la surface d’attaque et facilite les mouvements latéraux des attaquants vers d’autres compromissions. Par exemple, un intrus avec des capacités de noyau excessives peut remonter des systèmes de fichiers critiques comme /proc en écriture pour franchir les limites du conteneur. De même, CAP_NET_ADMIN permet d’intercepter ou de rediriger le trafic réseau dans le cluster, ce qui peut entraîner de la data exfiltration ou des attaques de type man-in-the-middle.

Pour protéger vos clusters, intégrez des vérifications de capacités dans vos pipelines CI/CD. Autrement, utilisez des outils comme kube-bench pour détecter les capacités Linux excessives. Des outils d’application de politiques tels que PSA et OPA Gatekeeper peuvent également automatiser ces contrôles à l’échelle des clusters.

Security context et normes de conformité

Le Kubernetes security context aide les organisations à appliquer des security controls clés contribuant à se conformer aux normes telles que PCI DSS, HIPAA et le RGPD. Il le fait en fournissant :

Contrôle d’accès : les security contexts aident à mettre en œuvre le principe du moindre privilège en exécutant les conteneurs en non-root, en supprimant les capacités inutiles et en empêchant l’escalade de privilèges.
Protection des données : des paramètres comme readOnlyRootFilesystem empêchent les modifications non autorisées des systèmes de fichiers et protègent contre les fuites de données depuis des conteneurs sensibles.
Auditabilité : des politiques securityContext homogènes simplifient les audits en imposant des exigences de conformité via des bases de sécurité contrôlées et bien définies.

Cependant, si les security contexts renforcent la sécurité au niveau du conteneur, la conformité complète exige un ensemble de contrôles plus large. Pour y parvenir, vous devez :

mettre en œuvre RBAC pour contrôler les permissions des utilisateurs ;
déployer des politiques réseau pour limiter la communication entre pods ;
activer l’audit logging pour la traçabilité ;
utiliser des outils comme Wiz, PSA ou OPA pour automatiser l’application des politiques.

En combinant ces bonnes pratiques Kubernetes avec des security contexts, vous mettez en place une stratégie defense-in-depth conforme aux réglementations du secteur et vous restez prêt pour les audits. Le tableau suivant indique quels contrôles de security context aident pour quels cadres de conformité.

Contrôle	PCI DSS	CIS	NIST
Utilisateur non-root/runAsUser	✓	✓	✓
Supprimer les capacités à risque	✓	✓	✓
readOnlyRootFilesystem	✓	✓	✓

Contexte de sécurité et admission de sécurité des capsules

Admission à la sécurité du module (PSA) applique des politiques de sécurité au niveau du namespace Kubernetes en validant les spécifications des pods, y compris les paramètres de security context, avant leur déploiement. Ainsi, PSA utilise des niveaux de politique prédéfinis (privileged, baseline et restricted) pour contrôler les paramètres de sécurité autorisés.

Par exemple, la politique « restricted » exige l’exécution des conteneurs en non-root, désactive le mode privilégié et limite les capacités du noyau. Si le champ securityContext d’un pod ne satisfait pas à ces exigences, PSA peut bloquer son déploiement, émettre un avertissement ou journaliser la violation en fonction du mode configuré.

La configuration suivante de Pod Security Admission impose le profil de sécurité « restricted » par défaut à l’échelle du cluster et rejette tout pod non conforme, à l’exception du namespace kube-system qui est exempté de ces restrictions.

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: PodSecurity
    configuration:
      apiVersion: pod-security.admission.config.k8s.io/v1
      kind: PodSecurityConfiguration
      defaults:
        enforce: restricted
      exemptions:
        usernames: []
        runtimeClasses: []
        namespaces:
          - kube-system

Wiz : Une plateforme de sécurité Kubernetes complète

Les erreurs de configuration Kubernetes, telles que l’exécution de conteneurs en tant que root, l’utilisation du mode privilégié ou l’octroi de capacités Linux excessives, peuvent silencieusement affaiblir les défenses du cluster. Plus tôt, nous avons montré comment ces erreurs créent des risques, allant de la falsification du système de fichiers à la compromission complète du nœud.

Wiz résout directement ces problèmes en :

Détectant les erreurs de configuration avant le déploiement : Wiz analyse vos manifestes Kubernetes, charts Helm et templates IaC pour détecter les paramètres securityContext risqués (comme les systèmes de fichiers inscriptibles ou les conteneurs s’exécutant en tant que root) avant le déploiement.
Appliquant les meilleures pratiques lors de l’admission : avec le contrôleur d’admission Wiz, vous pouvez bloquer les pods qui demandent une escalade de privilèges ou remplacent les profils restreints.
Maintenant la posture de conformité : Wiz mappe les paramètres de contexte de sécurité à PCI DSS, HIPAA et aux benchmarks CIS, vous donnant une visibilité immédiate sur la préparation aux audits.
Surveillance continue de l’exécution : même si les charges de travail dérivent de la politique après le déploiement, Wiz détecte les changements (comme les capacités ajoutées) et alerte votre équipe en temps réel.

Vous souhaitez appliquer les meilleures pratiques de sécurité Kubernetes et détecter les erreurs de configuration en temps réel ? Wiz automatise la gestion de la posture de sécurité et s’intègre à votre pipeline CI/CD. Planifiez une démo pour voir comment. Ou, pour un guide pratique immédiat, téléchargez notre aide-mémoire sur les contextes de sécurité Kubernetes et commencez à mettre en œuvre les meilleures pratiques dès aujourd’hui.

Points clés à retenir sur les Kubernetes security contexts :