Certification KCSA : les six domaines, l'examen et un quiz de révision

Onze compétences, une par composant : API server, controller manager, scheduler, kubelet, runtime, kube-proxy, pod, etcd, réseau, client, stockage. C'est le domaine le plus mécanique des six - pour chaque composant, la question est la même : qu'est-ce qu'il peut faire, avec quelles permissions, et qu'est-ce qu'un attaquant obtient s'il le contrôle.

Deux composants concentrent l'essentiel. L'API server, parce que tout passe par lui et que c'est donc sur lui que se branchent l'authentification, l'autorisation et l'admission - une porte unique est une bonne chose tant qu'elle est gardée. Et etcd, parce qu'il contient l'état complet du cluster, Secrets compris, en clair par défaut : un accès en lecture à etcd, ou simplement à une sauvegarde d'etcd, équivaut à un accès administrateur.

Le kubelet mérite une attention particulière. Il tourne sur chaque nœud, il a le droit de créer des pods, et son port de lecture non authentifié a longtemps été une porte ouverte classique. Client Security vise le poste de travail : un fichier kubeconfig traîne sur un disque non chiffré, et c'est le cluster entier qui traîne avec.

Le domaine le mieux couvert par le guide, et celui où les points se prennent le plus facilement parce que tout y est concret et vérifiable sur un cluster local.

Les Pod Security Standards définissent trois profils - privileged, baseline, restricted - et Pod Security Admission est le contrôleur intégré qui les applique par namespace, avec des labels. Il a remplacé PodSecurityPolicy, supprimé en 1.25 : si une ressource vous en montre un, elle date.

L'authentification et l'autorisation sont deux choses distinctes, et l'examen le vérifie. Kubernetes n'a pas d'objet « utilisateur » : il fait confiance à un certificat, un jeton ou un fournisseur externe. L'autorisation, elle, est RBAC dans la quasi-totalité des cas - Roles et ClusterRoles, RoleBindings et ClusterRoleBindings, et la règle qui gouverne tout : ce qui n'est pas explicitement autorisé est refusé.

Les Secrets sont le piège récurrent. base64 n'est pas un chiffrement, un Secret n'est pas chiffré au repos par défaut, et ce qui le distingue vraiment d'une ConfigMap tient à des droits RBAC séparés et à un traitement différent sur les nœuds. Quant aux NetworkPolicies : l'API server les stocke que quelque chose les applique ou non, donc sur un cluster dont le plugin réseau les ignore, votre manifeste s'applique sans erreur et ne filtre rien.

Aucun équivalent dans le guide, et le domaine qui demande le plus gros effort de révision propre. Ce n'est pas une liste de réglages : c'est une façon de raisonner, et les questions testent le raisonnement.

Tout part des trust boundaries, les frontières de confiance. Un cluster en a plusieurs, emboîtées : entre le conteneur et le pod, entre le pod et le nœud, entre le nœud et le control plane, entre le cluster et le cloud qui l'héberge. Chaque compétence du domaine décrit ce qui arrive quand l'une d'elles cède. Privilege Escalation est la traversée de la deuxième : privileged: true, hostPID, un montage hostPath en écriture - trois réglages qui dissolvent chacun la frontière entre le conteneur et la machine.

Persistence est la question d'après : une fois entré, comment l'attaquant reste-t-il. Un CronJob discret, un contrôleur d'admission modifié, un ServiceAccount aux droits trop larges créé tranquillement dans un namespace que personne ne regarde. Denial of Service a sa réponse dans l'ordonnancement, pas dans la sécurité : un pod sans requests est en classe BestEffort et sera évincé le premier, et c'est aussi comme ça qu'un voisin bruyant fait tomber ce qui l'entoure.

Attacker on the Network et Access to Sensitive Data reviennent au même constat : sans NetworkPolicy, le réseau d'un cluster est plat, et n'importe quel pod compromis joint n'importe quel autre pod. C'est le défaut, et c'est ce que l'examen attend que vous sachiez.

Ce qui entoure le cluster plutôt que le cluster lui-même. Aucun chapitre du guide ne le couvre.

Supply Chain Security est le gros morceau, et celui où les distinctions comptent. Signer une image établit deux choses, et deux seulement : qui l'a publiée, et qu'elle n'a pas bougé depuis. Pas qu'elle est sans vulnérabilité, pas qu'elle tourne en non-root, pas que ses dépendances sont saines. Les vulnérabilités relèvent du scan, l'inventaire des dépendances du SBOM, et l'application de la règle d'un contrôleur d'admission. Sigstore, Cosign et in-toto sont les noms à connaître.

Admission Control est le point d'articulation de tout le domaine : c'est le dernier endroit où une politique peut refuser un objet avant son écriture dans etcd. Les contrôleurs de validation refusent, ceux de mutation modifient, et les politiques s'écrivent aujourd'hui avec OPA Gatekeeper, Kyverno, ou nativement en CEL.

Le reste est plus classique : la PKI et la rotation des certificats du cluster, un service mesh pour le chiffrement de transit entre pods et l'authentification mutuelle, et un registre d'images qui doit être traité comme un actif sensible - c'est par lui que passe tout ce qui s'exécute.

Le domaine de cadrage, et il commence par le modèle le plus cité de tout le programme : les 4C. Cloud, Cluster, Container, Code, quatre couches emboîtées, de la plus large à la plus étroite. L'ordre n'est pas décoratif - chaque couche ne peut être que moins sûre que celle qui l'entoure, et durcir le code d'une application qui tourne sur un compte cloud compromis n'achète rien du tout.

Isolation Techniques va du plus léger au plus lourd : namespaces Linux et cgroups d'abord, puis seccomp, AppArmor et SELinux pour restreindre les appels système, puis les runtimes isolés - gVisor, Kata Containers - quand la frontière du conteneur ne suffit plus. Savoir ranger ces mécanismes dans le bon ordre de force répond à la plupart des questions.

Cloud Provider and Infrastructure Security introduit le modèle de responsabilité partagée : sur un cluster géré, le fournisseur tient le control plane et vous tenez tout le reste, y compris ce que vous croyiez délégué.

Le plus petit domaine, celui qui parle le moins de Kubernetes, et celui que les candidats venus de l'exploitation survolent le plus volontiers. Dix pour cent, soit six questions : c'est exactement l'écart qui sépare un 73 % d'un 83 %.

Quatre familles de cadres, à ne pas confondre - et l'examen les propose volontiers côte à côte comme distracteurs. Les cadres de conformité disent ce qu'une organisation doit prouver : SOC 2, ISO 27001, PCI DSS, le RGPD. Les cadres de modélisation de menaces donnent une méthode pour les inventorier : STRIDE, qui classe en six catégories - usurpation d'identité, altération, répudiation, divulgation, déni de service, élévation de privilège.

À côté, deux choses qui n'en sont ni l'un ni l'autre et qu'on prend souvent pour telles. MITRE ATT&CK est un catalogue de tactiques d'attaquants réellement observées, pas une méthode de classification. Un CIS Benchmark est une liste de durcissement concrète pour un produit donné - il en existe un pour Kubernetes, et kube-bench l'exécute contre votre cluster.

Supply Chain Compliance reprend le SBOM sous l'angle réglementaire, et Automation and Tooling ferme la boucle : la conformité ne se prouve pas par une capture d'écran annuelle mais par un contrôle automatisé qui tourne en continu.