CIS Kubernetes Benchmark : auditer la sécurité de votre cluster

Le CIS Kubernetes Benchmark est un ensemble de recommandations de sécurité développé par le Center for Internet Security (CIS). kube-bench est l'outil open-source de référence pour vérifier automatiquement la conformité de votre cluster à ces guidelines. En quelques minutes, vous obtenez un rapport détaillé des points à corriger.

Ce que vous allez apprendre

Situer le CIS Kubernetes Benchmark et ce qu'il couvre réellement
Installer kube-bench en binaire vérifié, en paquet ou en Job Kubernetes
Lancer un audit et cibler les bonnes sections avec --targets
Lire les statuts PASS, FAIL, WARN et appliquer les remédiations proposées
Distinguer un vrai écart d'un faux positif lié à votre distribution
Automatiser l'audit en CI/CD et en CronJob

Qu'est-ce que le CIS Kubernetes Benchmark ?

Le CIS (Center for Internet Security) est une organisation à but non lucratif qui publie des guidelines de sécurité pour de nombreuses technologies. Le CIS Kubernetes Benchmark est la référence mondiale pour sécuriser un cluster Kubernetes.

Ce que couvre le benchmark

Le benchmark analyse la configuration de tous les composants Kubernetes :

Domaine	Composants vérifiés	Exemples de contrôles
Control Plane	API Server, Controller Manager, Scheduler, etcd	Permissions des fichiers, arguments de sécurité
Worker Nodes	Kubelet, configuration réseau	Authentification kubelet, rotation des certificats
Policies	RBAC, Service Accounts, Network Policies	Principe du moindre privilège, segmentation réseau
Pod Security	Pod Security Standards, Security Contexts	Conteneurs non-root, capabilities

Les niveaux de recommandation

Chaque contrôle du benchmark est classé selon deux axes :

Classification	Signification
Level 1	Recommandations de base, faciles à implémenter, impact minimal sur la fonctionnalité
Level 2	Recommandations avancées, peuvent nécessiter plus de planification
Scored	Le contrôle affecte le score de conformité
Not Scored	Recommandation, mais pas comptabilisée dans le score

Dans les versions récentes du benchmark, la sortie de kube-bench n'affiche plus « Scored » et « Not Scored » mais (Automated) et (Manual). La distinction est la même : un contrôle Automated est évalué par l'outil et compte dans le score, un contrôle Manual demande une vérification humaine. Les options --scored et --unscored permettent de restreindre l'exécution à l'une des deux catégories.

Ce que kube-bench ne fait pas

kube-bench vérifie uniquement la conformité CIS des configurations Kubernetes. Il ne couvre pas d'autres aspects de la sécurité :

Ce que kube-bench fait	Ce que kube-bench ne fait PAS
Vérifier les permissions des fichiers de config	Scanner les vulnérabilités des images de conteneurs
Contrôler les arguments des composants K8s	Détecter les comportements suspects en runtime
Auditer les configurations RBAC	Analyser le trafic réseau
Vérifier les paramètres kubelet	Scanner les CVE des dépendances applicatives

Pour une sécurité complète, combinez kube-bench avec :

Trivy : scan des vulnérabilités d'images et configurations IaC
Falco : détection runtime des comportements anormaux
Audit Logs : traçabilité des actions sur l'API

Installer kube-bench

kube-bench est développé par Aqua Security et disponible en open-source. Plusieurs méthodes d'installation existent selon votre contexte.

Option 1 : Installation binaire (control plane)

Cette méthode est idéale pour les clusters autogérés où vous avez accès SSH aux nœuds. Le projet publie un fichier de sommes de contrôle à côté de chaque archive : téléchargez les deux et vérifiez l'empreinte avant d'extraire, c'est ce qui distingue une installation contrôlée d'un téléchargement à l'aveugle sur une machine du control plane.

# Créer le répertoire d'installation
sudo mkdir -p /opt/kube-bench
cd /tmp

