CKS, Guide de préparation complet

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

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

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

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	`kubernetes.io/docs`, `kubernetes.io/blog`, `falco.org/docs`, `etcd.io/docs`, `docs.cilium.io`, `istio.io/latest/docs`, `kubernetes.github.io/ingress-nginx`, `kubernetes-sigs.github.io/bom`

Il n'y a aucun QCM : deux heures devant un terminal, à durcir et diagnostiquer des clusters réels. La CKS pousse d'ailleurs cette logique plus loin que ses aînées, puisque plusieurs tâches consistent à réparer une configuration volontairement affaiblie plutôt qu'à en écrire une.

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, métadonnées du nœud, vérification des binaires
Cluster Hardening	15%	RBAC, ServiceAccounts, API Server restrictions
System Hardening	10%	Seccomp, AppArmor, surface de l'OS hôte, IAM au moindre privilège, accès réseau externe
Minimize Microservice Vulnerabilities	20%	SecurityContext, PSA, gestion secrets, chiffrement pod-to-pod
Supply Chain Security	20%	Scan images, signature, admission controllers, analyse statique des manifestes
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.

Une lecture s'impose sur ce tableau : trois domaines à 20 % pèsent 60 % à eux seuls, Minimize Microservice Vulnerabilities, Supply Chain Security et Monitoring, Logging and Runtime Security. Les trois autres se partagent le reste. Si votre temps est compté, c'est là qu'il faut le mettre.

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.

Commandes essentielles CKS Référence complète des commandes de sécurité

Ce que vous devez savoir faire sans hésiter

Le jour de l'examen, ces actions doivent être automatiques :

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

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

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

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

Les compétences que l'on oublie de réviser

Quatre lignes du blueprint passent sous le radar de la plupart des préparations, parce qu'elles ne ressemblent pas au reste. Elles rapportent pourtant des points, et la formation les enseigne : cette page dit seulement où les trouver.

Ce que le blueprint demande	Domaine	Où l'apprendre
Protéger les métadonnées et points d'accès du nœud	Cluster Setup	NetworkPolicies
Vérifier les binaires de la plateforme	Cluster Setup	Supply chain
Analyse statique des workloads, Kubesec et KubeLinter	Supply Chain	Supply chain
Chiffrement pod-to-pod, Cilium et Istio	Minimize Vuln.	mTLS pod-to-pod

Trois réflexes valent des points sur ces sujets, et ils se retiennent seuls. Le champ except d'un ipBlock est le seul moyen d'exprimer « tout sauf » dans une NetworkPolicy. Un bloc egress refuse tout ce qui n'y figure pas, DNS compris, ce qui explique presque tous les Pods qui ne résolvent plus rien après la pose d'une politique. Et le code d'échec de kubesec vaut 2, jamais 1, comme celui de grype.

Ce qui reste hors de portée d'un cluster local

Trois lignes du domaine System Hardening portent sur ce qui entoure Kubernetes plutôt que sur Kubernetes : Minimize host OS footprint, Using least-privilege identity and access management, Minimize external access to the network. L'examen attend que vous sachiez retirer un service inutile d'un nœud, restreindre les droits d'une identité de plateforme et fermer les ports ouverts sans raison.

Ces trois points ne se démontrent pas sur un cluster en conteneur, qui partage le noyau et le système de l'hôte. Ils se travaillent sur une machine virtuelle, et le site les couvre du côté durcissement système.

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, mais la réduction de la surface de l'hôte, elle, est bien au programme
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

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)

Huit semaines plutôt que six, et ce n'est pas une marge de confort : la CKS suppose acquis tout le programme de la CKA, et y ajoute des outils que la plupart des administrateurs n'ont jamais manipulés, Falco, Trivy, AppArmor, seccomp. Chaque semaine se termine par une manipulation, jamais par une lecture.

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 :

RBAC Kubernetes Contrôle d'accès basé sur les rôles

Network Policies Isolation réseau pod-to-pod

Pod Security Standards Privileged, Baseline, Restricted

Security Context runAsNonRoot, capabilities, readOnlyRootFilesystem

Secrets Kubernetes Gestion sécurisée des données sensibles

ServiceAccounts Identité des Pods et auto-montage des tokens

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 :

Supply Chain Security Sécuriser la chaîne d'approvisionnement de bout en bout

Image Scanning Scanner les images conteneurs pour détecter les CVE

Trivy Scanner de vulnérabilités images et clusters

Audit Logs Kubernetes Configurer et analyser les logs d'audit

Falco Détection runtime des comportements suspects

Kyverno Bloquer les images non conformes via admission

Outils à manipuler :

