CNCF Kubernetes and Cloud Native Security Associate
Dernière révision : mai 2026
Une référence concise des modèles d'architecture évalués par l'examen KCSA. Lisez de haut en bas ou sautez à une section.
Architecture d'une stratégie de sécurité cloud native holistique.
Implémenter des contrôles de sécurité à travers les 4C : Cloud (fondation), Cluster, Conteneur et Code.
Pourquoi: Une compromission à une couche externe (par exemple, le Cloud) sape la sécurité de toutes les couches internes. La sécurité est aussi forte que son maillon le plus faible.
Protection contre les défaillances de sécurité à point unique.
Implémenter plusieurs contrôles de sécurité superposés à différentes couches (par exemple, NetworkPolicies, RBAC, Security Contexts).
Pourquoi: Si un contrôle échoue ou est contourné, d'autres couches continuent de fournir une protection, augmentant la difficulté pour l'attaquant.
Sécuriser le trafic réseau dans un environnement où la localisation réseau n'est pas une limite de confiance.
Implémenter un modèle "ne jamais faire confiance, toujours vérifier". Authentifier et autoriser chaque requête, typiquement en utilisant un service mesh pour mTLS.
Pourquoi: Suppose que les menaces peuvent exister à la fois à l'intérieur et à l'extérieur du réseau, éliminant la confiance implicite basée sur la position réseau.
Limiter le rayon d'impact d'une identité ou d'un composant compromis.
Accorder à tous les sujets (utilisateurs, comptes de service, nœuds) uniquement les permissions minimales requises pour exécuter leur fonction.
Pourquoi: Réduit les dommages potentiels qu'un attaquant peut causer avec des identifiants volés.
Réduire le coût et l'impact des vulnérabilités de sécurité.
Intégrer l'analyse de sécurité automatisée (SAST, SCA, analyse d'images) et les vérifications de politiques dans les premières étapes du pipeline CI/CD.
Pourquoi: Trouve et corrige les vulnérabilités plus tôt dans le cycle de vie du développement, lorsqu'elles sont les moins chères à corriger.
Protéger les données de cluster sensibles (en particulier les Secrets) si le stockage etcd est compromis.
Sur le kube-apiserver, utiliser `--encryption-provider-config` pour activer le chiffrement au repos pour les ressources avant qu'elles ne soient stockées dans etcd.
Pourquoi: Par défaut, les Secrets Kubernetes sont uniquement encodés en base64 dans etcd. Ceci fournit un véritable chiffrement sur disque.
Prévenir l'accès non autorisé et l'interception des communications etcd.
Configurer etcd avec mTLS pour la communication client (`--client-cert-auth`) et pair (`--peer-client-cert-auth`).
Pourquoi: Garantit que seuls les composants authentifiés (apiserver, autres membres etcd) peuvent communiquer avec etcd et que le trafic est chiffré.
Prévenir l'accès non authentifié au serveur API Kubernetes.
Définir le flag `--anonymous-auth=false`. Utiliser des méthodes d'authentification robustes comme OIDC ou les certificats x509.
Pourquoi: Désactive l'utilisateur `system:anonymous`, forçant toutes les requêtes à être authentifiées et enregistrées contre une identité spécifique.
Exigence de suivre toutes les modifications et tentatives d'accès pour la sécurité et la conformité.
Activer la journalisation d'audit du serveur API avec `--audit-policy-file` et envoyer les journaux à un système de journalisation externe et immuable.
Pourquoi: Fournit une piste essentielle, infalsifiable, pour l'enquête sur les incidents, la chasse aux menaces et les audits de conformité.
Réduire la surface d'attaque des nœuds de travail.
Définir les flags kubelet : `--anonymous-auth=false`, `--authorization-mode=Webhook` et `--read-only-port=0`.
Pourquoi: Ceci impose que toutes les requêtes à l'API kubelet soient authentifiées et autorisées par le serveur API et désactive le port en lecture seule non sécurisé et non authentifié.
Prévenir les fuites d'informations des composants du plan de contrôle.
Définir le flag `--profiling=false` sur kube-apiserver, kube-controller-manager et kube-scheduler en production.
Pourquoi: Les points de terminaison de profilage peuvent exposer des données de performance internes et des détails système qui pourraient aider un attaquant dans la reconnaissance.
Protéger les composants du plan de contrôle contre les accès réseau non autorisés.
Utiliser des règles de pare-feu (groupes de sécurité cloud, iptables) pour restreindre l'accès aux ports du serveur API (6443) et etcd (2379) aux sources fiables uniquement.
Pourquoi: Le contrôle d'accès au niveau du réseau est une couche de défense fondamentale, empêchant les attaquants d'atteindre les API de composants sensibles.
Accorder des permissions aux utilisateurs ou aux applications.
Utiliser des `Roles` limités à l'espace de noms plutôt que des `ClusterRoles`. Accorder des verbes spécifiques (`get`, `list`) au lieu de jokers (`*`).
Pourquoi: Suit le principe du moindre privilège, limitant la portée des permissions à ce qui est nécessaire au sein d'un espace de noms spécifique.
Un pod n'a pas besoin de communiquer avec l'API Kubernetes.
Définir `automountServiceAccountToken: false` dans la spécification du pod ou sur le ServiceAccount lui-même.
Pourquoi: Évite d'exposer des identifiants inutiles à l'intérieur du pod, réduisant la surface d'attaque si le pod est compromis.
Appliquer une posture de sécurité de base pour tous les pods dans un espace de noms.
Utiliser le contrôleur d'admission `PodSecurity` intégré en appliquant des étiquettes d'espace de noms comme `pod-security.kubernetes.io/enforce: baseline`.
Pourquoi: Fournit un moyen standardisé et intégré de prévenir les configurations de pods risquées (comme les conteneurs privilégiés) sans outils tiers.
Renforcer la sécurité individuelle des conteneurs pour prévenir l'escalade de privilèges.
Dans la spécification du pod, définir les champs `securityContext` : `runAsNonRoot: true`, `allowPrivilegeEscalation: false`, `readOnlyRootFilesystem: true`.
Pourquoi: Ces contrôles empêchent de s'exécuter en tant que root, bloquent les mécanismes d'obtention de nouveaux privilèges et rendent le système de fichiers du conteneur immuable, réduisant drastiquement l'impact d'une compromission.
Implémenter un modèle de réseau zéro-confiance au sein du cluster.
Appliquer une NetworkPolicy par défaut de type "refuser" à chaque espace de noms qui sélectionne tous les pods (`podSelector: {}`) et possède une liste de règles d'entrée/sortie vide.
Pourquoi: Le réseau Kubernetes est par défaut en mode "autoriser". Cette politique inverse le modèle en mode "refuser par défaut", forçant les développeurs à autoriser explicitement le trafic requis.
Autoriser le trafic uniquement entre des niveaux d'application spécifiques (par exemple, web-vers-api).
Créer des NetworkPolicies qui utilisent `podSelector` et `namespaceSelector` pour définir des règles d'entrée et de sortie granulaires basées sur des étiquettes.
Pourquoi: Empêche les mouvements latéraux par les attaquants en garantissant qu'un pod compromis ne peut communiquer qu'avec des pairs explicitement autorisés.
Un utilisateur a besoin de la permission d'exécuter `kubectl exec` dans des conteneurs pour le débogage.
Accorder le verbe `create` sur la sous-ressource `pods/exec` dans le Role ou ClusterRole pertinent.
Pourquoi: L'action `exec` est contrôlée de manière contre-intuitive par le verbe `create` car elle crée une nouvelle session d'exécution. C'est un point de confusion courant.
Un attaquant accède à un conteneur et tente de compromettre le nœud hôte.
Interdire les conteneurs privilégiés (`securityContext.privileged: false`), les espaces de noms hôtes (`hostNetwork`, `hostPID`) et le montage du socket Docker.
Pourquoi: Ces configurations brisent efficacement l'isolation des conteneurs, donnant à un conteneur compromis un accès de niveau root à l'hôte.
Prévenir le déploiement d'images conteneur avec des vulnérabilités connues ou du code malveillant.
Implémenter l'analyse d'images (par exemple, Trivy) et la vérification de signature d'images (par exemple, Cosign) dans le pipeline CI/CD et via le contrôle d'admission.
Pourquoi: Fournit une approche de défense en profondeur : l'analyse détecte les vulnérabilités connues, tandis que la signature vérifie l'intégrité et la provenance de l'image.
Un attaquant a compromis un pod et tente d'accéder à d'autres pods dans le cluster.
Implémenter des NetworkPolicies par défaut de type "refuser" et créer des règles d'autorisation spécifiques uniquement pour la communication pod-à-pod requise.
Pourquoi: Restreint le "champ de vision" d'un attaquant à partir d'un pod compromis, contenant la brèche et l'empêchant de se propager.
Empêcher un pod compromis de voler les identifiants IAM cloud du service de métadonnées d'instance.
Appliquer une NetworkPolicy de sortie par défaut de type "refuser" qui bloque explicitement le trafic vers l'adresse IP de métadonnées (par exemple, `169.254.169.254/32`).
Pourquoi: Ceci est un chemin d'attaque courant dans les environnements cloud. Bloquer ce chemin de sortie atténue le risque de vol d'identifiants IAM des pods.
Protection contre les attaques par déni de service ou de cryptojacking qui épuisent les ressources des nœuds.
Appliquer des objets `ResourceQuota` aux espaces de noms pour limiter l'utilisation totale des ressources et des objets `LimitRange` pour imposer des limites sur les pods individuels.
Pourquoi: Garantit qu'aucun locataire ou charge de travail ne peut priver les autres de ressources, assurant la stabilité et prévenant les abus.
Un attaquant tente de maintenir un accès à long terme à un cluster compromis.
Surveiller la création de `DaemonSets`, `CronJobs` ou de pods privilégiés inattendus. Restreindre les permissions de créer ces ressources.
Pourquoi: Les attaquants utilisent ces types de charges de travail pour s'assurer que leur code malveillant s'exécute de manière persistante, même si un nœud ou un pod est redémarré.
S'assurer que les images conteneur sont exemptes de vulnérabilités connues avant le déploiement.
Intégrer un scanner d'images comme Trivy, Clair ou Grype dans le pipeline CI/CD pour analyser les images et faire échouer la construction si des vulnérabilités critiques sont détectées.
Pourquoi: Automatise la détection précoce des vulnérabilités ("shift left"), empêchant le code vulnérable d'atteindre la production.
S'assurer que seules des images conteneur fiables et non modifiées sont déployées sur le cluster.
Signer les images avec un outil comme Cosign dans le pipeline CI. Utiliser un contrôleur d'admission de validation (par exemple, Kyverno, Gatekeeper) pour vérifier la signature au moment du déploiement.
Pourquoi: Fournit une preuve cryptographique de l'intégrité de l'image (elle n'a pas été altérée) et de sa provenance (elle provient d'une source fiable).
Détecter les activités malveillantes à l'intérieur d'un conteneur en cours d'exécution (par exemple, un shell lancé, un accès à des fichiers sensibles).
Déployer un outil de sécurité runtime comme Falco, qui utilise eBPF pour surveiller les appels système et alerter sur les comportements suspects basés sur un ensemble de règles défini.
Pourquoi: Fournit une visibilité sur l'activité runtime, que l'analyse statique et le contrôle d'admission ne peuvent pas voir. C'est crucial pour détecter les brèches actives.
Appliquer des politiques de sécurité personnalisées et spécifiques à l'organisation (par exemple, "toutes les images doivent provenir de notre registre d'entreprise").
Utiliser un moteur de politiques comme OPA Gatekeeper ou Kyverno en tant que contrôleur d'admission de validation pour appliquer des politiques écrites en Rego ou YAML.
Pourquoi: Permet une application flexible, déclarative et automatisée des politiques de sécurité qui vont au-delà des contrôles intégrés de Kubernetes.
Chiffrer et authentifier tout le trafic de service à service au sein du cluster.
Implémenter un service mesh (par exemple, Istio, Linkerd) pour fournir automatiquement mTLS pour tous les services maillés.
Pourquoi: Atteint le réseau zéro-confiance en garantissant que tout le trafic intra-cluster est chiffré et que les services vérifient mutuellement leur identité.
Exécuter des charges de travail non fiables ou multi-locataires qui nécessitent une isolation plus forte que les conteneurs standards.
Utiliser un runtime de conteneur en bac à sable comme gVisor ou Kata Containers, qui fournissent une couche d'isolation supplémentaire entre le conteneur et le noyau hôte.
Pourquoi: Réduit la surface d'attaque du noyau hôte, rendant l'évasion de conteneur significativement plus difficile.
Contrôle granulaire des permissions d'un conteneur au niveau du noyau.
Utiliser des profils Seccomp pour filtrer les appels système autorisés et des profils AppArmor/SELinux pour appliquer des contrôles d'accès obligatoires (MAC) sur l'accès aux fichiers et au réseau.
Pourquoi: Ces fonctionnalités de sécurité natives de Linux fournissent une couche de défense profonde, restreignant ce qu'un processus de conteneur compromis peut fondamentalement faire.
Réduire la surface d'attaque au sein d'une image conteneur.
Construire des images d'application en utilisant des images de base minimales ou "distroless" qui ne contiennent que l'application et ses dépendances directes.
Pourquoi: Supprime les shells, les gestionnaires de paquets et d'autres utilitaires qui sont inutiles en production et pourraient être utilisés par un attaquant après une compromission.
Vérifier qu'un cluster Kubernetes est configuré selon les meilleures pratiques de sécurité.
Exécuter régulièrement `kube-bench`, un outil automatisé qui vérifie la conformité du cluster par rapport au CIS Kubernetes Benchmark.
Pourquoi: Fournit un moyen standardisé, complet et automatisé d'auditer la posture de sécurité du cluster et d'identifier les mauvaises configurations.
Un cluster doit traiter et stocker des données de carte de crédit en conformité avec PCI DSS.
Utiliser des NetworkPolicies pour la segmentation réseau afin d'isoler l'environnement de données de titulaire de carte (CDE), et activer le chiffrement au repos pour etcd.
Pourquoi: Ces contrôles correspondent directement aux exigences PCI DSS pour la segmentation réseau (Exigence 1) et la protection des données de titulaire de carte stockées (Exigence 3).
Un cluster gère des informations de santé protégées (PHI) et doit être conforme à la loi HIPAA.
Implémenter un RBAC strict, activer une journalisation d'audit complète et s'assurer que les données sont chiffrées à la fois au repos et en transit.
Pourquoi: Ces contrôles répondent aux mesures de protection techniques de HIPAA pour le contrôle d'accès, les contrôles d'audit et la sécurité de la transmission.
S'assurer que les journaux d'audit sont préservés pour la conformité et la forensique, même si le cluster est compromis.
Configurer le serveur API pour diffuser les journaux d'audit vers un backend de journalisation externe, à écriture unique/immuable (par exemple, un SIEM ou un compartiment de stockage cloud sécurisé).
Pourquoi: Empêche un attaquant avec des privilèges cluster-admin de masquer ses traces en modifiant ou en supprimant les journaux d'audit locaux.