# Télécharger l'archive ET le fichier de sommes publié par le projet
curl -sSLO https://github.com/aquasecurity/kube-bench/releases/download/v0.15.6/kube-bench_0.15.6_linux_amd64.tar.gz
curl -sSLO https://github.com/aquasecurity/kube-bench/releases/download/v0.15.6/kube-bench_0.15.6_checksums.txt

# Vérifier l'intégrité : la sortie doit afficher "... : OK"
sha256sum --check --ignore-missing kube-bench_0.15.6_checksums.txt

# Extraire les fichiers seulement si la vérification est passée
sudo tar -xzf kube-bench_0.15.6_linux_amd64.tar.gz -C /opt/kube-bench

# Ajouter au PATH
sudo mv /opt/kube-bench/kube-bench /usr/local/bin/

L'option --ignore-missing évite que sha256sum échoue sur les autres architectures listées dans le fichier de sommes, que vous n'avez pas téléchargées.

Vérification :

kube-bench version
# Output: 0.15.6

Option 2 : Installation via package manager

Les paquets .deb et .rpm publiés par le projet ont un avantage sur l'archive : ils installent le binaire et le répertoire de configuration cfg au bon endroit, ce qui évite l'erreur décrite plus haut. Ils ne sont pas diffusés par un dépôt, donc ils ne se mettront pas à jour tout seuls : vous restez responsable du suivi de version. Comme pour l'archive, le fichier de sommes couvre aussi ces paquets.

Pour Debian/Ubuntu :

curl -sSLO https://github.com/aquasecurity/kube-bench/releases/download/v0.15.6/kube-bench_0.15.6_linux_amd64.deb
curl -sSLO https://github.com/aquasecurity/kube-bench/releases/download/v0.15.6/kube-bench_0.15.6_checksums.txt
sha256sum --check --ignore-missing kube-bench_0.15.6_checksums.txt
sudo dpkg -i kube-bench_0.15.6_linux_amd64.deb

Pour RHEL/CentOS :

curl -sSLO https://github.com/aquasecurity/kube-bench/releases/download/v0.15.6/kube-bench_0.15.6_linux_amd64.rpm
curl -sSLO https://github.com/aquasecurity/kube-bench/releases/download/v0.15.6/kube-bench_0.15.6_checksums.txt
sha256sum --check --ignore-missing kube-bench_0.15.6_checksums.txt
sudo rpm -ivh kube-bench_0.15.6_linux_amd64.rpm

Option 3 : Exécution en tant que Job Kubernetes

Cette méthode est recommandée pour les clusters managés (EKS, AKS, GKE) ou lorsque vous n'avez pas accès SSH aux nœuds :

# Déployer le job kube-bench (workers uniquement)
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml

# Attendre la fin de l'exécution
kubectl wait --for=condition=complete job/kube-bench --timeout=60s

# Récupérer les résultats
kubectl logs job/kube-bench

Pour scanner le control plane et etcd depuis un Job (clusters autogérés), utilisez un Job avec hostPID: true et les volumes nécessaires :

apiVersion: batch/v1
kind: Job
metadata:
  name: kube-bench-cp
  namespace: kube-system
spec:
  template:
    spec:
      hostPID: true
      nodeSelector:
        node-role.kubernetes.io/control-plane: ""
      tolerations:
        - key: node-role.kubernetes.io/control-plane
          operator: Exists
          effect: NoSchedule
      containers:
        - name: kube-bench
          image: aquasec/kube-bench:v0.15.6@sha256:861900910eec45b54a97e4a2af81b16fae7203d768f7f8e7de3b7456807870f5
          command: ["kube-bench", "run", "--targets", "master,controlplane,etcd,node"]
          volumeMounts:
            - name: var-lib-etcd
              mountPath: /var/lib/etcd
              readOnly: true
            - name: etc-kubernetes
              mountPath: /etc/kubernetes
              readOnly: true
            - name: var-lib-kubelet
              mountPath: /var/lib/kubelet
              readOnly: true
      restartPolicy: Never
      volumes:
        - name: var-lib-etcd
          hostPath:
            path: /var/lib/etcd
        - name: etc-kubernetes
          hostPath:
            path: /etc/kubernetes
        - name: var-lib-kubelet
          hostPath:
            path: /var/lib/kubelet

