19 labs pratiques pour préparer le Certified Kubernetes Security Specialist, soit environ 8 heures de travail, chacun noté sur l'état réel de votre machine et non sur les commandes tapées. Ils se jouent chez vous avec la ligne de commande `dsoxlab`, et ne coûtent rien.
La sécurité du cluster et de ce qui y tourne : durcissement, admission, politiques réseau, chaîne d'approvisionnement des images et détection à l'exécution. Le CKA en est le prérequis.
- 19labs
- 8heures de pratique
- 19sur machines virtuelles
Niveaux 9 intermédiaire 10 avancé
Objectifs officiels de l'examen publiés par CNCF
Ce ne sont pas des questions d'examen. Ce sont des exercices pratiques sur les compétences que l'examen mesure, notés sur l'état de votre machine.
Kubernetes, CKA, CKAD et CKS
Ajouter ce catalogue dsoxlab catalog add https://github.com/stephrobert/kubernetes-dsoxlab-training
CKS, Certified Kubernetes Security Specialist
-
Confiner un Pod avec un profil AppArmor
Charger un profil AppArmor sur le nœud, l'appliquer à un conteneur par le champ securityContext, et prouver que le confinement agit en constatant l'échec d'une écriture que le profil interdit.
dsoxlab start cks-apparmor-confiner-un-pod -
Interdire un appel système à un conteneur, et le prouver de l'intérieur
Un conteneur qui peut appeler tout ce que le noyau propose. Écrivez un profil seccomp qui refuse une famille d'appels système, appliquez-le, et prouvez que le confinement tient : l'appel interdit échoue depuis l'intérieur, et tout le reste continue de fonctionner.
dsoxlab start cks-seccomp-profile -
Refuser un Pod privilégié à l'admission, avec Pod Security Admission
Un namespace qui accepte tout, y compris un Pod qui partage le namespace PID de l'hôte et tourne en root. Activez le standard restricted pour que le cluster le refuse à l'admission, et prouvez le refus sans rien créer : un essai côté serveur traverse l'admission et n'écrit rien.
dsoxlab start cks-pod-security-admission -
Reprendre un Pod privilégié en production, sans le priver de son travail
Un Pod tourne avec le namespace de processus de l'hôte, en root, privilégié, depuis un tag flottant. Reconstruisez-le sans rien de tout cela, et prouvez la différence là où elle se voit : de l'intérieur, le conteneur ne voit plus l'hôte.
dsoxlab start cks-secure-existing-pod -
Rendre un conteneur immuable sans le faire tomber
Un Deployment qui tourne peut encore être modifié de l'intérieur. Rendez sa racine non inscriptible, retirez-lui toutes les capacités, interdisez l'escalade, et faites en sorte que l'application continue de servir : nginx a besoin de quelques chemins inscriptibles, et les trouver est l'exercice.
dsoxlab start cks-security-context-immutable -
Isoler un Pod du noyau de l'hôte, et le prouver en lisant sa version
Le nœud propose un second runtime de conteneurs, qui exécute un noyau applicatif à lui. Placez-y un Pod, et prouvez l'isolation de la seule façon qui ne se truque pas : de l'intérieur, la version du noyau n'est plus celle du nœud.
dsoxlab start cks-runtime-sandbox-gvisor -
Épingler une image par son digest, et prouver que le tag ne suffit pas
Un Deployment qui fait confiance à un tag mutable. Épinglez-le sur le digest immuable de l'image qu'il exécute réellement, et prouvez que l'épinglage tient : le digest déclaré doit correspondre à ce que le runtime a résolu, et pas seulement y ressembler.
dsoxlab start cks-image-pinned-digest -
Faire refuser une image non épinglée par le cluster lui-même, sans webhook
Un namespace accepte n'importe quelle image, tag compris. Faites refuser par l'API server celles qui ne sont pas épinglées par leur digest, avec une politique qu'il évalue lui-même : pas de webhook, pas de contrôleur, rien à maintenir en vie.
dsoxlab start cks-validating-admission-policy -
Remplacer une image criblée de failles, et le prouver par un second scan
Un Deployment tourne sur une image vieille de trois ans. Analysez-la, choisissez son remplacement, et prouvez ce choix : le test analyse les deux et exige strictement moins de failles critiques que l'original, ce qu'aucun seuil fixe ne pourrait mesurer honnêtement.
dsoxlab start cks-image-scanning-trivy -
Signer une image, et prouver la signature en faisant refuser une autre
Un registre local porte deux images, aucune signée. Signez-en une avec cosign, publiez la clé publique, et prouvez que la chaîne fonctionne : la même clé doit accepter l'image signée et refuser l'autre. Une vérification qui accepte tout ne prouve rien.
dsoxlab start cks-cosign-verify-image -
Corriger un Dockerfile que l'analyse statique refuse, sans changer l'application
Un Dockerfile qui construit et qui tourne, et que l'analyse statique refuse sur cinq points. Corrigez-les tous sans changer ce que fait l'image, et prouvez-le en relançant l'analyse : les cinq constats doivent avoir disparu, identifiés par leur numéro et non par un total qu'une nouvelle règle fausserait.
dsoxlab start cks-dockerfile-static-analysis -
Retirer cluster-admin à un compte de service, sans le priver de son travail
Un ServiceAccount détient cluster-admin parce que c'était plus rapide. Reprenez ce pouvoir et donnez-lui exactement ce dont son application a besoin, rien de plus. La preuve n'est pas dans le manifeste : elle est dans ce que l'API server répond quand ce compte demande.
dsoxlab start cks-rbac-least-privilege -
Fermer le profileur de l'API server, sans fermer l'API
L'API server expose son profileur Go à qui sait l'atteindre, et un cluster kubeadm le laisse actif. Fermez-le et relevez le plancher TLS, puis prouvez les deux moitiés : le profileur répond 404, et le cluster fonctionne toujours.
dsoxlab start cks-api-server-hardening -
Enregistrer qui lit les Secrets, et seulement les métadonnées du reste
Le cluster ne garde aucune trace de qui lit quoi. Donnez à l'API server une politique d'audit à deux niveaux, corps complets pour les Secrets et métadonnées pour le reste, et prouvez qu'elle agit en relisant le journal que le cluster vient d'écrire.
dsoxlab start cks-audit-log-policy -
Tout interdire, puis rouvrir le strict nécessaire, DNS compris
Un namespace où tout parle à tout. Fermez-le entièrement dans les deux directions, puis rouvrez exactement deux choses : le seul flux dont l'application a besoin, et la résolution de noms, qu'une sortie fermée par défaut casse sans que rien ne vous prévienne.
dsoxlab start cks-networkpolicy-default-deny -
Exiger le mTLS dans un maillage, et le prouver par un client qui reste dehors
Un maillage de services accepte du trafic en clair, de n'importe qui, du maillage ou du dehors. Exigez le TLS mutuel, et prouvez-le de la seule façon qui compte : un Pod muni d'un sidecar joint toujours le service, un Pod qui n'en a pas ne le joint plus.
dsoxlab start cks-istio-mtls-lockdown -
Servir un site en HTTPS avec son propre certificat, et non celui du contrôleur
Le site répond déjà en HTTPS, et c'est précisément le piège : le contrôleur Ingress sert son propre certificat par défaut à qui le demande. Terminez le TLS avec un certificat qui nomme vraiment l'hôte.
dsoxlab start cks-ingress-tls -
Faire baisser le compte d'un audit CIS, et le prouver par un second audit
kube-bench audite le control plane contre le référentiel CIS et échoue à dix contrôles sur un cluster kubeadm sorti de l'installation. Corrigez les trois qui partagent une même cause, puis prouvez-le de la seule façon honnête : relancez l'audit et comptez.
dsoxlab start cks-cis-benchmark-remediate -
Capstone : ouvrir une enclave pour une équipe qui n'est pas de confiance
Une équipe extérieure a besoin de place dans votre cluster. Donnez-lui un espace qui reste sûr même si elle ne l'est pas : le cluster doit refuser lui-même ce qu'elle ne devrait pas déployer, son identité ne doit presque rien pouvoir, et rien hors de l'enclave ne doit atteindre ce qui y tourne.
dsoxlab start cks-capstone-enclave