Accueil · Guides de révision · CKS

Guide complet CKS — CNCF

Certified Kubernetes Security Specialist · Programme, plan de révision, ressources, examen blanc gratuit.

TL;DR — Le guide en 1 minute

Le CKS (Certified Kubernetes Security Specialist) s'adresse aux ingenieurs DevOps, SRE et specialistes securite cloud-native maitrisant deja Kubernetes. Format : examen pratique de 2 heures dans des clusters live, score requis 67%. Prerequis obligatoire : detenir une CKA active. Debouches : Kubernetes Security Engineer, Cloud Security Architect, Platform Engineer, avec des salaires depassant 75k EUR en France. Certification CNCF tres recherchee en 2026 avec l'explosion des deploiements Kubernetes en production et les exigences reglementaires NIS2 et DORA.

Pourquoi passer la certification CKS ?

Passer le CKS en 2026 represente un investissement strategique majeur pour tout professionnel cloud-native. Avec plus de 96% des entreprises utilisant ou evaluant Kubernetes selon la CNCF Survey 2025, la securisation des clusters est devenue critique. Les directives europeennes NIS2 et DORA imposent desormais des audits de securite stricts sur les infrastructures conteneurisees, creant une demande explosive pour des specialistes certifies. Le CKS est l'une des rares certifications 100% pratiques du marche : pas de QCM, uniquement des exercices reels dans des clusters live, ce qui garantit aux recruteurs une competence verifiee. Sur LinkedIn France, les offres mentionnant CKS ont augmente de 180% entre 2024 et 2026. Le ROI est rapide : l'investissement de 395 USD est generalement rentabilise en moins de trois mois grace aux augmentations salariales (entre 8 et 15%) constatees apres certification. Le CKS valorise particulierement les profils combinant DevSecOps, FinOps et Platform Engineering, trois domaines en forte tension. Enfin, la certification beneficie de la credibilite de la Linux Foundation et de la CNCF, references mondiales incontestees dans l'ecosysteme cloud-native, ce qui ouvre des opportunites a l'international, notamment dans les fintech et les scale-ups SaaS.

Caractéristiques de l'examen

Format Examen pratique (performance-based) dans clusters Kubernetes live
Duree 120 minutes
Score requis 67%
Prix officiel 395 USD (environ 365 EUR)
Langues Anglais uniquement (interface), surveillance multilingue
Validite 2 ans
Prerequis CKA (Certified Kubernetes Administrator) active obligatoire

Programme détaillé par domaine

Domain 1 : Cluster Setup 15%

Objectifs
Ce domaine couvre la configuration securisee initiale d'un cluster Kubernetes. Le candidat doit savoir appliquer les Network Policies pour restreindre le trafic est-ouest entre namespaces, utiliser le CIS Benchmark via kube-bench pour auditer la conformite, configurer l'Ingress avec TLS termine, proteger les metadonnees des nodes, verifier les binaires de la plateforme et securiser le kubelet. La maitrise des concepts de defense en profondeur appliques a l'infrastructure est essentielle pour reussir cette partie.
Concepts clés
NetworkPolicy (ingress/egress), CIS Kubernetes Benchmark, kube-bench, TLS Ingress avec cert-manager, mTLS, GUI elements securisation (dashboard), kubelet authentication/authorization (--anonymous-auth=false, --authorization-mode=Webhook), API server flags de securite, audit de binaires via sha256sum, restriction NodeRestriction admission plugin, isolation reseau via CNI (Calico, Cilium). Comprendre le modele de menaces Kubernetes et la matrice MITRE ATT&CK for Containers est un plus indeniable.
Services / outils
kube-bench, kube-hunter, Calico, Cilium, cert-manager, Trivy, OpenSSL pour audits TLS, etcd encryption, audit logging.
Temps estimé
12-15h

Domain 2 : Cluster Hardening 15%

Objectifs
Ce domaine porte sur le durcissement du cluster en restreignant l'acces a l'API Kubernetes. Le candidat doit configurer le RBAC finement (Roles, ClusterRoles, RoleBindings), gerer les ServiceAccounts en desactivant l'automount des tokens, mettre a jour Kubernetes frequemment pour appliquer les patches CVE, et restreindre l'expose de l'API. La granularite des permissions et le principe du moindre privilege sont au coeur de cette section.
Concepts clés
RBAC (Role, ClusterRole, RoleBinding, ClusterRoleBinding), principle of least privilege, ServiceAccount tokens (automountServiceAccountToken: false), upgrade avec kubeadm upgrade plan/apply, restriction acces API (anonymous-auth, basic-auth deprecated), bound service account tokens (TokenRequest API), audit policy YAML, separation namespace stricte. Connaitre les verbs RBAC (get, list, watch, create, update, patch, delete) et les resources (pods, deployments, secrets) est indispensable.
Services / outils
kubectl auth can-i, kubeadm, audit2rbac, rakkess pour visualiser les permissions.
Temps estimé
10-12h

