CKS (Spécialiste en Sécurité Kubernetes) : prérequis et plan d'étude de 6 semaines

Le CKS — Certified Kubernetes Security Specialist — est, à mon avis, le plus difficile des trois examens Kubernetes de niveau professionnel, plus restreint que le CKA et plus exigeant sous la pression du temps. Deux heures, pratique, 445 $, avec une reprise gratuite incluse. PSI Bridge, uniquement en ligne, pas de centres d'examen. La note de passage est de 67 %. La CNCF ne publie pas les taux de réussite officiels, mais le taux de réussite au premier essai, selon les sondages communautaires, se situe autour de 40 à 50 %, ce qui est inférieur à celui du CKA, et cela correspond à mon expérience en observant mes collègues le passer.

Ce que la plupart des gens oublient : vous ne pouvez pas simplement vous inscrire. La CNCF exige un CKA actif sur votre compte au moment de l'inscription. Pas « vous avez passé le CKA à un moment donné ». Actif. Si votre CKA a expiré (ce qui se produit désormais après 2 ans au lieu de 3 depuis le changement de politique du 1er avril 2024), vous devez le renouveler avant de pouvoir vous inscrire au CKS. Il s'agit d'une condition stricte, pas d'une simple recommandation, et elle surprend les gens chaque trimestre.

Les véritables prérequis

L'officiel : un CKA actif. C'est tout.

L'officieux :

• Maîtrise de kubectl au point de ne plus réfléchir à la syntaxe. Si vous cherchez encore « kubectl create deployment » sur Google, vous n'êtes pas prêt.
• Bases de Linux — vous vous connecterez en SSH aux nœuds, lirez les journaux systemd, modifierez les drapeaux kubelet et déboguerez les échecs de profils seccomp / AppArmor. Si journalctl -u kubelet ne vous est pas familier, commencez par y remédier.
• Maîtrise de vim. Pas de la sorcellerie Vim. Mais éditer du YAML dans vim en 2 heures sans perdre 30 secondes à « attendez, comment je sauvegarde déjà » est obligatoire.
• Un modèle mental fonctionnel de NetworkPolicy. C'est le plus grand obstacle de l'examen. Plus de détails ci-dessous.
• Un contact préalable avec Falco, Trivy, AppArmor, seccomp, mTLS via le service mesh et les Pod Security Standards. Vous n'avez pas besoin d'être un expert dans aucun d'entre eux ; vous devez les reconnaître.

Si vous manquez plus de deux de ces éléments, consacrez un mois supplémentaire aux exercices opérationnels de type CKA avant de vous attaquer au CKS. Tenter d'apprendre les opérations et la sécurité de Kubernetes simultanément sous la pression du temps est un chemin vers l'épuisement de la reprise gratuite.

Ce qui est réellement testé

Le programme de la CNCF le divise comme suit (les pourcentages changent à chaque révision du programme ; ceci est à jour début 2026) :

• Mise en place et durcissement du cluster (~15 %) : benchmarks CIS, kube-bench, restriction de l'accès externe, désactivation de l'authentification anonyme, drapeaux de durcissement kubelet.
• Durcissement du système (~15 %) : durcissement du noyau (seccomp, AppArmor), réduction de la surface d'attaque, minimisation de l'IAM côté cloud.
• Minimiser les vulnérabilités des microservices (~20 %) : Pod Security Standards (qui ont remplacé les PSPs en 1.25), jetons ServiceAccount, OPA / Gatekeeper ou Kyverno, mTLS.
• Sécurité de la chaîne d'approvisionnement (~20 %) : analyse d'images avec Trivy, signature avec cosign, contrôleurs d'admission qui bloquent les images non signées, bases du SBOM, minimisation des images de base.
• Surveillance, journalisation, sécurité d'exécution (~20 %) : règles Falco, analyse comportementale, immuabilité, journalisation d'audit au niveau du serveur API.
• Politique réseau (Network Policy) (~10 %) : default-deny, isolation des namespaces, règles d'egress. Listé comme un faible pourcentage, mais en pratique, toutes les autres catégories touchent aussi à NetworkPolicy.

L'examen ne teste pas le fonctionnement interne de Falco. Il teste votre capacité à écrire une règle Falco qui se déclenche lorsqu'un shell démarre dans un conteneur. L'examen ne teste pas la cryptographie de cosign. Il teste votre capacité à configurer un contrôleur d'admission pour rejeter les images non signées. Le travail est opérationnel, pas académique.

Le plan de 6 semaines

Cela suppose environ 10 heures par semaine avec un CKA actif déjà en poche. Adaptez si vous avez plus ou moins de temps.

Semaine 1 : NetworkPolicy jusqu'à l'épuisement.

