Examen blanc CKS 02

Un second examen blanc indépendant de type CKS, composé de 20 défis de sécurité Kubernetes couvrant les domaines officiels du CKS à travers divers scénarios de sécurité opérationnelle.

KubernetesFormation CKS

💡 Ce tutoriel est traduit par l'IA à partir de la version anglaise. Pour voir la version originale, vous pouvez cliquer ici

Programme

Configuration du cluster
Renforcement du cluster
Renforcement du système
Réduction des vulnérabilités des microservices
Sécurité de la chaîne d'approvisionnement
Surveillance, journalisation et sécurité à l'exécution

Introduction

CKS Practice Exam 02 est une deuxième évaluation pratique autonome pour appliquer la sécurité Kubernetes sous contrainte de temps. Elle comprend 20 défis indépendants répartis entre six domaines alignés sur CKS, pour une durée totale recommandée de 120 minutes. Chaque tâche vaut 5 points et 67 points représentent le seuil de réussite simulé par LabEx.

Cette session propose d’autres scénarios opérationnels que Practice Exam 01 : protection des flux sortants vers un endpoint de type métadonnées, limitation du proxy API, durcissement des services et journaux hôte, admission de registres fiables, vérification hors ligne d’une signature, images sans secrets de build, analyse d’une sortie Helm et confinement d’incidents. Vous devrez atteindre et prouver l’état final dans chaque nouvel environnement, sans solution guidée.

Ce que vous apprendrez

  • Créer des politiques egress précises qui préservent DNS et les services approuvés tout en bloquant des endpoints de métadonnées, locataires ou suspects
  • Remplacer les droits génériques ou une identité divulguée par un RBAC limité et une gestion plus sûre des jetons ServiceAccount
  • Réduire la surface d’attaque hôte en désactivant un service de débogage et en imposant un accès minimal aux journaux
  • Appliquer des limites Pod Security, renouveler des Secrets exposés et remplacer un stockage hostPath dangereux
  • Limiter les registres d’images par une politique d’admission native et vérifier hors ligne une version signée avant déploiement
  • Retirer les identifiants de build des images finales et corriger les manifestes rendus par Helm avec KubeLinter
  • Corréler des preuves d’audit, de workload et d’exécution délimitées pour restaurer une politique et contenir une compromission

À qui s’adresse ce cours

Ce cours s’adresse aux administrateurs Kubernetes, ingénieurs plateforme et spécialistes de la sécurité qui souhaitent une autre épreuve complète de type CKS ou un test exigeant de leurs capacités de remédiation autonome. Il suppose que vous savez diagnostiquer l’état actif de Kubernetes et Linux sans instructions pas à pas.

Prérequis : Administration Kubernetes de niveau CKA, avec une bonne maîtrise de kubectl, YAML, workloads, réseau, RBAC, ServiceAccounts et commandes Linux de base pour les services et permissions. Practice Exam 01 et les cours CKA LabEx ne sont pas requis.

Environnement d’apprentissage : Vingt VM Ubuntu 22.04 isolées accessibles dans le navigateur, chacune avec Kubernetes v1.34 préparé sur un seul nœud. Manifestes, certificats, constats, signatures, clés publiques, charts Helm, données d’analyse, sommes de contrôle, extraits d’audit et images locales sont préparés dans la VM concernée ; aucun registre externe ni incident de production n’est nécessaire.

Questions fréquentes

Practice Exam 02 est-il la suite de Practice Exam 01 ?

Non. C’est une épreuve complète indépendante couvrant les mêmes grands domaines par des scénarios différents. Vous pouvez commencer par l’une ou l’autre ; elles ne partagent ni état ni fichiers.

S’agit-il d’un examen CKS officiel ?

Non. C’est une ressource d’apprentissage LabEx indépendante. Les 120 minutes, le barème sur 100 et le seuil de 67 points sont des paramètres simulés et ne donnent aucun résultat de certification officiel.

Le cours utilise-t-il de vrais contrôles d’admission, hôte et d’exécution ?

Oui. Vous manipulez RBAC, NetworkPolicy, l’admission Pod Security, ValidatingAdmissionPolicy, l’état systemd, les permissions Linux et des workloads actifs. Les dépendances externes risquées sont remplacées par des endpoints locaux contrôlés, des artefacts préparés et des preuves d’audit délimitées.

Faut-il Internet pour les registres, signatures ou scanners ?

Non. Les images approuvées sont locales ou en cache, les éléments de signature sont fournis pour une vérification hors ligne et les entrées Helm/KubeLinter sont dans la VM. La politique de registres est testée avec des dry runs côté serveur, sans téléchargement distant.

Enseignant

labby
Labby
Labby is the LabEx teacher.

Recommandé pour vous

no data