Exécuter les vérifications CIS

Scan complet du cluster

Sur un nœud control plane (avec binaire installé), lancez un scan complet :

# Scan avec auto-détection de la version K8s et des fichiers de config
sudo kube-bench run

Le résultat affiche trois sections pour chaque contrôle :

[INFO] 1 Control Plane Security Configuration
[INFO] 1.1 Control Plane Node Configuration Files
[PASS] 1.1.1 Ensure that the API server pod specification file permissions are set to 600 or more restrictive (Automated)
[PASS] 1.1.2 Ensure that the API server pod specification file ownership is set to root:root (Automated)
[FAIL] 1.1.9 Ensure that the Container Network Interface file permissions are set to 600 or more restrictive (Manual)
[WARN] 1.1.12 Ensure that the etcd data directory ownership is set to etcd:etcd (Manual)

Comprendre les résultats

Traitez ces quatre statuts avec des priorités différentes. Un FAIL est un écart mesuré, sur lequel kube-bench a pu se prononcer : c'est là que vous commencez. Un WARN signale un contrôle que l'outil ne sait pas évaluer seul, souvent parce qu'il dépend d'un chemin ou d'un composant que seul un humain peut confirmer ; il ne veut pas dire « moins grave ». Ne calculez jamais un pourcentage de conformité en ignorant les WARN, vous obtiendriez un score flatteur et faux.

Statut	Signification	Action
PASS	Le contrôle est conforme	Aucune action requise
FAIL	Le contrôle échoue	Correction requise
WARN	Vérification manuelle recommandée	À investiguer
INFO	Information contextuelle	Lecture uniquement

Exporter les résultats

Le format compte selon le destinataire. Le texte convient à une lecture humaine ponctuelle, le JSON à un traitement automatisé ou à un tableau de bord, le JUnit à une plateforme de CI qui sait afficher des tests en échec directement dans l'interface d'un pipeline. Notez que l'option --outputfile existe et évite la redirection shell, utile quand le programme écrit aussi des messages de log sur la sortie standard.

# Export en fichier texte
sudo kube-bench run > kube-bench-report.txt

# Export en JSON (pour intégration CI/CD)
sudo kube-bench run --json > kube-bench-report.json

# Export en JUnit (pour intégration CI)
sudo kube-bench run --junit > kube-bench-report.xml

Scanner des composants spécifiques

Un point que presque tout le monde se fait avoir : les noms passés à --targets correspondent aux noms de fichiers du profil, dans cfg/<benchmark>/. Or master et controlplane sont deux cibles distinctes, pas un ancien et un nouveau nom. Dans le profil cis-1.12 :

Cible	Section CIS	Ce qu'elle contient
`master`	1, Control Plane Security Configuration	Permissions des manifests, arguments de l'API Server, du scheduler et du controller manager
`etcd`	2, Etcd Node Configuration	Configuration et certificats d'etcd
`controlplane`	3, Control Plane Configuration	Authentification, autorisation, journalisation d'audit
`node`	4, Worker Node Security Configuration	Fichiers et paramètres kubelet
`policies`	5, Kubernetes Policies	RBAC, Service Accounts, Pod Security, Network Policies

Autrement dit, pour auditer les composants du control plane (API Server, Controller Manager, Scheduler), la cible est master, pas controlplane. Vous pouvez lister le contenu du profil pour vous en assurer : ls /opt/kube-bench/cfg/cis-1.12/.

# Configuration des composants du control plane (section 1)
sudo kube-bench run --targets master

# Configuration d'authentification et d'audit du control plane (section 3)
sudo kube-bench run --targets controlplane

# Scanner uniquement les worker nodes
sudo kube-bench run --targets node

# Scanner uniquement etcd
sudo kube-bench run --targets etcd

# Scanner uniquement les policies
sudo kube-bench run --targets policies

# Plusieurs cibles en une passe
sudo kube-bench run --targets master,etcd,controlplane

Interpréter et remédier aux problèmes

Exemple de rapport

