La CKS valide votre capacité à sécuriser un cluster Kubernetes et ses workloads dans un environnement réel. Elle prolonge naturellement la CKA et se concentre sur six domaines : sécurité du cluster, durcissement système, sécurité des workloads, supply chain, admission et sécurité runtime.
Cette page est le hub de préparation CKS. Elle vous guide vers les ressources du site et vous donne une stratégie structurée pour réussir.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Ce que valide la CKS et en quoi elle diffère de CKA/CKAD
- Le format de l'examen et les conditions de passage
- Les 6 domaines du blueprint avec leur pondération officielle
- Ce que vous devez savoir faire sans hésiter le jour J
- Un plan de préparation sur 8 semaines avec les ressources du site
Ce que la CKS valide
Section intitulée « Ce que la CKS valide »La CKS certifie que vous êtes capable de sécuriser la plateforme Kubernetes et les workloads pendant tout leur cycle de vie : build, déploiement et runtime.
- Durcir le cluster (API Server, RBAC, ServiceAccounts, composants)
- Réduire la surface d'attaque (Seccomp, AppArmor, SecurityContext)
- Sécuriser les workloads (Pod Security Standards, admission, secrets)
- Protéger la supply chain (scan d'images, signature, admission controllers)
- Détecter et investiguer à l'exécution (audit logs, Falco, comportements suspects)
CKS = CKA + sécurité appliquée au build, au déploiement et au runtime.
Format de l'examen
Section intitulée « Format de l'examen »| Aspect | Valeur |
|---|---|
| Durée | 2 heures |
| Type | Examen pratique supervisé (performance-based) |
| Score minimum | 67% |
| Validité | 2 ans |
| Reprise | 1 retake inclus |
| Éligibilité | 12 mois pour passer l'examen après achat |
| Prix | 445 USD |
| Version Kubernetes | v1.35 (actuellement) |
| Prérequis | CKA réussie (active ou non) |
| Simulateur | 2 sessions incluses |
| Documentation autorisée | Ressources officiellement autorisées selon le handbook |
Les 6 domaines du blueprint
Section intitulée « Les 6 domaines du blueprint »Le blueprint officiel CNCF définit les domaines et leur pondération :
| Domaine | Poids | Ce que ça couvre |
|---|---|---|
| Cluster Setup | 15% | NetworkPolicies, CIS benchmarks, Ingress TLS |
| Cluster Hardening | 15% | RBAC, ServiceAccounts, API Server restrictions |
| System Hardening | 10% | Seccomp, AppArmor, réduction surface d'attaque |
| Minimize Microservice Vulnerabilities | 20% | SecurityContext, PSA, gestion secrets |
| Supply Chain Security | 20% | Scan images, signature, admission controllers |
| Monitoring, Logging and Runtime Security | 20% | Audit logs, Falco, détection runtime |
Ces pondérations bougent : la page officielle de la Linux Foundation fait foi et ne
coïncide pas toujours avec le dépôt cncf/curriculum, dont le PDF accuse parfois une
version de retard. Relisez-la avant de bâtir votre planning, et vérifiez au passage la
version de Kubernetes sur laquelle l'examen est aligné : l'environnement suit la
dernière version mineure sous quatre à huit semaines après sa sortie.
| Bloc | Temps conseillé |
|---|---|
| Minimize Vulnerabilities | 20% |
| Supply Chain Security | 20% |
| Runtime Security | 20% |
| Cluster Hardening | 15% |
| System Hardening | 10% |
| Cluster Setup | 15% |
Ce second tableau n'ajoute pas d'information nouvelle : il traduit les pondérations en répartition de votre temps de révision. L'idée est de résister à la tentation inverse, qui consiste à passer ses soirées sur les sujets qu'on aime déjà. Si vous venez de l'administration système, vous serez à l'aise sur le durcissement et perdrez vos points sur la supply chain ; si vous venez du développement, ce sera l'inverse.
Ce que vous devez savoir faire sans hésiter
Section intitulée « Ce que vous devez savoir faire sans hésiter »Le jour de l'examen, ces actions doivent être automatiques :
Sécurité des workloads
Section intitulée « Sécurité des workloads »C'est le bloc qui revient le plus souvent, sous des formulations variées. Le réflexe à acquérir n'est pas d'apprendre les champs par coeur mais de savoir partir d'un manifeste existant et le durcir champ par champ, parce que l'examen vous donne presque toujours un Pod déjà déployé à corriger plutôt qu'une page blanche.
- Lire et corriger un SecurityContext (runAsNonRoot, readOnlyRootFilesystem, capabilities)
- Appliquer Pod Security Standards sur un namespace (labels PSA)
- Vérifier les permissions d'un ServiceAccount (
kubectl auth can-i) - Configurer le chiffrement des Secrets dans etcd
Contrôle d'accès
Section intitulée « Contrôle d'accès »Le piège classique du RBAC en examen est de créer un Role correct mais de le lier au
mauvais sujet, ou d'utiliser un ClusterRoleBinding là où un RoleBinding était
attendu. Prenez l'habitude de terminer chaque tâche RBAC par une vérification avec
kubectl auth can-i, qui donne la réponse en une seconde.
- Créer des Roles/ClusterRoles avec moindre privilège
- Identifier les permissions excessives dans un cluster
- Restreindre l'accès à l'API Server
- Désactiver l'auto-montage des tokens ServiceAccount
Supply chain
Section intitulée « Supply chain »Ces quatre points forment une chaîne : on scanne l'image, on la signe, on la référence par digest pour qu'elle ne puisse plus changer sous le même nom, et on fait refuser le reste par un contrôleur d'admission. Le point le plus souvent bâclé est le dernier : savoir scanner ne rapporte aucun point si rien n'empêche l'image vulnérable d'être déployée quand même.
- Scanner une image avec Trivy et interpréter les résultats
- Configurer une admission policy pour bloquer les images non conformes
- Utiliser des digests au lieu de tags
- Signer et vérifier une image avec Cosign
Runtime et audit
Section intitulée « Runtime et audit »Ce bloc mesure votre capacité à investiguer après coup, pas à empêcher. La difficulté est rarement conceptuelle : elle tient au volume. Un journal d'audit brut est illisible sans filtrage, et l'exercice consiste presque toujours à réduire ce flux à la poignée d'événements qui répondent à la question posée.
- Lire et interpréter les audit logs Kubernetes
- Configurer une politique d'audit
- Identifier un comportement suspect dans les logs Falco
- Créer une NetworkPolicy deny-all puis autoriser le trafic nécessaire
Ce que la CKS ne demande pas
Section intitulée « Ce que la CKS ne demande pas »Pour ne pas vous disperser, voici ce qui est hors scope :
- Développement applicatif → CKAD
- Installation kubeadm complète → déjà couvert en CKA
- Provisioning d'infrastructure → hors scope
- Hardening OS avancé (kernel tuning, SELinux policies) → limité aux bases
- Outils de sécurité avancés non standards → focus sur les primitives K8s
La CKS valide une vision end-to-end de la sécurité Kubernetes, pas une expertise pointue sur un outil spécifique.
Socle minimum avant de commencer
Section intitulée « Socle minimum avant de commencer »Avant d'attaquer la préparation CKS, assurez-vous de maîtriser :
-
CKA réussie
C'est le prérequis officiel. Vous devez être à l'aise avec l'administration d'un cluster Kubernetes.
-
Bon niveau Linux
Lecture de fichiers de configuration, navigation filesystem, commandes système de base.
-
kubectl fluide
Création, modification, inspection de ressources, l'autocomplétion doit être naturelle.
-
RBAC et NetworkPolicies maîtrisés
Ces concepts CKA sont fondamentaux pour la CKS. Révisez-les si besoin.
-
Compréhension de l'architecture cluster
API Server, etcd, kubelet, composants du control plane, vous devez savoir où se configure quoi.
Plan de préparation (8 semaines)
Section intitulée « Plan de préparation (8 semaines) »Semaines 1-2 : Révisions CKA + Pod Security
Section intitulée « Semaines 1-2 : Révisions CKA + Pod Security »Objectif : Consolider les bases CKA et découvrir Pod Security Standards.
Ce que vous devez faire :
- Revoir RBAC (Roles, ClusterRoles, bindings)
- Revoir NetworkPolicies (default deny, autorisation sélective)
- Comprendre SecurityContext (runAsNonRoot, capabilities)
- Lire la documentation Pod Security Standards
- Revoir la gestion des ServiceAccounts et des Secrets
- Installer un lab local (Kind + Falco + Trivy)
Critère de validation : Créer un RBAC complet (Role + Binding + ServiceAccount) et une NetworkPolicy deny-all en moins de 5 minutes.
Guides du site :
Semaines 3-4 : Cluster & System Hardening (30%)
Section intitulée « Semaines 3-4 : Cluster & System Hardening (30%) »Objectif : Durcir le cluster et le système.
Ce que vous devez faire :
- Configurer SecurityContext sur les Pods (runAsNonRoot, capabilities)
- Appliquer PSA sur des namespaces (labels enforce/warn)
- Scanner le cluster avec kube-bench (CIS Benchmark)
- Configurer le chiffrement des Secrets dans etcd
- Comprendre Seccomp et AppArmor
- Écrire des Validating Admission Policies
- Comparer les solutions d'admission (VAP, Kyverno, Gatekeeper)
Critère de validation : Appliquer PSA Restricted sur un namespace et scanner le cluster CIS Benchmark sans erreur critique.
Guides du site :
Semaines 5-6 : Supply Chain + Runtime Security (40%)
Section intitulée « Semaines 5-6 : Supply Chain + Runtime Security (40%) »Ce sont les domaines les plus lourds. Passez plus de temps ici.
Ce que vous devez faire :
- Scanner des images avec Trivy et interpréter les CVE
- Utiliser des digests au lieu de tags
- Comprendre la signature d'images (Cosign)
- Configurer les audit logs Kubernetes
- Installer et manipuler Falco
- Analyser des alertes de sécurité runtime
- Comprendre la supply chain de bout en bout (build → registry → deploy)
Critère de validation : Scanner une image, identifier une CVE critique, et configurer une politique d'admission qui bloque les images non scannées.
Guides du site :
Outils à manipuler :
trivy image, scan de vulnérabilitéstrivy k8s, audit du clusterkube-bench, CIS Benchmarkcosign, signature d'imagesfalco, détection runtime
Semaines 7-8 : Simulations et révisions
Section intitulée « Semaines 7-8 : Simulations et révisions »Objectif : Valider votre niveau avec les simulateurs.
Ce que vous devez faire :
- Passer les 2 simulations incluses avec l'inscription
- Chronométrer chaque exercice
- Identifier vos points faibles et les retravailler
- Optimiser votre workflow (alias, autocomplétion)
Critère de validation : Score > 75% sur les simulateurs.
Checklist finale :
- Alias
k=kubectlconfiguré - Autocomplétion activée
- SecurityContext maîtrisé
- PSA labels mémorisés
- Trivy et kube-bench manipulés
- Audit logs compris
Configuration initiale le jour J
Section intitulée « Configuration initiale le jour J »Dès le début de l'examen, configurez votre environnement :
# Alias indispensablesalias k=kubectlalias kn='kubectl config set-context --current --namespace'export do="--dry-run=client -o yaml"
# Autocomplétionsource <(kubectl completion bash)complete -F __start_kubectl k
# Vérifier le contexte actuelkubectl config current-contextkubectl config get-contextsCommandes les plus rentables
Section intitulée « Commandes les plus rentables »Ce bloc n'est pas à apprendre par coeur : c'est une liste des gestes de vérification
qui font gagner des points parce qu'ils confirment qu'une tâche est réellement terminée.
Repérez surtout les commandes de contrôle (auth can-i, describe netpol, la lecture
brute d'etcd) : sur un examen chronométré, la principale cause de perte de points n'est
pas l'ignorance mais l'oubli de vérifier ce qu'on vient d'appliquer.
# RBAC : vérifier les permissionsk auth can-i --list --as=system:serviceaccount:ns:sak auth can-i create pods --as=user@example.com
# Pod Security : appliquer PSA sur un namespacek label ns production pod-security.kubernetes.io/enforce=restrictedk label ns production pod-security.kubernetes.io/warn=restricted
# SecurityContext : générer un Pod sécurisék run secure-pod --image=nginx $do | \ yq '.spec.containers[0].securityContext = {"runAsNonRoot": true, "readOnlyRootFilesystem": true}'
# Scan d'imagestrivy image nginx:1.28trivy k8s --report summary
# Audit : vérifier la politique d'auditcat /etc/kubernetes/audit-policy.yamlk -n kube-system logs -l component=kube-apiserver | grep audit
# Secrets : vérifier le chiffrement etcdk get secret -n kube-system -o json | jq '.items[0].data'ETCDCTL_API=3 etcdctl get /registry/secrets/default/mysecret | hexdump -C | head
# NetworkPolicies : deny-all puis autoriserk create -f deny-all.yamlk describe netpol -n production
# CIS Benchmarkkube-bench run --targets=masterkube-bench run --targets=nodeOutils à maîtriser
Section intitulée « Outils à maîtriser »Aucun de ces outils ne demande une expertise poussée, mais chacun doit être lancé sans
consulter sa documentation. La colonne de droite indique le geste exact attendu :
trivy pour repérer une vulnérabilité, kube-bench pour situer le cluster face au
CIS Benchmark, cosign pour établir la provenance d'une image. jq est le seul de la
liste qui n'est pas un outil de sécurité, mais c'est celui qui vous fera gagner le plus
de temps sur les sorties JSON.
| Outil | Usage CKS |
|---|---|
| kubectl | Administration, RBAC, inspection |
| jq | Parsing des sorties JSON |
| trivy | Scan d'images et de clusters |
| kube-bench | Vérification CIS Benchmark |
| cosign | Signature et vérification d'images |
| falco | Détection runtime (selon le lab) |
Pièges à éviter
Section intitulée « Pièges à éviter »Lisez la colonne « Solution » plutôt que la colonne « Piège » : ces six lignes décrivent des habitudes à installer pendant l'entraînement, pas des consignes à se rappeler le jour J. Sous pression, on n'applique que ce qui est devenu automatique. Les deux premières lignes coûtent le plus cher, parce qu'une contrainte de sécurité manquée invalide toute la réponse même quand le reste est juste.
| Piège | Conséquence | Solution |
|---|---|---|
| Ne pas lire l'énoncé en entier | Vous oubliez une contrainte de sécurité | Lisez TOUT, notez les exigences |
| Bloquer sur une question | Vous perdez du temps précieux | Passez après 10 minutes, revenez après |
| Appliquer une policy sans tester | Vous bloquez le workload | Utilisez --dry-run=server d'abord |
| Oublier de vérifier vos réponses | Erreurs non détectées | Un kubectl get rapide pour confirmer |
| Ignorer les audit logs | Vous ne savez pas investiguer | Pratiquez la lecture des logs |
| Oublier de changer de contexte | Vous travaillez sur le mauvais cluster | Vérifiez le contexte à chaque question |
Différences avec CKA et CKAD
Section intitulée « Différences avec CKA et CKAD »Ce tableau se lit ligne par ligne, de haut en bas : les premières lignes décrivent le cadre administratif, les suivantes montrent la progression réelle du niveau attendu sur un même sujet. Les deux dernières lignes techniques sont les plus parlantes : supply chain et runtime security n'apparaissent tout simplement pas dans les deux autres certifications. C'est là que se joue l'écart de préparation, pas dans le RBAC que vous connaissez déjà.
| Aspect | CKAD | CKA | CKS |
|---|---|---|---|
| Focus | Applications | Cluster | Sécurité |
| Prérequis | Aucun | Aucun | CKA réussie |
| Score minimum | 66% | 66% | 67% |
| RBAC | Basique | Complet | Avancé + audit |
| NetworkPolicies | Basiques | Couvert | Avancées + isolation |
| Secrets | Usage | Usage | + Chiffrement etcd |
| Supply chain | Non couvert | Non couvert | Scan, signature, admission |
| Runtime security | Non couvert | Bases | Audit, Falco, détection |
| Public cible | Développeurs | Administrateurs | Security engineers |
Ressources recommandées
Section intitulée « Ressources recommandées »Simulateurs et cours
Section intitulée « Simulateurs et cours »Le simulateur Killer.sh est fourni avec l'inscription et se joue en deux sessions. Gardez-les pour la fin de la préparation : il est calibré nettement plus difficile que l'examen réel, et l'utiliser trop tôt donne surtout une impression décourageante sans vous apprendre grand-chose. Chaque session ouvre un accès prolongé après la tentative, et c'est en relisant les corrections que vous progresserez le plus.
- Killer.sh, 2 simulations incluses avec l'inscription (utilisez-les en semaines 7-8)
- KodeKloud CKS, Cours structuré avec labs pratiques
Documentation officielle
Section intitulée « Documentation officielle »Ces quatre pages font partie de la documentation consultable pendant l'examen. Il ne s'agit donc pas de les mémoriser mais de savoir y retrouver un exemple en moins d'une minute. Entraînez-vous à la navigation autant qu'au contenu : repérez à l'avance où se trouvent le manifeste de politique d'audit et les labels Pod Security Standards, ce sont les deux blocs que vous recopierez le plus souvent.
Environnement de pratique
Section intitulée « Environnement de pratique »Montez ce lab avant même de commencer le programme de huit semaines. Le point important est d'avoir un cluster que vous pouvez casser puis recréer en une commande : une bonne partie des exercices CKS consiste à modifier les manifestes statiques du control plane, et un cluster jetable évite de bloquer votre progression sur une API Server qui ne redémarre plus.
- Kind, Cluster local pour expérimenter
- kube-bench, Scanner CIS Benchmark
- Trivy, Scanner de vulnérabilités
- Falco, Détection runtime
À retenir
Section intitulée « À retenir »- CKS = CKA + sécurité : consolidez vos bases avant de passer
- 60% sur 3 domaines : Minimize Vulnerabilities, Supply Chain, Runtime
- Score minimum 67% contre 66% pour CKA/CKAD
- CKA réussie obligatoire (mais pas forcément active)
- Validité 2 ans, 1 retake inclus, vous avez le droit à l'erreur
- Utilisez les 2 simulations avant l'examen réel
- Maîtrisez SecurityContext et PSA, ils reviennent constamment
- Pratiquez Trivy et les audit logs, domaines à 20%
Pour aller plus loin
Section intitulée « Pour aller plus loin »- Exercices chronométrés CKS : Des scénarios de durcissement minutés au format de l'examen.