Pratiquer
Labs Kubernetes
Opérer un cluster pour de vrai : des Pods qui ne démarrent pas, du réseau à ouvrir puis à refermer, du stockage à provisionner, et un examen à préparer.
Revenir aux 404 labsComment jouer un lab
- 64 labs
- 21 heures de pratique
- 64 sur machine virtuelle
Ce que vous y pratiquez Pods et workloadsservices et IngressstockageRBACNetworkPolicyadmission et durcissementdépannage
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
Ajouter ce catalogue dsoxlab catalog add https://github.com/stephrobert/kubernetes-dsoxlab-training chaque lab joué et noté par l'auteur
CKA, Certified Kubernetes Administrator
25
-
Lab guidé 10m · intermédiaire · machines virtuelles
Poser un Pod statique sur un worker, sans passer par l'API
Faire tourner un Pod que le kubelet du worker gère seul, à partir d'un manifeste déposé sur le nœud, et le voir apparaître dans l'API sous son nom de miroir. Le fichier doit être au bon endroit, celui que la configuration du kubelet désigne, et le runtime du worker doit réellement exécuter le conteneur.
dsoxlab start cka-static-podCKA Guide compagnon
-
Lab guidé 10m · débutant · machines virtuelles
Un agent sur chaque nœud, control plane compris
Déployer un DaemonSet qui pose un agent sur tous les nœuds du cluster, y compris le control plane, protégé par son taint. Les tests comptent un Pod par nœud, vérifient que le taint est toujours là et que l'agent y tourne quand même, et lisent ses logs pour prouver qu'il fait son travail.
dsoxlab start cka-daemonset-all-nodesCKA Guide compagnon
-
Lab guidé 15m · intermédiaire · machines virtuelles
Donner une identité à une application : ServiceAccount, Role, RoleBinding
Une application refuse de démarrer parce que son ServiceAccount n'existe pas. Le créer, lui accorder le droit de lire les Pods de son namespace et rien d'autre, puis prouver depuis l'intérieur du Pod, avec son propre jeton, que lister passe et que supprimer, lire les Secrets ou regarder ailleurs sont refusés.
dsoxlab start cka-rbac-serviceaccountCKA Guide compagnon
-
Lab guidé 10m · intermédiaire · machines virtuelles
Réserver un nœud : taint, tolérance et nodeSelector
Réserver le worker à la production par un taint et un label, puis placer un Pod qui doit y aller, tolérance et nodeSelector, et un Pod qui ne doit pas y aller. Les tests lisent le nœud, le placement réel de chaque Pod et les mécanismes déclarés : un Pod épinglé par nodeName contourne le taint et ne passe pas.
dsoxlab start cka-taints-tolerations-placementCKA Guide compagnon
-
Lab guidé 15m · intermédiaire · machines virtuelles
Placer avec nodeAffinity : contrainte obligatoire et préférence
Placer un Deployment par une affinité de nœud obligatoire sur un label à plusieurs valeurs, y ajouter une préférence pondérée, puis débloquer un Pod qui attend un nœud qui n'existe pas encore en posant le label qu'il exige. Les tests lisent les labels des nœuds, les affinités déclarées et le nœud réel de chaque Pod.
dsoxlab start cka-node-affinityCKA Guide compagnon
-
Lab guidé 15m · intermédiaire · machines virtuelles
Isoler la base de données : seul le backend y accède
Écrire la NetworkPolicy qui ne laisse entrer vers la base que le backend de son namespace, sur son port, et rien d'autre. Les tests tentent les connexions : celle qui doit passer, celle du frontend qui doit être bloquée, celle d'un Pod au bon label mais dans un autre namespace, et vérifient que la base peut encore sortir.
dsoxlab start cka-networkpolicy-isolate-dbCKA Guide compagnon
-
Lab guidé 20m · intermédiaire · machines virtuelles
Router deux applications sur un seul hôte, et prouver que chacune reçoit la sienne
Deux applications, un seul nom d'hôte, et aucune règle disant laquelle est laquelle. Routez par le chemin, et prouvez-le de la seule façon qui compte : chaque chemin répond le nom de son application, et un chemin non déclaré ne répond ni l'une ni l'autre.
dsoxlab start cka-ingress-path-routingCKA Guide compagnon
-
Lab guidé 25m · avancé · machines virtuelles
Router avec la Gateway API, et voir la Gateway se déclarer programmée
Les deux mêmes applications, le même nom d'hôte unique, et le successeur de l'Ingress. Déclarez une Gateway, attachez-lui une route, et prouvez le routage : chaque chemin répond le nom de son application, un chemin non déclaré ne répond ni l'une ni l'autre.
dsoxlab start cka-gateway-api-httprouteCKA Guide compagnon
-
Lab guidé 15m · intermédiaire · machines virtuelles
Un volume persistant : PersistentVolume, PersistentVolumeClaim et un Pod qui écrit
Sur un cluster sans provisionnement dynamique, créer un PersistentVolume sur le disque d'un nœud, le réclamer par un PersistentVolumeClaim, le monter dans un Pod qui y écrit. Les tests lisent le volume, la liaison, le montage, le fichier dans le Pod, puis le même fichier sur le disque du nœud : c'est là que se prouve la persistance.
dsoxlab start cka-pv-pvc-storageclassCKA Guide compagnon
-
Lab guidé 25m · intermédiaire · machines virtuelles
Obtenir un volume sans qu'un administrateur l'ait créé, et voir ce qu'il devient
Une revendication bloquée en attente parce que personne n'a préparé de volume à la main. Laissez le cluster le provisionner à la demande, puis observez ce que la classe décide quand la revendication disparaît : le volume la suit.
dsoxlab start cka-storageclass-provisionnement-dynamiqueCKA Guide compagnon
-
Lab guidé 15m · intermédiaire · machines virtuelles
Revenir en arrière sur un déploiement bloqué, puis livrer la bonne version
Une mise à jour est partie avec un nom d'image faux et le déploiement est bloqué. Revenir à la révision qui marchait par l'historique du Deployment, puis livrer l'image correcte avec une cause de changement. Les tests lisent les ReplicaSets et leurs numéros de révision : ils racontent ce qui s'est passé, et un Deployment recréé de zéro ne raconte rien.
dsoxlab start cka-deployment-rollout-rollbackCKA Guide compagnon
-
Lab guidé 15m · intermédiaire · machines virtuelles
Vider un worker pour une maintenance, sans couper le service
Protéger une application par un PodDisruptionBudget, retirer le worker du scheduling, l'évacuer en respectant ce budget et les DaemonSets, puis le remettre en service et tracer l'opération. Les tests prouvent que les Pods ont réellement été recréés ailleurs, que le nœud est revenu, et que le DaemonSet du CNI n'a pas bougé.
dsoxlab start cka-node-drain-cordonCKA Guide compagnon
-
Lab guidé 20m · intermédiaire · machines virtuelles
Faire monter en charge automatiquement avec un HorizontalPodAutoscaler
Poser un HPA sur un Deployment, générer de la charge, voir la montée en replicas, puis couper la charge. Les tests lisent le HPA, ses métriques courantes, et l'event de redimensionnement que le contrôleur a émis : un HPA qui n'a jamais redimensionné n'est pas un HPA validé.
dsoxlab start cka-hpa-autoscalingCKA Guide compagnon
-
Lab guidé 25m · intermédiaire · machines virtuelles
Plafonner un namespace sans bloquer ceux qui oublient de se déclarer
Un namespace sans plafond ni valeurs par défaut : une équipe peut prendre tout le cluster, et un Pod sans `requests` est placé à l'aveugle. Posez les deux, et prouvez chacun : un Pod qui demande trop est refusé, un Pod qui ne demande rien est accepté et complété.
dsoxlab start cka-resourcequota-limitrangeCKACKAD Guide compagnon
-
Lab guidé 10m · débutant · machines virtuelles
Sortir un Pod de l'ImagePullBackOff
Un Pod ne démarre pas parce que son image ne se télécharge pas. Lire le message exact du runtime dans les events, corriger la référence d'image, et prouver que le serveur répond.
dsoxlab start cka-troubleshoot-imagepullbackoffCKA Guide compagnon
-
Lab guidé 15m · intermédiaire · machines virtuelles
Sortir un Deployment du CrashLoopBackOff
Les Pods d'un Deployment redémarrent en boucle depuis la dernière livraison. Lire ce que le processus a dit avant de mourir, comprendre ce qui lui manque, corriger le Deployment, et prouver que l'application sert à nouveau.
dsoxlab start cka-troubleshoot-crashloopbackoffCKA Guide compagnon
-
Lab guidé 15m · intermédiaire · machines virtuelles
Entrer dans un conteneur sans shell avec kubectl debug
Un Pod dont l'image ne contient aucun shell n'offre rien à kubectl exec. Lui adjoindre un conteneur éphémère qui partage ses processus, atteindre le système de fichiers du nœud par un Pod de débogage, et en laisser la preuve.
dsoxlab start cka-kubectl-debugCKA Guide compagnon
-
Lab guidé 10m · intermédiaire · machines virtuelles
Rétablir la résolution DNS du cluster
Plus aucun Pod ne résout de nom de service. Trouver pourquoi le DNS du cluster ne répond plus, le remettre en service, et prouver qu'un Pod client résout et joint à nouveau un Service par son nom.
dsoxlab start cka-troubleshoot-dnsCKA Guide compagnon
-
Lab guidé 15m · avancé · machines virtuelles
Rétablir le trafic vers un Service
Un Service ne dessert plus ses Pods : selector faux, port faux, et une politique réseau qui ferme tout. Remettre le Service d'aplomb, rouvrir exactement ce qu'il faut sans retirer la politique de sécurité, et prouver qu'un client joint le Service par son nom.
dsoxlab start cka-troubleshoot-networkingCKA Guide compagnon
-
Lab guidé 15m · avancé · machines virtuelles
Ramener un nœud NotReady dans le cluster
Un worker est passé NotReady, et l'application qui lui est réservée est dégradée. Trouver sur le nœud pourquoi il ne parle plus au control plane, remettre son agent en service de façon durable, et prouver que l'application est revenue.
dsoxlab start cka-troubleshoot-node-notreadyCKA Guide compagnon
-
Lab guidé 15m · avancé · machines virtuelles
Réparer un kubelet qui refuse de démarrer
Le kubelet d'un worker s'arrête aussitôt lancé, et le nœud est NotReady. Lire dans le journal ce qu'il reproche à sa configuration, corriger le fichier sans rien casser d'autre, et prouver que le nœud et son application sont revenus.
dsoxlab start cka-troubleshoot-kubeletCKA Guide compagnon
-
Lab guidé 15m · avancé · machines virtuelles
Remettre l'API server en service
kubectl ne répond plus : l'API server du control plane sort en erreur au démarrage. Sans API, diagnostiquer sur le nœud, dans les conteneurs et les journaux du kubelet, corriger le manifeste statique, et prouver que l'API répond sans avoir affaibli son autorisation.
dsoxlab start cka-troubleshoot-apiserverCKA Guide compagnon
-
Lab guidé 25m · avancé · machines virtuelles
Sauvegarder etcd, puis restaurer le cluster depuis un instantané
Un namespace a disparu. Prendre d'abord une sauvegarde fraîche de l'état courant, puis restaurer le cluster depuis l'instantané de la veille, sans arrêter le mauvais composant et sans laisser l'API server sur un cache périmé. Les tests prouvent qu'etcd tourne sur un répertoire produit pendant le lab, que les objets reviennent avec leur UID d'origine, et que ce qui a été écrit après la sauvegarde a disparu.
dsoxlab start cka-etcd-backup-restoreCKA Guide compagnon
-
Lab guidé 40m · avancé · machines virtuelles
Monter un cluster d'une version mineure, sans interrompre ce qui tourne
Un cluster en retard d'une version mineure, une application qui doit continuer à servir, et la montée à conduire : le plan de contrôle d'abord, le nœud ensuite, chacun avec sa propre commande. Les tests lisent les versions et vérifient que rien n'a été laissé vidé.
dsoxlab start cka-kubeadm-upgradeCKA Guide compagnon
-
Examen blanc réussite 66 % 45m · avancé · machines virtuelles
Capstone : remettre le portail en service, sans personne à qui demander
Un namespace laissé par une équipe partie, un portail qui ne répond rien, et aucun ticket pour dire pourquoi. Trois défauts indépendants à trouver, deux exigences qui n'ont jamais été satisfaites, et une seule mesure de réussite : le portail répond sur chaque nœud du cluster.
dsoxlab start cka-capstone-portailCKA Guide compagnon
CKAD, Certified Kubernetes Application Developer
20
-
Lab guidé 10m · débutant · machines virtuelles
Un Pod à deux conteneurs, avec budgets, labels et annotation
Écrire à la main un Pod à deux conteneurs, chacun avec ses requests et ses limits, avec des labels et une annotation, et prouver depuis l'intérieur de chaque conteneur que la limite de mémoire est celle que le noyau applique.
dsoxlab start ckad-pod-resources-labelsCKAD Guide compagnon
-
Lab guidé 15m · débutant · machines virtuelles
Injecter configuration et secrets dans un Pod
Donner à une application sa configuration par des variables d'environnement et par un fichier monté, et ses identifiants par un Secret, sans jamais écrire un mot de passe dans le manifeste du Pod. Prouver, de l'intérieur du conteneur, que tout est arrivé.
dsoxlab start ckad-configmap-secret-injectionCKAD Guide compagnon
-
Lab guidé 20m · intermédiaire · machines virtuelles
Sortir un mot de passe d'un manifeste, sans que l'application s'en aperçoive
Un mot de passe est écrit en clair dans un manifeste de Deployment, que quiconque peut lire le lit aussi. Déplacez-le dans un Secret, injectez-le à la fois en variable d'environnement et en fichier monté, et laissez l'application tourner.
dsoxlab start ckad-secret-injection-protectionCKAD Guide compagnon
-
Lab guidé 15m · débutant · machines virtuelles
Trois sondes sur un Pod : startup, liveness, readiness
Équiper une application des trois sondes, avec des réglages qui ont un sens : un démarrage lent toléré, une vivacité surveillée, un trafic qui n'arrive qu'une fois prête. Prouver que les sondes agissent : le Pod n'est Ready que parce qu'elles répondent.
dsoxlab start ckad-probes-all-typesCKAD Guide compagnon
-
Lab guidé 15m · intermédiaire · machines virtuelles
Attendre une dépendance avec un init container
Empêcher une application de démarrer avant que le Service dont elle dépend ne réponde, avec un init container qui attend. Observer le Pod bloqué en Init, poser la dépendance, et voir l'application partir toute seule.
dsoxlab start ckad-init-containerCKAD Guide compagnon
-
Lab guidé 15m · intermédiaire · machines virtuelles
Un sidecar natif qui suit les logs de l'application
Faire lire par un second conteneur les logs qu'une application écrit dans un fichier, avec un sidecar natif, déclaré comme init container à restartPolicy Always, et un volume partagé. Prouver que le sidecar transmet réellement les lignes.
dsoxlab start ckad-multi-container-sidecarCKAD Guide compagnon
-
Lab guidé 20m · intermédiaire · machines virtuelles
Faire lire à un conteneur ce qu'un autre écrit, et pas le reste
Deux conteneurs dans un Pod, l'un qui écrit et l'autre qui lit, et rien de partagé entre eux. Donnez-leur un volume dont la durée de vie est celle du Pod, et prouvez-le dans les deux sens : ce qui est écrit dans le volume passe, ce qui est écrit à côté ne passe pas.
dsoxlab start ckad-volumes-partage-entre-conteneursCKAD Guide compagnon
-
Lab guidé 10m · débutant · machines virtuelles
Exposer un Deployment par un Service ClusterIP
Déployer trois replicas d'un serveur et les exposer par un Service interne. Prouver depuis un client que le Service répond par son nom, et qu'il répartit réellement les requêtes entre les trois Pods.
dsoxlab start ckad-expose-serviceCKAD Guide compagnon
-
Lab guidé 15m · intermédiaire · machines virtuelles
Durcir un Pod avec un securityContext
Faire tourner un serveur web sans privilège : utilisateur non root, aucune escalade, racine en lecture seule, toutes les capabilities retirées. Et lui donner quand même de quoi écrire là où il en a besoin, sinon il ne démarre pas. Prouver, de l'intérieur, que le confinement agit et que l'application sert.
dsoxlab start ckad-security-context-hardenedCKAD Guide compagnon
-
Lab guidé 15m · intermédiaire · machines virtuelles
Donner un accès en lecture seule aux Pods avec RBAC
Permettre à une utilisatrice de lire les Pods d'un namespace et leurs logs, et rien de plus : ni créer, ni supprimer, ni voir les autres namespaces. Prouver les deux côtés avec kubectl auth can-i, ce qui est permis et ce qui reste refusé.
dsoxlab start ckad-rbac-role-rolebindingCKAD Guide compagnon
-
Lab guidé 20m · intermédiaire · machines virtuelles
Cloisonner trois tiers avec des NetworkPolicy ingress et egress
Frontend, backend, base de données : n'autoriser que les flux prévus, dans les deux sens, DNS compris, et interdire tout le reste. Prouver chaque règle par une vraie connexion, celle qui passe et celle qui est bloquée.
dsoxlab start ckad-networkpolicy-ingress-egressCKAD Guide compagnon
-
Lab guidé 15m · intermédiaire · machines virtuelles
Régler une mise à jour progressive : maxSurge et maxUnavailable
Contraindre la façon dont un Deployment remplace ses Pods, jamais plus de deux en trop ni plus d'un indisponible, puis déclencher une mise à jour d'image et prouver qu'elle est allée au bout : ancienne révision à zéro, nouvelle au complet.
dsoxlab start ckad-rolling-update-strategyCKAD Guide compagnon
-
Lab guidé 15m · intermédiaire · machines virtuelles
Basculer le trafic d'une version à l'autre : blue-green
Faire tourner deux versions d'une application côte à côte, et basculer tout le trafic de l'une à l'autre en changeant le selector d'un Service. Prouver la bascule depuis un client : toutes les requêtes atteignent la nouvelle version, aucune l'ancienne.
dsoxlab start ckad-blue-green-deploymentCKAD Guide compagnon
-
Lab guidé 20m · intermédiaire · machines virtuelles
Une base Kustomize et deux overlays, dev et prod
Décrire une application une seule fois, dans une base Kustomize, et la déployer dans deux namespaces avec des overlays qui changent le nombre de replicas, préfixent les noms et ajoutent un label d'environnement. Prouver que les deux environnements tournent et se ressemblent.
dsoxlab start ckad-kustomize-overlaysCKAD Guide compagnon
-
Lab guidé 15m · intermédiaire · machines virtuelles
Installer, mettre à jour et revenir en arrière avec Helm 4
Déployer un chart avec Helm, le mettre à jour avec de nouvelles valeurs, puis revenir à la première révision. Prouver par l'historique de la release et par l'état du Deployment que les trois opérations ont eu lieu, dans cet ordre.
dsoxlab start ckad-helm-install-upgradeCKAD Guide compagnon
-
Lab guidé 15m · débutant · machines virtuelles
Un Job à complétions parallèles et un CronJob
Exécuter un traitement quatre fois, deux à la fois, avec un Job, et prouver que les exécutions se sont bien chevauchées. Puis planifier un nettoyage toutes les cinq minutes avec un CronJob qui garde un historique borné.
dsoxlab start ckad-job-cronjobCKAD Guide compagnon
-
Lab guidé 10m · avancé · machines virtuelles
Redimensionner un Pod en place, sans le redémarrer
Augmenter le CPU et la mémoire d'un Pod qui tourne, sans le recréer ni redémarrer son conteneur, par la sous-ressource resize. Prouver que le noyau applique la nouvelle limite et que le conteneur est resté le même.
dsoxlab start ckad-in-place-pod-vertical-scalingCKAD Guide compagnon
-
Lab guidé 10m · débutant · machines virtuelles
Un Pod bloqué par un ConfigMap qui n'existe pas
Un Pod ne démarre pas et ne dit rien dans ses logs, parce qu'il n'a pas encore de conteneur : ce sont ses events qui parlent. Lire la cause, créer la ressource manquante avec le contenu attendu, et prouver que l'application sert.
dsoxlab start ckad-troubleshoot-missing-configmapCKAD Guide compagnon
-
Lab guidé 15m · intermédiaire · machines virtuelles
Trois Pods en CrashLoopBackOff, trois causes
Trois Pods redémarrent en boucle pour trois raisons différentes : une commande qui n'existe pas, une variable d'environnement absente, une limite de mémoire trop basse. Lire pour chacun ce qui le tue, le corriger, et prouver que les trois tiennent.
dsoxlab start ckad-troubleshoot-crashloopCKAD Guide compagnon
-
Examen blanc réussite 66 % 45m · avancé · machines virtuelles
Capstone : livrer la boutique, à partir du seul cahier des charges
Une livraison complète, donnée comme un cahier des charges et non comme un mode d'emploi. Six exigences à satisfaire dans un namespace : configuration, secret, sondes, identité, exposition et isolation. Rien ne dit quel objet créer, et le dernier test vérifie la seule chose qui compte : un Pod frontend joint la boutique, un Pod qui n'en est pas un ne la joint pas.
dsoxlab start ckad-capstone-boutiqueCKAD Guide compagnon
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-podCKS 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-profileCKS 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-admissionCKS 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-podCKS 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-immutableCKS 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-gvisorCKS 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-digestCKS 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-policyCKS 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-trivyCKS 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-imageCKS 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-analysisCKS 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-privilegeCKS 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-hardeningCKS 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-policyCKS 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-denyCKS 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-lockdownCKS 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-tlsCKS 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-remediateCKS 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-enclaveCKS Guide compagnon