Domain 3 : System Hardening 10%

Objectifs
Ce domaine couvre le durcissement du systeme d'exploitation hote et la minimisation de la surface d'attaque. Le candidat doit minimiser l'OS footprint (suppression packages inutiles), utiliser AppArmor ou SELinux pour confiner les processus, configurer les seccomp profiles pour filtrer les syscalls, et restreindre l'acces aux ressources kernel. La comprehension des mecanismes Linux de securite est primordiale.
Concepts clés
AppArmor profiles (annotations container.apparmor.security.beta.kubernetes.io), seccomp profiles (RuntimeDefault, Localhost), Linux capabilities (CAP_NET_ADMIN, drop ALL), syscalls dangereux, IAM roles pour nodes (cloud), restriction kernel modules, sysctls securises, suppression services systemd inutiles, fail2ban, mise a jour kernel reguliere. La syntaxe YAML pour appliquer ces profils aux Pods doit etre maitrisee sur le bout des doigts.
Services / outils
AppArmor, seccomp, SELinux, systemctl, auditd, Falco pour detection runtime.
Temps estimé
8-10h

Domain 4 : Minimize Microservice Vulnerabilities 20%

Objectifs
Ce domaine traite de la securisation des microservices au niveau Pod. Le candidat doit configurer les SecurityContext (runAsNonRoot, readOnlyRootFilesystem), implementer les Pod Security Standards (Restricted, Baseline, Privileged), gerer les Secrets de maniere securisee (chiffrement etcd, integration Vault), utiliser des runtimes isolees comme gVisor ou Kata Containers, et appliquer mTLS via service mesh.
Concepts clés
SecurityContext (runAsUser, runAsGroup, fsGroup, allowPrivilegeEscalation: false), Pod Security Admission (PSA) avec labels enforce/audit/warn, Secrets encryption at rest via EncryptionConfiguration, integration HashiCorp Vault avec CSI driver, RuntimeClass pour gVisor/Kata, mTLS via Istio ou Linkerd, OPA Gatekeeper pour policies admission. Les Pod Security Policies (PSP) sont depreciees depuis 1.25, donc PSA est la reference actuelle.
Services / outils
gVisor, Kata Containers, Istio, Linkerd, OPA Gatekeeper, Kyverno, HashiCorp Vault, sealed-secrets, SOPS.
Temps estimé
15-18h

Domain 5 : Supply Chain Security 20%

Objectifs
Ce domaine couvre la securite de la chaine d'approvisionnement logicielle. Le candidat doit minimiser la base d'image (distroless, scratch), securiser le supply chain (whitelist registries, signature images), utiliser des outils d'analyse statique sur les workloads utilisateurs, et scanner les images pour les vulnerabilites connues. La traçabilite SBOM (Software Bill of Materials) est aussi abordee.
Concepts clés
Distroless images, multi-stage builds Docker, ImagePolicyWebhook admission controller, signature via Cosign/Sigstore, scan vulnerabilites avec Trivy ou Grype, SBOM avec Syft, ValidatingAdmissionWebhook pour bloquer images non signees, registry privee securisee (Harbor), policy as code avec Kyverno. La comprehension de SLSA framework (Supply-chain Levels for Software Artifacts) est un atout majeur.
Services / outils
Trivy, Grype, Cosign, Sigstore, Syft, Harbor, Kyverno, Notary v2, distroless (gcr.io/distroless).
Temps estimé
12-15h

Domain 6 : Monitoring, Logging and Runtime Security 20%

Objectifs
Ce domaine traite de la detection des menaces en temps reel. Le candidat doit configurer Falco pour detecter les comportements anormaux, mettre en place l'audit logging Kubernetes, analyser les syscalls suspects, et investiguer les processus malveillants. La capacite a ecrire des regles Falco custom est testee en pratique.
Concepts clés
Falco rules syntax (YAML), audit policy Kubernetes (Stages: RequestReceived, ResponseStarted), behavioral analysis, container immutability (readOnlyRootFilesystem), tracing syscalls avec strace, forensics post-incident, integration SIEM, alerting Prometheus/Alertmanager. Les phases du cycle d'attaque (reconnaissance, initial access, persistence) doivent etre comprises.
Services / outils
Falco, Falcosidekick, Fluentd/Fluent Bit, Elasticsearch, Loki, Prometheus, Tracee, Tetragon.
Temps estimé
12-14h

Plan de révision hebdomadaire

