L’examen Certified Kubernetes Security Specialist (CKS) est une évaluation axée sur la pratique et indépendante de tout fournisseur ; il porte sur les tâches de sécurité Kubernetes effectuées en ligne de commande sur des clusters Kubernetes. Il s’appuie actuellement sur Kubernetes v1.35, mais la Linux Foundation aligne l’environnement sur une version mineure récente de Kubernetes ; il convient donc de vérifier la version actuelle et le programme avant de se fier à une commande, une fonctionnalité ou une pondération de domaine spécifique. Les six domaines couverts sont : la configuration du cluster (15 %), le renforcement de la sécurité du cluster (15 %), le renforcement de la sécurité du système (10 %), la réduction des vulnérabilités des microservices (20 %), la sécurité de la chaîne d’approvisionnement (20 %), ainsi que la surveillance, la journalisation et la sécurité à l’exécution (20 %). L’examen est basé sur la pratique et surveillé à distance : vous devez accomplir plusieurs tâches en ligne de commande dans un délai de deux heures, et avoir préalablement obtenu la certification Certified Kubernetes Administrator (CKA).
Examinons maintenant le déroulement des tâches et la répartition actuelle des domaines.
Une tâche CKS est considérée comme terminée lorsque l’état de sécurité requis est établi et que vous disposez de la preuve que le mécanisme de contrôle Kubernetes correspondant l’applique effectivement. Mémoriser une commande permet certes de créer rapidement un objet, mais cela ne garantit pas qu’une charge de travail (workload) est bien sélectionnée par une politique, qu’une identité ne dispose que des autorisations API prévues, ou qu’une règle de détection observe le comportement d’exécution attendu. Avant de modifier la configuration, prenez connaissance des exigences concernant la ressource cible, le périmètre de sécurité et les indicateurs de vérification nécessaires.
Lorsque le temps est compté, produisez des artefacts simples et faciles à examiner. Il s’agit généralement d’un manifeste déclarant l’état souhaité, d’une commande ciblée pour l’appliquer ou l’inspecter, et d’une sortie affichant l’objet ou le comportement résultant de la modification. Un manifeste atteste de la configuration soumise à l’API Kubernetes. La sortie d’une commande ne prouve que l’état de la ressource ou la réponse observée à un instant T, au sein du cluster et du namespace sélectionnés. Aucun de ces éléments ne suffit à lui seul à garantir la sécurité de tous les chemins d’accès.
Adoptez une méthode itérative. Commencez par identifier le contexte du cluster actif et le namespace cible. Ensuite, examinez les objets et les labels existants qui déterminent la sélection des politiques ou la portée des autorisations. Appliquez la modification minimale répondant à la condition énoncée, puis vérifiez le résultat par une observation adaptée à cette condition. Enfin, conservez suffisamment d’informations contextuelles pour pouvoir annuler une modification erronée, en particulier lors de changements affectant la configuration globale du cluster, les fichiers des nœuds ou les paramètres du serveur API.
Règle opérationnelle Privilégiez les preuves directement liées au périmètre requis plutôt que l’utilisation d’une commande familière qui modifierait des ressources sans rapport avec l’objectif.
Tout au long de ce cours, nous sécuriserons une charge de travail fictive liée au commerce de détail, située dans le namespace shop. Un namespace est un périmètre Kubernetes regroupant des ressources spécifiques à cet espace ; il peut servir de limite pour la gestion des autorisations et des politiques. La charge de travail dispose d’un point d’entrée (ingress) accessible depuis l’extérieur vers orders-api:1.0 sur le port 8080 ; cette application appelle payments-api:1.0 sur le port 8443, laquelle utilise ensuite orders-db. Dans ce modèle, aucune autre charge de travail n’est accessible depuis l’extérieur du cluster, à l’exception du point d’entrée.
Chaque application utilise son propre ServiceAccount, une identité Kubernetes qu’un Pod peut employer pour appeler l’API Kubernetes. Ainsi, orders-api utilise orders-sa, tandis que payments-api utilise payments-sa. Dissocier ces identités nous permet de tester l’autorisation fondée sur le principe du moindre privilège indépendamment de l’accessibilité réseau, de la provenance des images, des restrictions appliquées aux Pods et des signaux d’exécution. La règle réutilisable consiste à identifier le chemin de la charge de travail et la limite d’identité avant de choisir une mesure de sécurité.
Nous pouvons désormais délimiter la charge de travail, une frontière que les mesures de défense ultérieures devront préserver.