La sortie se termine toujours par deux blocs qu'il faut lire ensemble : un résumé chiffré par section, puis les remédiations correspondant aux contrôles en échec. Ce second bloc est ce qui rend kube-bench directement exploitable, il ne se contente pas de constater mais donne la commande ou l'argument à appliquer. Les remédiations restent volontairement génériques, avec des espaces réservés du type <path/to/cni/files> : à vous de retrouver le chemin réel sur votre nœud.

== Summary controlplane ==
41 checks PASS
9 checks FAIL
11 checks WARN
0 checks INFO

== Remediations controlplane ==
1.1.9 Run the below command (based on the file location on your system) on the control plane node.
For example, chmod 600 <path/to/cni/files>

1.1.12 On the etcd server node, get the etcd data directory, passed as an argument --data-dir,
from the command 'ps -ef | grep etcd'.
Run the below command (based on the etcd data directory found above).
For example, chown etcd:etcd /var/lib/etcd

Corrections courantes

Les quatre corrections ci-dessous couvrent la majorité des FAIL d'un cluster kubeadm fraîchement installé. Elles sont classées par risque croissant : les deux premières touchent des permissions de fichiers et sont sans effet sur le service, les deux suivantes modifient le comportement du cluster et peuvent le rendre indisponible en cas d'erreur de syntaxe. Sauvegardez le manifeste avant de l'éditer et vérifiez que le Pod statique redémarre bien avant d'enchaîner.

Permissions des fichiers de configuration

# Corriger les permissions de l'API Server
sudo chmod 600 /etc/kubernetes/manifests/kube-apiserver.yaml

# Corriger les permissions du scheduler
sudo chmod 600 /etc/kubernetes/manifests/kube-scheduler.yaml

# Corriger les permissions du controller manager
sudo chmod 600 /etc/kubernetes/manifests/kube-controller-manager.yaml

Ownership des fichiers etcd

# Vérifier le répertoire de données etcd
ps -ef | grep etcd | grep data-dir

# Corriger le propriétaire
sudo chown -R etcd:etcd /var/lib/etcd

Arguments de sécurité de l'API Server

Éditez /etc/kubernetes/manifests/kube-apiserver.yaml :

spec:
  containers:
  - command:
    - kube-apiserver
    # Activer l'audit logging
    - --audit-log-path=/var/log/kubernetes/audit/audit.log
    - --audit-policy-file=/etc/kubernetes/audit-policy.yaml
    - --audit-log-maxage=30
    - --audit-log-maxbackup=10
    - --audit-log-maxsize=100
    # Désactiver les tokens anonymes
    - --anonymous-auth=false
    # Activer le chiffrement des secrets
    - --encryption-provider-config=/etc/kubernetes/enc/enc.yaml

Configuration du kubelet

Éditez /var/lib/kubelet/config.yaml :

# Désactiver l'authentification anonyme
authentication:
  anonymous:
    enabled: false

# Activer la rotation des certificats
rotateCertificates: true

# Activer l'autorisation webhook
authorization:
  mode: Webhook

Profils pour clusters managés

kube-bench inclut des profils spécifiques pour les principaux cloud providers. Les noms de benchmark évoluent régulièrement, vérifiez la documentation officielle pour les versions les plus récentes.

La source de vérité la plus fiable reste votre propre installation : chaque profil est un sous-répertoire de cfg/. Un ls suffit à connaître exactement ce que votre binaire accepte derrière --benchmark, et évite l'erreur can't find configuration for sur un nom de profil inventé.

ls /opt/kube-bench/cfg/
# ack-1.0  aks-1.0  aks-1.7  aks-1.8  cis-1.10  cis-1.11  cis-1.12  ...
# eks-1.5.0  eks-1.7.0  eks-1.8.0  gke-1.6.0  gke-1.8.0  gke-1.9.0
# k3s-cis-1.9  rke2-cis-1.8  rh-1.8  cis-1.24-microk8s  ...

# Configuration spécifique AWS EKS
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job-eks.yaml

# Ou via Docker (vérifiez le benchmark disponible pour votre version EKS)
docker run --rm -v /etc:/etc:ro -v /var:/var:ro \
  aquasec/kube-bench:v0.15.6 run --benchmark eks-1.5.0