Mettez en place un cluster kind localement avec Calico ou Cilium (le kindnet par défaut n'applique pas les NetworkPolicy, ce qui déroute les gens). Écrivez une politique default-deny pour un namespace. Écrivez une politique allow-from-namespace. Écrivez une politique d'egress qui autorise uniquement le DNS. Écrivez-en une qui autorise le trafic depuis un label de pod spécifique à travers les namespaces. Refaites tout cela de mémoire jusqu'à ce que vous puissiez les écrire dans vim sans consulter kubernetes.io. Le YAML de NetworkPolicy est le domaine de contenu le plus volumineux de l'examen et celui où la plupart des gens échouent. Passez plus de temps ici que vous ne pensez en avoir besoin.

Semaine 2 : Pod Security Standards, ServiceAccounts, renforcement du RBAC.

Appliquez les profils restricted, baseline et privileged aux namespaces. Configurez les ServiceAccounts avec automountServiceAccountToken: false. Créez un RBAC qui suit le principe du moindre privilège pour un déploiement qui doit lire des ConfigMaps dans son propre namespace et rien d'autre. Entraînez-vous à diagnostiquer « ce pod ne peut pas faire X à cause du RBAC » jusqu'à ce que le flux kubectl auth can-i devienne automatique.

Semaine 3 : Chaîne d'approvisionnement — Trivy, cosign, contrôle d'admission.

Scannez une image avec Trivy et interprétez la sortie CVE. Signez une image avec cosign. Configurez un ImagePolicyWebhook ou une politique Kyverno qui rejette les images non signées par votre clé. Mettez en place un registre OCI localement si vous voulez vous entraîner pleinement. L'examen vous fournira probablement Trivy installé ; vous devriez connaître ses drapeaux clés par cœur (--severity HIGH,CRITICAL, --ignore-unfixed).

Semaine 4 : Exécution — Falco, AppArmor, seccomp.

Installez Falco sur un cluster kind. Lisez les règles par défaut. Écrivez une règle personnalisée. Appliquez un profil AppArmor à un pod (l'examen vous donne généralement un profil déjà sur le nœud et vous demande de le connecter via une annotation — ce qui signifie connaître la syntaxe container.apparmor.security.beta.kubernetes.io/<container>: localhost/<profile>). Appliquez un profil seccomp via securityContext.seccompProfile. Ces deux éléments ont une syntaxe héritée basée sur les annotations et une syntaxe actuelle basée sur les champs ; l'examen a tendance à tester la syntaxe actuelle, mais vous devriez reconnaître les deux.

Semaine 5 : Durcissement du cluster et de l'hôte.

Exécutez kube-bench, interprétez les échecs, corrigez les plus faciles (authentification anonyme, journalisation d'audit, drapeaux kubelet). Configurez la politique d'audit sur le serveur API. Restreignez l'accès à etcd. Désactivez les ports kubelet inutiles. Il s'agit principalement de travail Linux au niveau des nœuds, et c'est là que les ingénieurs sans solides bases d'administrateur système ralentissent.

Semaine 6 : Killer Shell, simulations complètes et repos.

Utilisez les deux sessions Killer Shell incluses cette semaine. Elles sont intentionnellement plus difficiles que l'examen réel ; attendez-vous à obtenir un score inférieur à ce que vous espérez. Utilisez les lacunes pour étudier. Passez l'examen réel dans les 2-3 derniers jours de la semaine 6 pendant que la mémoire musculaire est fraîche. Ne le reportez pas — chaque semaine de délai vous fait perdre vos réflexes.

Dormez la nuit précédant l'examen. Ne passez pas une nuit blanche à étudier. Ne modifiez pas vos alias kubectl le jour de l'examen.

Les pièges qui posent problème

NetworkPolicy sous la pression du temps. Déjà mentionné et il est bon de le répéter. La structure YAML est impitoyable — une mauvaise indentation tue la politique silencieusement et le pod continue de router. Entraînez-vous dans vim jusqu'à ce que vous puissiez écrire un default-deny + selective allow par réflexe.

Oublier que NetworkPolicy nécessite un CNI qui l'applique. kindnet ne le fait pas. flannel (par défaut dans certaines configurations) ne le fait pas. Calico, Cilium, Weave le font. Assurez-vous que votre cluster de pratique exécute un CNI appliquant ces règles, sinon vous apprendrez les mauvaises leçons.

Confondre PSP et Pod Security Standards. Les PSPs ont été supprimés en 1.25 (il y a des années maintenant, mais l'ancien matériel de formation y fait toujours référence). Le mécanisme actuel est le Pod Security Admission avec les profils restricted, baseline, privileged appliqués via des labels de namespace. N'étudiez pas les PSPs.

Configuration du chiffrement au repos d'etcd. Testé souvent. Spécifiquement : éditer EncryptionConfiguration, redémarrer le serveur API avec le bon drapeau, et vérifier avec etcdctl get que la valeur est chiffrée. Pratiquez cela.

Le piège de l'onglet du navigateur. Vous êtes autorisé à consulter kubernetes.io, falco.org, app-armor.net, et quelques autres. Vous ne pouvez pas compter sur la recherche rapide sous la pression du temps. Mémorisez la structure. Utilisez l'onglet pour copier-coller des extraits spécifiques, pas pour apprendre la syntaxe.

Devriez-vous le passer ?

Passez le CKS si votre travail est ou sera la sécurité de plateforme, l'ingénierie de sécurité dans un environnement Kubernetes, ou le travail de conformité dans des secteurs réglementés. Ne le passez pas si vous êtes un ingénieur de plateforme généraliste — le CKA couvre ce dont la plupart des rôles généralistes ont besoin, et le CKS est un excès qui expire en 2 ans.

Si vous vous y lancez, parcourez la banque de questions CKS sur CertLabPro ou démarrez un examen chronométré. La couverture conceptuelle des banques de questions complète les répétitions opérationnelles que vous devez effectuer sur de vrais clusters. Les deux sont nécessaires ; ni l'un ni l'autre ne suffit seul.