trivy image, scan de vulnérabilités
trivy k8s, audit du cluster
kube-bench, CIS Benchmark
cosign, signature d'images
falco, détection runtime

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 :

Commandes essentielles CKS Référence complète

Labs CKS Entraînement chronométré

Configuration initiale le jour J

Dès le début de l'examen, configurez votre environnement :

# Alias indispensables
alias k=kubectl
alias kn='kubectl config set-context --current --namespace'
export do="--dry-run=client -o yaml"

# Autocomplétion
source <(kubectl completion bash)
complete -F __start_kubectl k

# Vérifier le contexte actuel
kubectl config current-context
kubectl config get-contexts

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 permissions
k auth can-i --list --as=system:serviceaccount:ns:sa
k auth can-i create pods --as=user@example.com

# Pod Security : appliquer PSA sur un namespace
k label ns production pod-security.kubernetes.io/enforce=restricted
k label ns production pod-security.kubernetes.io/warn=restricted

# SecurityContext : générer un Pod sécurisé
k run secure-pod --image=nginx:1.28 $do | \
  yq '.spec.containers[0].securityContext = {"runAsNonRoot": true, "readOnlyRootFilesystem": true}'

# Scan d'images
trivy image nginx:1.28
trivy k8s --report summary

# Audit : vérifier la politique d'audit
cat /etc/kubernetes/audit-policy.yaml
k -n kube-system logs -l component=kube-apiserver | grep audit

# Secrets : vérifier le chiffrement etcd
k get secret -n kube-system -o json | jq '.items[0].data'
etcdctl get /registry/secrets/default/mysecret | hexdump -C | head

# NetworkPolicies : deny-all puis autoriser
k create -f deny-all.yaml
k describe netpol -n production

# CIS Benchmark
kube-bench run --targets=master
kube-bench run --targets=node

Une commande mérite d'être citée à part, kubectl auth can-i : elle répond par oui ou non à « ai-je le droit de faire ceci », et avec --as elle répond pour quelqu'un d'autre. C'est le moyen le plus rapide de vérifier qu'un RBAC fait bien ce qu'on croit, plutôt que de le relire.

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
kubesec	Note un manifeste, échoue en 2 sous le seuil
kube-linter	Énumère les défauts d'un manifeste, échoue en 1
sha256sum	Vérifie un binaire de plateforme avant déploiement
falco	Détection runtime (selon le lab)

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

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

Comparer CKA, CKAD et CKS Choisir la certification adaptée à votre profil

Ressources recommandées

La CKS se distingue des deux autres sur un point : sa documentation autorisée déborde kubernetes.io pour couvrir les sites des outils qu'elle interroge, notamment falco.org, docs.cilium.io, istio.io et etcd.io. Savoir y naviguer fait donc partie de la préparation, au même titre que les commandes. Une règle mérite d'être connue avant le jour J : la recherche de kubernetes.io/docs est autorisée, mais ouvrir un résultat qui pointe hors du domaine autorisé ne l'est pas.

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

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

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

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%

Contrôle de connaissances

Sept questions sur ce qui distingue la CKS des deux autres : son prérequis, ses six domaines dont trois pèsent 60 %, et sa documentation autorisée qui déborde kubernetes.io.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

7 questions

5 min.

80% requis

Informations

Le chronomètre démarre au clic sur Démarrer
Questions à choix multiples, vrai/faux et réponses courtes
Vous pouvez naviguer entre les questions
Les résultats détaillés sont affichés à la fin

Pour aller plus loin

Exercices chronométrés CKS : Des scénarios de durcissement minutés au format de l'examen.

CKS, Guide de préparation complet

Ce que vous allez apprendre

Ce que la CKS valide

Format de l'examen

Les 6 domaines du blueprint

Ce que vous devez savoir faire sans hésiter

Sécurité des workloads

Contrôle d'accès

Supply chain

Runtime et audit

Les compétences que l'on oublie de réviser

Ce qui reste hors de portée d'un cluster local

Ce que la CKS ne demande pas

Socle minimum avant de commencer

Plan de préparation (8 semaines)

Semaines 1-2 : Révisions CKA + Pod Security

Semaines 3-4 : Cluster & System Hardening (30%)

Semaines 5-6 : Supply Chain + Runtime Security (40%)

Semaines 7-8 : Simulations et révisions

Configuration initiale le jour J

Commandes les plus rentables

Outils à maîtriser

Pièges à éviter

Différences avec CKA et CKAD

Ressources recommandées

Simulateurs et cours

Documentation officielle

Environnement de pratique

À retenir

Contrôle de connaissances

Contrôle de connaissances

Informations

Vérification

Profil de compétences

Quoi faire maintenant

Pour aller plus loin