Un cluster Kubernetes fonctionnel n'est pas automatiquement un cluster sécurisé. Par défaut, Kubernetes n'applique pas un durcissement suffisant pour la production : les pods peuvent souvent communiquer librement, les Secrets ne sont pas chiffrés au repos sans configuration dédiée, et des permissions trop larges accordées aux ServiceAccounts exposent rapidement des ressources sensibles.
Ce module vous fait durcir un cluster de bout en bout, de la conformité de base aux politiques d'admission, puis jusqu'à la détection d'intrusion au runtime. Il s'adresse à des administrateurs qui connaissent déjà les objets de base, kubectl et l'administration d'un cluster (kubeadm, etcd), et il prolonge en grande partie les 6 domaines de la certification CKS (Certified Kubernetes Security Specialist).
Pourquoi sécuriser le cluster à ce moment du parcours ?
Section intitulée « Pourquoi sécuriser le cluster à ce moment du parcours ? »On ne durcit bien que ce que l'on sait installer et exploiter. Ce module vient donc après l'installation, l'administration et l'exploitation du cluster : vous avez déjà un cluster qui tourne, et vous savez ce qu'il contient. Il vient aussi après le module sur la sécurité des workloads, qui pose le socle du moindre privilège avec le Security Context, les ServiceAccounts et le RBAC. Ici, on ajoute les couches qui empêchent et détectent ce que ces droits seuls ne bloquent pas.
Le fil suit la défense en profondeur : chaque couche suppose que la précédente peut être contournée. C'est pourquoi le module ne se lit pas comme un catalogue d'outils, mais comme une pile qui va du cluster vers le conteneur, puis vers ce qui se passe pendant l'exécution.
Quel est le fil entre les leçons du module ?
Section intitulée « Quel est le fil entre les leçons du module ? »Le module commence par mesurer. Le CIS Benchmark donne une référence de durcissement du cluster et un audit avec kube-bench : sans cet état des lieux, on ne sait pas par où commencer.
Viennent ensuite les restrictions sur chaque pod, appliquées au niveau du noyau et du namespace. AppArmor et seccomp limitent ce qu'un conteneur peut faire côté noyau (fichiers, appels système), et les Pod Security Standards fixent trois niveaux de politique (Privileged, Baseline, Restricted) appliqués par namespace.
Le bloc le plus long traite de l'admission, c'est-à-dire du contrôle exercé avant qu'une ressource soit créée, pour refuser ce qui n'est pas conforme. Les Admission Controllers expliquent le mécanisme. Trois outils l'exploitent : les policies natives ValidatingAdmissionPolicy écrites en CEL, Kyverno avec des policies en YAML, et Gatekeeper avec OPA et Rego. La leçon de comparaison VAP, Kyverno et Gatekeeper clôt ce bloc et aide à choisir.
Le module passe ensuite au trafic et à la chaîne d'approvisionnement, avec des images de confiance. Le chiffrement pod-to-pod (mTLS avec Istio, ou WireGuard avec Cilium) protège les échanges internes, la leçon Supply Chain Security traite la provenance des images, et le scan d'images cherche les vulnérabilités connues avant déploiement.
Enfin, le module regarde ce qui se passe quand le workload tourne, avec la détection et l'isolation au runtime. Les audit logs enregistrent qui a fait quoi sur l'API, Falco détecte les comportements anormaux, la comparaison Falco et Tetragon oppose l'alerte à la prévention dans le noyau, et les runtime sandboxes (gVisor, Kata Containers) isolent les workloads les plus sensibles.
Quels thèmes se traitent hors de ce module ?
Section intitulée « Quels thèmes se traitent hors de ce module ? »Deux thèmes de sécurité vivent ailleurs dans le parcours, parce qu'ils appartiennent à des sujets plus larges. Le filtrage du trafic entre pods relève des Network Policies, traitées avec le réseau du cluster : le principe est un deny-all par défaut, puis des flux autorisés explicitement. Les Secrets ont leur propre leçon sur les Secrets Kubernetes, et les bonnes pratiques de gestion des secrets complètent le chiffrement at-rest dans etcd.
Pour élargir au-delà de Kubernetes, la page sur la sécurité des conteneurs traite le sujet pour tout moteur de conteneurs.
Ce module prépare-t-il à la certification CKS ?
Section intitulée « Ce module prépare-t-il à la certification CKS ? »Il en couvre une grande partie : le hardening du cluster, la sécurité des workloads, la supply chain, le runtime et l'audit. La CKS suppose d'avoir validé la CKA (ou une expérience équivalente). Le parcours CKS détaille les domaines d'examen et la stratégie, et le comparatif CKA, CKAD et CKS aide à choisir selon votre profil.
À retenir
Section intitulée « À retenir »La sécurité Kubernetes repose sur la défense en profondeur, et chaque couche de ce module répond à un risque précis :
- Mesure : le CIS Benchmark donne l'état des lieux du cluster.
- Workloads : AppArmor, seccomp et Pod Security Standards limitent chaque pod.
- Admission : VAP, Kyverno ou Gatekeeper bloquent les ressources non conformes avant leur création.
- Réseau et données : chiffrement pod-to-pod, Secrets chiffrés au repos, Network Policies.
- Chaîne d'approvisionnement : provenance et scan des images.
- Détection : audit logs activés, Falco ou Tetragon, sandboxes pour les workloads sensibles.