Aller au contenu
English
Compte : non connecté, synchronisation possible Mon apprentissage
Selectionner le thème
English

Préparation associée

Labs CKS

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.

Revenir aux 404 labsComment jouer un lab

  • 19 labs
  • 8 heures de pratique
  • 19 sur machine virtuelle

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.

La CLI d'abord, avec uv ou pipx : aucun droit d'administration, Python 3.11 suffit. uv tool install dsoxlab # ou : pipx install dsoxlab Installer DSOXLab

Kubernetes, CKA, CKAD et CKS

19 labs chaque lab joué et noté par l'auteur

Ajouter ce catalogue dsoxlab catalog add https://github.com/stephrobert/kubernetes-dsoxlab-training

CKS, Certified Kubernetes Security Specialist

19
  • Lab guidé 25m · avancé · machines virtuelles

    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

    Guide compagnon

  • Lab guidé 25m · avancé · machines virtuelles

    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

    Guide compagnon

  • Lab guidé 15m · intermédiaire · machines virtuelles

    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

    Guide compagnon

  • Lab guidé 20m · intermédiaire · machines virtuelles

    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

    Guide compagnon

  • Lab guidé 20m · intermédiaire · machines virtuelles

    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

    Guide compagnon

  • Lab guidé 25m · avancé · machines virtuelles

    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

    Guide compagnon

  • Lab guidé 15m · intermédiaire · machines virtuelles

    É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

    Guide compagnon

  • Lab guidé 30m · avancé · machines virtuelles

    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

    Guide compagnon

  • Lab guidé 25m · intermédiaire · machines virtuelles

    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

    Guide compagnon

  • Lab guidé 30m · avancé · machines virtuelles

    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

    Guide compagnon

  • Lab guidé 20m · intermédiaire · machines virtuelles

    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

    Guide compagnon

  • Lab guidé 20m · intermédiaire · machines virtuelles

    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

    Guide compagnon

  • Lab guidé 25m · avancé · machines virtuelles

    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

    Guide compagnon

  • Lab guidé 25m · avancé · machines virtuelles

    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

    Guide compagnon

  • Lab guidé 20m · intermédiaire · machines virtuelles

    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

    Guide compagnon

  • Lab guidé 30m · avancé · machines virtuelles

    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

    Guide compagnon

  • Lab guidé 25m · intermédiaire · machines virtuelles

    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

    Guide compagnon

  • Lab guidé 30m · avancé · machines virtuelles

    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

    Guide compagnon

  • Examen blanc réussite 66 % 45m · avancé · machines virtuelles

    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

    Guide compagnon

Ce projet vous est utile ?

Les guides, formations, quiz et labs restent gratuits. Si vous les utilisez régulièrement, vous pouvez contribuer à leur maintenance et à leur développement.

Devenir membre de soutien (nouvel onglet) Soutenir une fois (nouvel onglet) En savoir plus

Suivez aussi le projet sur LinkedIn