# Configuration spécifique Azure AKS
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job-aks.yaml

# Ou via Docker (profils AKS disponibles : aks-1.0, aks-1.7, aks-1.8)
docker run --rm -v /etc:/etc:ro -v /var:/var:ro \
  aquasec/kube-bench:v0.15.6 run --benchmark aks-1.8

# Configuration spécifique Google GKE
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job-gke.yaml

# Ou via Docker
docker run --rm -v /etc:/etc:ro -v /var:/var:ro \
  aquasec/kube-bench:v0.15.6 run --benchmark gke-1.6.0

Depuis kube-bench 0.15.5, un profil dédié k3s (k3s-cis-1.9) couvre les spécificités de cette distribution légère : service kubelet intégré, chemins de configuration propres à k3s. Pratique pour auditer un cluster k3s ou k3d en périphérie.

# Scan d'un nœud k3s/k3d (worker + policies applicatives)
docker run --rm -v /etc:/etc:ro -v /var:/var:ro \
  aquasec/kube-bench:v0.15.6 run --benchmark k3s-cis-1.9 --targets node,policies

Intégration CI/CD

Pipeline GitLab CI

Ce pipeline exécute kube-bench à chaque merge request ou déploiement, génère des rapports JSON et JUnit, et échoue si des contrôles CIS sont en échec, garantissant ainsi que les régressions de sécurité sont détectées avant mise en production :

security-audit:
  stage: security
  image: aquasec/kube-bench:v0.15.6@sha256:861900910eec45b54a97e4a2af81b16fae7203d768f7f8e7de3b7456807870f5
  script:
    # Générer le rapport JSON pour analyse
    - kube-bench run --json > kube-bench-results.json
    # Générer le rapport JUnit pour GitLab
    - kube-bench run --junit > kube-bench-results.xml
    - |
      FAIL_COUNT=$(jq '[.Controls[].results[] | select(.status == "FAIL")] | length' kube-bench-results.json)
      if [ "$FAIL_COUNT" -gt "0" ]; then
        echo "Echec : $FAIL_COUNT controles CIS en erreur"
        exit 1
      fi
  artifacts:
    paths:
      - kube-bench-results.json
    reports:
      junit: kube-bench-results.xml

kube-bench propose une alternative plus directe au comptage jq : l'option --exit-code fixe le code de retour utilisé quand au moins un contrôle échoue. kube-bench run --exit-code 1 suffit alors à faire tomber le job, sans dépendre du format JSON. Gardez la variante jq si vous voulez tolérer un seuil d'échecs connus plutôt qu'un zéro absolu.

CronJob Kubernetes

Un audit ponctuel ne dit rien de la dérive. Le CronJob ci-dessous relance kube-bench chaque nuit et rend visible toute régression introduite par une mise à jour de cluster ou une modification manuelle. Deux points de vigilance : l'image est épinglée sur une version précise plutôt que sur latest, sans quoi vos résultats changent sans que rien n'ait bougé côté cluster ; et le hostPID: true combiné aux montages de /etc/kubernetes confère à ce Pod un accès très large, à réserver à un namespace dédié avec un RBAC restreint.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: kube-bench-scheduled
  namespace: security
spec:
  schedule: "0 2 * * *"  # Tous les jours à 2h
  jobTemplate:
    spec:
      template:
        spec:
          hostPID: true
          containers:
          - name: kube-bench
            image: aquasec/kube-bench:v0.15.6@sha256:861900910eec45b54a97e4a2af81b16fae7203d768f7f8e7de3b7456807870f5
            command: ["kube-bench"]
            args: ["run", "--json"]
            volumeMounts:
            - name: var-lib-kubelet
              mountPath: /var/lib/kubelet
              readOnly: true
            - name: etc-kubernetes
              mountPath: /etc/kubernetes
              readOnly: true
          volumes:
          - name: var-lib-kubelet
            hostPath:
              path: /var/lib/kubelet
          - name: etc-kubernetes
            hostPath:
              path: /etc/kubernetes
          restartPolicy: Never

