La KCSA valide votre compréhension fondamentale de la sécurité Kubernetes et cloud native. C’est la certification associate orientée sécurité de la CNCF/Linux Foundation : un examen théorique (QCM), en ligne et supervisé, conçu pour vérifier que vous comprenez les contrôles de base, les menaces courantes et les bonnes pratiques de sécurisation d’un cluster Kubernetes et de sa plateforme. Elle complète naturellement la KCNA et prépare la montée vers la CKS.
Cette page est le hub de préparation KCSA. Elle vous guide à travers les domaines de l’examen, les ressources du site et 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 KCSA et comment elle se positionne par rapport à KCNA, CKA et CKS
- Le format de l’examen et les informations à connaître
- Les 6 domaines du blueprint avec leur pondération officielle
- Les concepts de sécurité à maîtriser pour chaque domaine
- Un plan de préparation sur 4 semaines avec les ressources du site
Ce que la KCSA valide
Section intitulée « Ce que la KCSA valide »La KCSA (Kubernetes and Cloud Native Security Associate) certifie que vous comprenez les fondamentaux de la sécurité Kubernetes et cloud native :
- Les bases de la sécurité cloud native : identité, contrôle d’accès, défense en profondeur, responsabilité partagée
- La sécurité des composants du cluster : API server, etcd, kubelet, admission, authentification
- Les fondamentaux de sécurité Kubernetes : RBAC, ServiceAccounts, Secrets, NetworkPolicies, SecurityContext
- Le modèle de menace Kubernetes : surfaces d’attaque, supply chain, exposition réseau, escalade de privilèges
- La sécurité de plateforme : images, runtime, réseau, observabilité sécurité, service mesh, PKI
- La conformité et les frameworks : CIS Benchmark, posture, audit, policy-as-code, outillage d’automatisation
Pourquoi passer la KCSA ?
Section intitulée « Pourquoi passer la KCSA ? »La KCSA remplit un rôle précis dans le parcours de certification cloud native :
| Situation | Ce que la KCSA vous apporte |
|---|---|
| Vous avez déjà la KCNA | Une spécialisation associate orientée sécurité |
| Vous travaillez en plateforme / DevSecOps | Une validation structurée des fondamentaux sécurité |
| Vous préparez la CKS à moyen terme | Un socle conceptuel solide avant la pratique |
| Vous êtes architecte ou RSSI technique | Une preuve de compréhension de la sécurité cloud native |
| Vous sécurisez déjà Kubernetes sans cadre clair | Une carte mentale des contrôles à connaître |
Format de l’examen
Section intitulée « Format de l’examen »| Aspect | Valeur |
|---|---|
| Type | QCM en ligne, supervisé (proctored) |
| Prix | 250 USD |
| Reprise | 1 retake inclus |
| Domaines | 6 domaines officiels |
| Niveau | Associate / débutant avancé |
| Pré-requis | Aucun prérequis formel |
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 |
|---|---|---|
| Overview of Cloud Native Security | 14% | Principes de sécurité cloud native, identité, supply chain, observabilité, service mesh |
| Kubernetes Cluster Component Security | 22% | API server, etcd, kubelet, admission, composants critiques |
| Kubernetes Security Fundamentals | 22% | RBAC, ServiceAccounts, Secrets, SecurityContext, NetworkPolicies |
| Kubernetes Threat Model | 16% | Menaces, surfaces d’attaque, supply chain, multi-tenancy, compromission |
| Platform Security | 16% | Sécurité d’image, runtime, PKI, connectivité, admission control |
| Compliance and Security Frameworks | 10% | CIS, conformité, frameworks, automatisation, policy-as-code |
Domaine 1 : Overview of Cloud Native Security (14%)
Section intitulée « Domaine 1 : Overview of Cloud Native Security (14%) »Ce domaine vérifie que vous comprenez les grands principes de la sécurité cloud native.
Ce que vous devez maîtriser
Section intitulée « Ce que vous devez maîtriser »- Défense en profondeur
- Responsabilité partagée
- Identité des workloads
- Bases de la supply chain logicielle
- Observabilité orientée sécurité
- Place du service mesh et de la PKI dans une architecture sécurisée
Ce que vous devez savoir expliquer
Section intitulée « Ce que vous devez savoir expliquer »- Pourquoi sécuriser uniquement le périmètre réseau ne suffit plus
- Pourquoi l’identité workload devient centrale en cloud native
- La différence entre sécurité build-time, deploy-time et runtime
- Pourquoi la supply chain fait partie de la sécurité cloud native
Guides du site pour ce domaine :
Supply Chain Security Kubernetes Images, signature, SBOM, provenance et contrôles d'admission
Service mesh mTLS, data plane, control plane et sécurité inter-services
Écosystème CNCF Comprendre les projets et standards de l'écosystème cloud native
Principes cloud native Immutabilité, observabilité, couplage faible et architecture moderne
Domaine 2 : Kubernetes Cluster Component Security (22%)
Section intitulée « Domaine 2 : Kubernetes Cluster Component Security (22%) »Ce domaine couvre la sécurité des composants critiques du cluster.
Ce que vous devez maîtriser
Section intitulée « Ce que vous devez maîtriser »- Le rôle de l’API server dans le contrôle d’accès
- etcd comme composant critique contenant l’état du cluster
- La sécurisation du kubelet
- L’importance de TLS et des certificats
- Les audit logs
- Les admission controllers et les politiques de validation
Ce que vous devez savoir expliquer
Section intitulée « Ce que vous devez savoir expliquer »- Pourquoi l’API server est la cible prioritaire d’un cluster
- Pourquoi etcd doit être protégé et sauvegardé
- À quoi servent les logs d’audit
- En quoi l’admission permet de bloquer des configurations risquées
Guides du site pour ce domaine :
Architecture Kubernetes Control plane, worker nodes et composants critiques
etcd Base de données du cluster et composant sensible
Audit Logs Kubernetes Tracer toutes les actions sur l'API Server
Admission Controllers Valider et muter les requêtes à l'entrée du cluster
Validating Admission Policy Politiques natives Kubernetes basées sur CEL
Domaine 3 : Kubernetes Security Fundamentals (22%)
Section intitulée « Domaine 3 : Kubernetes Security Fundamentals (22%) »C’est le cœur opérationnel de la KCSA. Vous devez comprendre les contrôles de sécurité de base de Kubernetes.
Ce que vous devez maîtriser
Section intitulée « Ce que vous devez maîtriser »- RBAC : rôles, RoleBindings, ClusterRoles
- ServiceAccounts : identité des Pods et des workloads
- Secrets : limites, exposition, injection
- SecurityContext : privilèges, capabilities, readOnlyRootFilesystem
- Pod Security Standards : Baseline, Restricted, Privileged
- NetworkPolicies : segmentation réseau intra-cluster
Ce que vous devez savoir expliquer
Section intitulée « Ce que vous devez savoir expliquer »- Pourquoi
cluster-adminne doit pas être distribué largement - Pourquoi un Pod ne devrait pas tourner en root sans raison
- Comment limiter les communications entre namespaces
- Pourquoi les ServiceAccounts sont liées à l’identité workload
Guides du site pour ce domaine :
RBAC Contrôle d'accès basé sur les rôles
ServiceAccounts Identité des Pods et permissions associées
Security Context Privilèges, utilisateur, capabilities et filesystem
Pod Security Standards Niveaux de sécurité des Pods
Network Policies Segmenter le trafic entre workloads
Secrets Gestion des données sensibles
Domaine 4 : Kubernetes Threat Model (16%)
Section intitulée « Domaine 4 : Kubernetes Threat Model (16%) »Ce domaine vérifie que vous savez raisonner comme un défenseur : quelles sont les menaces probables, les surfaces d’attaque et les voies de compromission.
Ce que vous devez maîtriser
Section intitulée « Ce que vous devez maîtriser »- Les menaces internes et externes
- L’escalade de privilèges
- Les images compromises
- La fuite de secrets
- La latéralisation réseau
- Les risques du multi-tenant
- Les erreurs de configuration comme cause de compromission
Ce que vous devez savoir expliquer
Section intitulée « Ce que vous devez savoir expliquer »- Comment une image malveillante peut contaminer un cluster
- Pourquoi une absence de segmentation réseau facilite la latéralisation
- Pourquoi le modèle de menace dépend du contexte de plateforme
- Pourquoi un cluster multi-tenant demande des contrôles supplémentaires
Guides du site pour ce domaine :
Supply Chain Security Kubernetes Comprendre les risques liés aux images, dépendances et artefacts
Network Policies Réduire les mouvements latéraux entre services
CIS Kubernetes Benchmark Identifier les points de configuration à risque
Falco Détection d'anomalies et sécurité runtime
Domaine 5 : Platform Security (16%)
Section intitulée « Domaine 5 : Platform Security (16%) »Ici, l’examen se place au niveau de la plateforme : images, runtime, admission, PKI, connectivité, service mesh.
Ce que vous devez maîtriser
Section intitulée « Ce que vous devez maîtriser »- Sécurité des images
- Contrôle d’admission
- PKI et certificats
- Runtime et confinement
- Connectivité sécurisée
- Service mesh et mTLS
- Politique de confiance autour des workloads
Ce que vous devez savoir expliquer
Section intitulée « Ce que vous devez savoir expliquer »- Pourquoi scanner une image avant déploiement ne suffit pas
- À quoi sert la signature d’image
- Pourquoi le mTLS protège les communications inter-services
- Comment admission control et policy-as-code renforcent la plateforme
Guides du site pour ce domaine :
Supply Chain Security Kubernetes Scanner, signer, tracer et contrôler les images
Gatekeeper OPA et politiques d'admission
VAP vs Kyverno vs Gatekeeper Choisir le bon moteur de politiques
Service mesh mTLS et contrôle de la communication inter-services
Domaine 6 : Compliance and Security Frameworks (10%)
Section intitulée « Domaine 6 : Compliance and Security Frameworks (10%) »Le dernier domaine couvre la logique de conformité, de frameworks et d’automatisation.
Ce que vous devez maîtriser
Section intitulée « Ce que vous devez maîtriser »- CIS Benchmark
- Notion de conformité et d’écart
- Audit et traçabilité
- Policy-as-code
- Automatisation des contrôles
- Positionnement des frameworks de sécurité
Ce que vous devez savoir expliquer
Section intitulée « Ce que vous devez savoir expliquer »- À quoi sert un benchmark comme le CIS
- Pourquoi les contrôles manuels ne suffisent pas à l’échelle
- Comment policy-as-code aide à industrialiser la conformité
- Pourquoi la sécurité cloud native doit être observable et automatisée
Guides du site pour ce domaine :
CIS Kubernetes Benchmark Auditer la configuration du cluster
Audit Logs Traçabilité et investigation
Kyverno Automatiser l'application de politiques
Gatekeeper Contrôles de conformité avec OPA
Socle minimum avant de commencer
Section intitulée « Socle minimum avant de commencer »Avant d’attaquer la préparation KCSA, vérifiez que vous avez :
-
Un minimum de culture Kubernetes
Vous connaissez les objets de base : Pod, Deployment, Service, Namespace, ConfigMap, Secret.
-
Une compréhension générale de la sécurité
Vous savez ce qu’est l’authentification, l’autorisation, le chiffrement et le principe du moindre privilège.
-
Une première exposition au cloud native
Vous avez entendu parler d’images conteneur, de pipeline CI/CD, de GitOps et d’observabilité.
-
Idéalement, la KCNA ou un niveau équivalent
Ce n’est pas obligatoire, mais cela aide beaucoup à ne pas découvrir en même temps les bases Kubernetes et les concepts sécurité.
Plan de préparation (4 semaines)
Section intitulée « Plan de préparation (4 semaines) »Semaine 1 : Kubernetes Security Fundamentals + Overview
Section intitulée « Semaine 1 : Kubernetes Security Fundamentals + Overview »Objectif : Poser les bases de la sécurité Kubernetes.
Ce que vous devez étudier :
- RBAC et ServiceAccounts
- Secrets et configuration sensible
- SecurityContext et principe du moindre privilège
- Pod Security Standards
- Principes de défense en profondeur
- Notions d’identité workload
Critère de validation : Vous pouvez expliquer comment réduire les privilèges d’un workload Kubernetes sans casser son fonctionnement.
Semaine 2 : Cluster Component Security + Threat Model
Section intitulée « Semaine 2 : Cluster Component Security + Threat Model »Objectif : Comprendre où attaquer un cluster et comment le défendre.
Ce que vous devez étudier :
- API server, etcd, kubelet
- Admission controllers
- Audit logs
- Menaces supply chain
- Latéralisation réseau
- Risques liés aux images et au multi-tenant
Critère de validation : Vous pouvez décrire les principales surfaces d’attaque d’un cluster Kubernetes.
Semaine 3 : Platform Security + Compliance
Section intitulée « Semaine 3 : Platform Security + Compliance »Objectif : Relier sécurité des workloads, politiques et posture de plateforme.
Ce que vous devez étudier :
- Images, signature, provenance
- Policy-as-code
- mTLS et service mesh
- Benchmarks CIS
- Automatisation des contrôles
- Bases PKI et connectivité sécurisée
Critère de validation : Vous pouvez expliquer comment une plateforme Kubernetes réduit les risques avant, pendant et après le déploiement.
Semaine 4 : Révisions et entraînement
Section intitulée « Semaine 4 : Révisions et entraînement »Objectif : Consolider et identifier les lacunes.
Ce que vous devez faire :
- Revoir les 6 domaines
- Relire vos notes
- Refaire les quiz sécurité du site
- Identifier les confusions fréquentes
- Faire des QCM d’entraînement
Checklist finale :
- Je sais distinguer authentification, autorisation et admission
- Je comprends RBAC, ServiceAccounts et Secrets
- Je sais expliquer SecurityContext et Pod Security Standards
- Je comprends les risques supply chain de base
- Je connais le rôle d’etcd, de l’API server et des audit logs
- Je sais expliquer NetworkPolicies, mTLS et segmentation
- Je connais le rôle du CIS Benchmark
- Je sais situer Kyverno, Gatekeeper, VAP et Falco dans une stratégie sécurité
Ce que la KCSA ne demande pas
Section intitulée « Ce que la KCSA ne demande pas »Pour ne pas vous disperser, voici ce qui est hors scope ou secondaire :
- Installer et réparer un cluster en ligne de commande → CKA
- Résoudre des labs pratiques de hardening en temps limité → CKS
- Configurer Falco, Istio ou Kyverno en profondeur → niveau supérieur
- Écrire des politiques complexes de mémoire → pas le cœur d’une certif associate
- Maîtriser toute la sécurité Linux système → la KCSA reste centrée cloud native
La KCSA teste votre compréhension conceptuelle de la sécurité cloud native, pas votre rapidité d’exécution sur un terminal.
Stratégie le jour de l’examen
Section intitulée « Stratégie le jour de l’examen »| Conseil | Pourquoi |
|---|---|
| Lisez précisément les termes | Beaucoup de questions jouent sur les différences entre authentification, autorisation, admission, chiffrement |
| Raisonnez par contrôle de sécurité | Demandez-vous toujours : “ce mécanisme protège quoi ?” |
| Éliminez les réponses trop absolues | En sécurité, les réponses extrêmes sont souvent fausses |
| Faites le lien avec les risques | RBAC, PSS, mTLS, audit logs ont chacun un objectif clair |
| Ne mémorisez pas seulement les outils | Comprenez d’abord le problème qu’ils résolvent |
Positionnement dans les certifications CNCF
Section intitulée « Positionnement dans les certifications CNCF »La KCSA se place dans la branche associate sécurité du parcours Kubernetes :
| Certification | Niveau | Focus |
|---|---|---|
| KCNA | Associate | Fondamentaux Kubernetes et cloud native |
| KCSA | Associate | Fondamentaux sécurité cloud native |
| CKAD | Professional | Développement applicatif |
| CKA | Professional | Administration Kubernetes |
| CKS | Specialist | Sécurité avancée Kubernetes |
Pièges courants de la préparation
Section intitulée « Pièges courants de la préparation »| Piège | Conséquence | Solution |
|---|---|---|
| Réviser uniquement les outils | Connaissance superficielle | Révisez les menaces, objectifs et contrôles |
| Confondre RBAC, admission et NetworkPolicies | Réponses imprécises | Classez les contrôles par niveau : identité, API, réseau, runtime |
| Sous-estimer les composants du cluster | Lacunes sur 22% du blueprint | Travaillez API server, etcd, kubelet, audit |
| Négliger la conformité | Perte de points faciles | Révisez CIS, policy-as-code, traçabilité |
| Se jeter trop vite sur la CKS | Gap trop important | Consolidez d’abord la base conceptuelle avec KCSA |
Ressources recommandées
Section intitulée « Ressources recommandées »Références officielles
Section intitulée « Références officielles »- Page officielle KCSA (Linux Foundation)
- Page CNCF KCSA
- Curriculum officiel / blueprint (disponible sur la page CNCF)
- Handbook candidat (fourni après inscription)
Ressources du site
Section intitulée « Ressources du site »- Les guides Kubernetes sécurité de la section Sécuriser Kubernetes
- Les pages RBAC, SecurityContext, PSS, Audit Logs, Supply Chain Security
- Les comparatifs de policy engines et les guides runtime
Pratique complémentaire
Section intitulée « Pratique complémentaire »Même si l’examen est un QCM, manipuler un cluster aide à ancrer les concepts :
- Créer un namespace isolé
- Appliquer une NetworkPolicy simple
- Observer l’effet d’un SecurityContext
- Lire des audit logs
- Tester une policy d’admission
À retenir
Section intitulée « À retenir »- La KCSA est un QCM associate orienté sécurité Kubernetes et cloud native
- Deux domaines valent 22% chacun : sécurité des composants du cluster et fondamentaux de sécurité Kubernetes
- Le prix officiel est de 250 USD avec une reprise incluse
- La KCSA n’est pas la CKS : elle valide un socle théorique, pas une exécution pratique
- La KCSA complète naturellement la KCNA pour une branche sécurité associate
- Le modèle de menace, la plateforme et la conformité comptent autant que les objets Kubernetes eux-mêmes
Prochaines étapes
Section intitulée « Prochaines étapes » Préparation KCNA Valider les fondations Kubernetes et cloud native avant la sécurité
Sécuriser Kubernetes Vue d'ensemble du hardening, des politiques et de la sécurité runtime
RBAC Comprendre le contrôle d'accès Kubernetes
Supply Chain Security Images, SBOM, signature et contrôles d'admission
Préparation CKA Renforcer la maîtrise opérationnelle de la plateforme
Préparation CKS Passer à la sécurité pratique avancée après la CKA