Semaine 1 - Fondations : revoir les concepts CKA (RBAC, namespaces, networking), lire la documentation officielle Kubernetes sur la securite (kubernetes.io/docs/concepts/security/), installer un cluster local avec kind ou minikube pour pratiquer. Objectif : 15h. Semaine 2 - Cluster Setup et Hardening : approfondir NetworkPolicy avec Calico, executer kube-bench sur un cluster, configurer audit logging, pratiquer RBAC granulaire avec kubectl auth can-i. Realiser au minimum 20 exercices pratiques sur Killercoda. Objectif : 18h. Semaine 3 - System Hardening et Microservices : maitriser AppArmor et seccomp avec exemples concrets, configurer SecurityContext sur differents Pods, deployer gVisor comme RuntimeClass, integrer Vault avec CSI driver. Tester Pod Security Admission en mode enforce. Objectif : 20h. Semaine 4 - Supply Chain et Runtime : signer des images avec Cosign, scanner avec Trivy, ecrire 10 regles Falco custom, configurer ImagePolicyWebhook, deployer Kyverno avec policies restrictives. Realiser le premier examen blanc Killer.sh. Objectif : 20h. Semaine 5 - Examens blancs intensifs : passer les deux sessions Killer.sh incluses (essentielles, plus difficiles que l'examen reel), refaire les zones faibles, chronometrer chaque exercice a 5 minutes maximum, maitriser vim et kubectl explain pour rapidite. Semaine 6 - Revision finale : relire le killer.sh corrige, refaire les commandes raccourcies (alias k=kubectl, export do=--dry-run=client -o yaml), passer l'examen en etant repose. Conseil : reservez l'examen un mardi ou mercredi matin pour eviter la fatigue.

Besoin d'un planning sur mesure ? 30 jours · 60 jours · 90 jours

Ressources recommandées

Documentation officielle Kubernetes

Reference absolue, source primaire autorisee pendant l'examen.

Killer.sh CKS Simulator

Inclus avec l'inscription examen, deux sessions de 36h, simulateur le plus realiste.

KodeKloud CKS Course

Cours video complet avec labs interactifs et examens blancs.

CNCF Slack #cks-exam-prep

Communaute active d'aspirants et de certifies CKS pour echanger tips et ressources.

5 erreurs classiques à éviter

  • Erreur 1 : Sous-estimer la pression temporelle. 120 minutes pour 15-20 exercices pratiques, soit 6-8 minutes par tache. Solution : entrainer la rapidite avec les alias kubectl (k, kn, ks) et maitriser vim shortcuts.
  • Erreur 2 : Ne pas utiliser les bookmarks de la documentation. Pendant l'examen, l'acces a kubernetes.io est autorise. Preparer une liste de bookmarks vers NetworkPolicy, SecurityContext, Falco rules avant l'examen.
  • Erreur 3 : Oublier de changer de contexte. Chaque question utilise un cluster different. Toujours executer kubectl config use-context au debut de chaque exercice sous peine de modifier le mauvais cluster.
  • Erreur 4 : Negliger Falco et les regles custom. Beaucoup de candidats sous-estiment cette partie (20% du score). Pratiquer l'ecriture de regles Falco au format YAML et la lecture de logs Falco est crucial.
  • Erreur 5 : Ne pas passer le simulateur Killer.sh. Inclus dans le prix, il est volontairement plus difficile que l'examen reel. Le passer deux fois (avec 36h d'acces chacun) garantit une preparation optimale.

5 questions types corrigées

Q1. Vous devez creer une NetworkPolicy nommee 'deny-all-egress' dans le namespace 'production' qui bloque tout trafic sortant des Pods, sauf vers le DNS (port 53 UDP). Quelle configuration appliquer ?
Réponse : B
La reponse B est correcte. Une NetworkPolicy avec policyTypes: [Egress] et une regle egress autorisant explicitement le port 53 UDP vers le namespace kube-system (ou les pods CoreDNS) bloque tout autre trafic sortant. L'option A concerne uniquement l'ingress. L'option C bloque aussi le DNS. Les PodSecurityPolicy (D) sont depreciees depuis Kubernetes 1.25 et ne gerent pas le reseau. Toujours utiliser des selecteurs precis (namespaceSelector et podSelector) pour autoriser CoreDNS.
Q2. Quel SecurityContext applique le durcissement maximal recommande par les Pod Security Standards 'Restricted' ?
Réponse : B
La reponse B applique les controles essentiels du profil Restricted. runAsNonRoot empeche l'execution en root, readOnlyRootFilesystem garantit l'immutabilite, allowPrivilegeEscalation: false bloque setuid/setgid, et drop ALL capabilities supprime tous les privileges Linux. Il faut egalement ajouter seccompProfile.type: RuntimeDefault pour une conformite complete. Les options A et C accordent des privileges excessifs. L'option D est insuffisante car elle n'adresse pas l'utilisateur d'execution ni les capabilities. Ce SecurityContext est testable via Pod Security Admission en mode enforce.
Q3. Comment garantir qu'une image de container provient bien d'un registry de confiance avant deploiement dans Kubernetes ?
Réponse : B
La reponse B est correcte. Un ValidatingAdmissionWebhook (ou un ImagePolicyWebhook) couple a Cosign/Sigstore intercepte les requetes de creation de Pod et verifie la signature cryptographique de l'image. Si la signature est invalide ou absente, le deploiement est refuse. kubectl scan (A) n'existe pas comme commande native. runAsNonRoot (C) concerne l'utilisateur d'execution, pas la provenance. imagePullPolicy: Always (D) force le pull mais ne valide pas l'origine. Kyverno et OPA Gatekeeper sont les outils standards pour implementer ces policies declarativement avec verification SLSA.