Faux positifs et distributions spécifiques

kube-bench peut signaler des échecs qui sont en réalité des faux positifs, selon la distribution Kubernetes utilisée. Chaque distribution a ses propres conventions de configuration.

Distributions avec profils dédiés

kube-bench détecte automatiquement certaines distributions et applique le profil approprié :

Distribution	Profil	Particularités
RKE2	`rke2-cis-*`	Fichiers dans `/etc/rancher/rke2/`, etcd intégré
RKE	`rke-cis-*`	Composants du control plane en conteneurs
k3s	`k3s-cis-*`	Architecture légère, chemins non standards
OpenShift	`rh-*`	Profil Red Hat spécifique (`rh-0.7` à `rh-1.8`)
kubeadm	`cis-*`	Profil CIS standard
microk8s	`cis-1.24-microk8s`	Profil dédié aux chemins snap
Alibaba ACK	`ack-1.0`	Profil du fournisseur
Tanzu TKGI	`tkgi-1.2.53`	Profil du fournisseur

Exemples de faux positifs courants

Un faux positif suit presque toujours le même schéma : le contrôle cherche un fichier ou un processus à un emplacement standard que votre distribution a déplacé. Avant de conclure, appliquez ce réflexe : lisez le texte du contrôle, retrouvez le chemin réel sur votre nœud avec ps -ef ou ls, et comparez. Si la configuration attendue existe bien mais ailleurs, c'est un faux positif ; si elle n'existe nulle part, c'est un vrai écart.

RKE2/k3s :

Les fichiers de configuration sont dans /etc/rancher/ au lieu de /etc/kubernetes/
etcd peut être intégré au binaire, pas en tant que processus séparé

Kubespray :

Le propriétaire etcd peut être root au lieu de etcd:etcd selon la configuration
Certains arguments de sécurité sont dans des fichiers de drop-in systemd

Clusters managés :

Les checks du control plane échouent car vous n'avez pas accès aux nœuds masters

Documenter les exceptions

Une exception non écrite redevient un écart au prochain audit, et personne ne se souvient pourquoi elle avait été acceptée. Versionnez ce fichier à côté de votre infrastructure et exigez trois informations pour chaque entrée : la raison technique, la personne qui a validé et la date. C'est ce document, et non le rapport brut de kube-bench, que vous présenterez à un auditeur.

Le format ci-dessous est une convention d'équipe, pas un format lu par kube-bench. Pour que l'outil ignore réellement un contrôle à l'exécution, utilisez l'option --skip, par exemple --skip 1.1.12,4.2.6.

# exceptions-cis.yaml - Contrôles ignorés volontairement
exceptions:
  - control: "1.1.12"
    reason: "etcd géré par RKE2, ownership root attendu"
    reviewed_by: "security-team"
    date: "2026-03-15"
  - control: "4.2.6"
    reason: "ProtectKernelDefaults désactivé pour compatibilité drivers GPU"
    reviewed_by: "security-team"
    date: "2026-03-15"

Alternatives à kube-bench

Ces outils ne s'excluent pas : ils interviennent à des moments différents. Checkov analyse vos manifestes avant déploiement, kube-bench et Kubescape auditent le cluster une fois déployé, Trivy couvre en plus les images. Si vous préparez la CKS, restez sur kube-bench, c'est le seul outil de cette liste explicitement associé au benchmark CIS dans les objectifs de l'examen.

Outil	Avantages	Inconvénients
kube-bench	Référence, simple, CNCF	Uniquement CIS Benchmark
Kubescape	Multi-frameworks (CIS, NSA, MITRE)	Plus complexe
Checkov	Multi-cloud, IaC	Focus IaC, moins K8s runtime
Trivy	Scanner polyvalent	CIS = une partie des features

Bonnes pratiques

Le piège classique du CIS Benchmark est l'audit unique : on corrige tout une fois, on archive le rapport, et six mois plus tard le cluster a dérivé sans que personne ne le sache. Les cinq points ci-dessous visent à transformer l'audit en mesure récurrente. Le cinquième est le moins intuitif : kube-bench choisit son profil selon la version de Kubernetes détectée, un cluster mis à jour sans mise à jour de kube-bench peut donc se retrouver évalué avec un profil obsolète.

Planifier les audits : Exécutez kube-bench au minimum mensuellement, idéalement à chaque changement de configuration
Prioriser les corrections : Commencez par les contrôles FAIL de Level 1
Documenter les exceptions : Certains contrôles peuvent être inapplicables à votre contexte
Automatiser : Intégrez kube-bench dans votre CI/CD
Suivre les versions : Mettez à jour kube-bench avec votre version Kubernetes

Conseils pour la certification CKS

Ce qui est attendu à l'examen

L'examen CKS est pratique et chronométré : on ne vous demandera pas de réciter la structure du benchmark, mais de corriger un cluster en un temps limité. Les cinq compétences ci-dessous forment donc une chaîne unique : lancer l'outil, lire le rapport, appliquer la remédiation, relancer pour confirmer. Entraînez-vous surtout sur les deux dernières, l'édition des manifests du control plane et du fichier kubelet, ce sont elles qui font perdre du temps quand on hésite sur le chemin.

Exécuter kube-bench et identifier les contrôles en échec
Interpréter les résultats : comprendre PASS, FAIL, WARN
Appliquer les remédiations suggérées par kube-bench
Modifier les manifests du control plane (/etc/kubernetes/manifests/)
Configurer le kubelet (/var/lib/kubelet/config.yaml)

Commandes essentielles à connaître

Quatre invocations couvrent l'essentiel des situations d'examen. La troisième, --check, est celle qui fait gagner le plus de temps : après une correction, elle rejoue un seul contrôle au lieu du scan complet, en quelques secondes au lieu d'une minute. Elle accepte une liste séparée par des virgules.

# Scan des composants du control plane (section 1)
kube-bench run --targets master

# Scan des workers uniquement
kube-bench run --targets node

# Filtrer sur un contrôle spécifique
kube-bench run --check 1.1.1

# Exporter en JSON pour analyse
kube-bench run --json | jq '.Controls[].results[] | select(.status=="FAIL")'

Erreurs fréquentes à éviter

Ces trois erreurs partagent une caractéristique désagréable en examen : aucune ne produit un message clair. Sans sudo, kube-bench ne plante pas, il signale simplement des échecs sur des fichiers qu'il n'a pas pu lire. Avec la mauvaise cible, il retourne un rapport parfaitement valide, mais d'une autre section que celle demandée. Vérifiez donc toujours que le rapport porte bien sur ce que vous croyez avoir demandé avant de conclure.

Oublier sudo : kube-bench a besoin des permissions root pour lire les fichiers système
Confondre les targets : master couvre la section 1 (composants du control plane), controlplane couvre la section 3 (authentification et audit). Les deux existent, ce ne sont pas des synonymes
Ne pas redémarrer les services : après modification du kubelet, exécutez systemctl restart kubelet

À retenir

Le CIS Kubernetes Benchmark définit les standards de sécurité pour Kubernetes
kube-bench automatise la vérification de conformité
Les résultats indiquent PASS, FAIL, WARN pour chaque contrôle
Les remédiations sont fournies directement dans le rapport
Sur les clusters managés, seuls les worker nodes et policies sont vérifiables
L'intégration CI/CD permet des audits automatiques et continus

Testez vos connaissances

Dix questions pour vérifier que l'essentiel est acquis, en particulier le point qui piège le plus : savoir quelle cible scanner selon le composant visé, et ne pas confondre master avec controlplane.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

10 questions

8 min.

70% requis

Informations

Le chronomètre démarre au clic sur Démarrer
Questions à choix multiples, vrai/faux et réponses courtes
Vous pouvez naviguer entre les questions
Les résultats détaillés sont affichés à la fin

Prochaines étapes

Falco : détection runtime Détectez les comportements suspects en temps réel

Audit Logs Kubernetes Tracez toutes les actions sur votre cluster

Network Policies Segmentez le trafic réseau entre pods

Pod Security Standards Appliquez des politiques de sécurité aux pods