Voir plus de questions gratuites →

Carrière & salaire après CKS

Le CKS ouvre des postes de Kubernetes Security Engineer, Cloud Security Architect et Platform Security Engineer. En France en 2026, les salaires constates sont : junior certifie CKS 55-65k EUR, senior 75-95k EUR, architecte 95-130k EUR. A Paris et Lyon, les fintech (Qonto, Lydia, Swile) et les scale-ups SaaS offrent les meilleures conditions, souvent avec BSPCE. En Europe (Amsterdam, Berlin, Dublin), les remunerations grimpent a 110-150k EUR. Le CKS se combine ideallement avec : CKA (prerequis), CKAD, HashiCorp Vault Associate, AWS Security Specialty ou Azure AZ-500. L'evolution naturelle mene vers des roles de Principal Engineer, Head of Platform Security ou consultant DevSecOps independant (TJM 800-1200 EUR). Avec NIS2 obligatoire, la demande continuera de croitre fortement jusqu'en 2028.

Détail des salaires CKS en 2026 →

FAQ — CKS

Combien de temps faut-il pour preparer CKS ?

Entre 6 et 10 semaines a raison de 15-20h hebdomadaires pour un candidat possedant deja le CKA. Sans experience prealable Kubernetes en production, comptez 3 a 4 mois de preparation intensive incluant labs quotidiens.

Cette certification est-elle reconnue en France ?

Oui, le CKS est largement reconnu en France et en Europe. La CNCF et la Linux Foundation sont des references mondiales. Les ESN (Capgemini, Sopra Steria, Accenture) et les editeurs cloud-native valorisent fortement cette certification.

Quel est le taux de reussite a CKS ?

Le taux de reussite estime est entre 40 et 50% au premier essai, ce qui en fait l'une des certifications Kubernetes les plus difficiles. Le format pratique sans QCM ne pardonne pas l'approximation. Le simulateur Killer.sh augmente significativement les chances de succes.

Quel est le salaire apres CKS ?

En France en 2026, un profil certifie CKS gagne entre 65k et 95k EUR selon experience. Les seniors avec 5+ ans d'experience Kubernetes atteignent 100-130k EUR. En freelance, le TJM oscille entre 700 et 1100 EUR.

Faut-il une experience prealable ?

Oui, le CKA est un prerequis obligatoire et doit etre actif. Minimum 2 ans d'experience Kubernetes en production est fortement recommande, ainsi qu'une comprehension solide de Linux, networking, TLS et conteneurs.

CKS ou cert concurrente : laquelle choisir ?

Le CKS est unique sur Kubernetes specifiquement. Pour cloud generique, AWS Security Specialty ou Azure AZ-500 sont complementaires, pas concurrentes. Le CKS reste la reference vendor-neutral pour la securite des clusters Kubernetes en environnement multi-cloud.

Combien coute l'examen CKS ?

395 USD (environ 365 EUR en 2026), incluant une tentative de rattrapage gratuite et l'acces au simulateur Killer.sh. Des promotions CNCF (jusqu'a 30% de reduction) sont frequentes via le code CYBERMONDAY ou lors des KubeCon.

Combien de fois peut-on repasser CKS ?

L'inscription inclut une tentative initiale plus une tentative de rattrapage gratuite. Au-dela, il faut racheter une licence complete a 395 USD. Aucune limite annuelle n'est imposee, mais respecter un delai de 14 jours entre tentatives est recommande.

Prêt à passer à la pratique ?

Lancez votre examen blanc gratuit ou faites le test d'orientation pour valider votre choix.

Démarrer l'examen blanc CKS → Test d'orientation