Que fait Benchmarking Kubernetes avec kube-bench ?
Présentation
kube-bench (par Aqua Security) est un outil open-source qui vérifie si un cluster Kubernetes est déployé de manière sécurisée en exécutant les contrôles documentés dans le CIS Kubernetes Benchmark. Il inspecte les composants du plan de contrôle (API server, controller manager, scheduler, etcd), la configuration du kubelet et des nœuds workers, ainsi que les paramètres de politique à l'échelle du cluster, puis signale chaque contrôle comme PASS, FAIL, WARN ou INFO avec une recommandation de correction issue directement des directives du CIS. Les tests sont basés sur des fichiers YAML de configuration, ce qui permet à kube-bench de suivre les nouvelles versions de Kubernetes et les révisions du benchmark, et de prendre en charge les distributions managées (EKS, GKE, AKS, ACK, OpenShift, RKE, k3s).
Durcir un cluster conformément au CIS Benchmark réduit directement la surface d'attaque pour T1610 (Deploy Container) , où un adversaire déploie un conteneur pour exécuter du code ou contourner les défenses — par exemple en abusant des conteneurs privilégiés, des namespaces hôtes, de l'accès API anonyme ou des paramètres kubelet non sécurisés qu'un cluster non durci laisse exposés.
kube-bench peut être exécuté en tant que binaire autonome sur un nœud, dans un conteneur, ou — le plus souvent — en tant que Job Kubernetes dont le pod monte le système de fichiers hôte pour pouvoir lire les fichiers de configuration pertinents. La sortie est disponible sous forme de texte lisible, JSON, JUnit ou AWS Security Finding Format (ASFF) et peut être poussée vers une base de données PostgreSQL pour le suivi des tendances.
Quand l'utiliser
- Lors de l'établissement d'une base de sécurité pour un nouveau cluster Kubernetes conformément au CIS Kubernetes Benchmark.
- Lors de la réalisation d'audits de conformité périodiques du durcissement du plan de contrôle et des nœuds.
- Lors de la validation des corrections après application de modifications de durcissement (réexécuter pour confirmer que les contrôles sont maintenant PASS).
- Lors de l'intégration du scan de conformité du cluster dans un pipeline CI/CD ou une chaîne de surveillance continue.
- Lors de la préparation de preuves pour les normes SOC 2, PCI DSS ou le durcissement de conformité interne.
Prérequis
- Accès au cluster : accès SSH à un nœud du plan de contrôle/workeur (mode binaire) ou
kubectlavec autorisation de créer des Jobs (mode in-cluster). - Connaissance de la version de Kubernetes du cluster (kube-bench la détecte automatiquement, ou spécifier avec
--version/--benchmark). - Installer kube-bench (méthodes officielles d'Aqua Security) :
# Version binaire (Linux)
KB_VERSION=0.10.7
curl -L -o kube-bench.tgz \
"https://github.com/aquasecurity/kube-bench/releases/download/v${KB_VERSION}/kube-bench_${KB_VERSION}_linux_amd64.tar.gz"
tar -xzf kube-bench.tgz
sudo mv kube-bench /usr/local/bin/
sudo cp -R cfg /etc/kube-bench/cfg
# Via Go install
go install github.com/aquasecurity/kube-bench@latest
# Exécution en tant que conteneur unique directement sur un nœud (monte la config hôte)
docker run --rm --pid=host \
-v /etc:/etc:ro -v /var:/var:ro \
-t docker.io/aquasec/kube-bench:latest run --targets node
# Vérification
kube-bench version
Objectifs
- Exécuter kube-bench avec le benchmark approprié pour la version de Kubernetes du cluster.
- Scanner le plan de contrôle (master), les nœuds, etcd, les politiques du plan de contrôle et les cibles des services managés.
- Produire une sortie JSON/JUnit lisible par machine pour les pipelines et les tableaux de bord.
- Trier les résultats FAIL et WARN et appliquer les recommandations de correction du CIS.
- Réexécuter pour valider que les corrections sont maintenant PASS.
Cartographie MITRE ATT&CK
| ID de technique | Nom | Tactic | Pertinence |
|---|---|---|---|
| T1610 | Deploy Container | Execution / Defense Evasion | Le durcissement du CIS Benchmark imposé par kube-bench restreint les déploiements privilégiés/dans les namespaces hôtes, l'accès API anonyme et les paramètres kubelet non sécurisés que les adversaires abusent lorsqu'ils déploient des conteneurs malveillants. |
Workflow
1. Exécuter le scan par défaut (détection automatique)
Exécuter toutes les cibles applicables, en laissant kube-bench détecter la version de Kubernetes et le benchmark :
sudo kube-bench
2. Exécuter en tant que Job Kubernetes (in-cluster)
Appliquer le manifeste de Job fourni depuis le dépôt kube-bench et lire les résultats depuis les logs du pod :
# Job générique
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
# Attendre, puis récupérer les résultats
kubectl get pods -l app=kube-bench
kubectl logs -l app=kube-bench
# Des Jobs spécifiques à chaque plateforme sont disponibles, ex. EKS :
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job-eks.yaml
3. Cibler des composants spécifiques
Utiliser run --targets pour limiter le scan à des groupes de composants particuliers :
# Plan de contrôle (API server, scheduler, controller manager)
sudo kube-bench run --targets master
# Nœud workeur (kubelet, proxy)
sudo kube-bench run --targets node
# Datastore etcd
sudo kube-bench run --targets etcd
# Politiques à l'échelle du cluster (RBAC, sécurité des pods, politique réseau)
sudo kube-bench run --targets policies
# Combiner plusieurs cibles
sudo kube-bench run --targets master,node,etcd,policies
4. Fixer un benchmark ou une version de Kubernetes spécifique
Lorsque la détection automatique est erronée ou que vous devez auditer avec une révision spécifique, fixez le benchmark explicitement :
# Fixer une révision spécifique du CIS Benchmark
sudo kube-bench run --benchmark cis-1.8
# Ou mapper par version de Kubernetes
sudo kube-bench --version 1.27
# Benchmarks spécifiques aux distributions managées
sudo kube-bench run --benchmark eks-1.5.0
sudo kube-bench run --benchmark gke-1.6.0
sudo kube-bench run --benchmark rke2-cis-1.7
5. Exécuter ou ignorer des contrôles individuels
Se concentrer sur ou exclure des ID de contrôle spécifiques lors des cycles de correction :
# Exécuter uniquement des contrôles spécifiques
sudo kube-bench run --targets master --check 1.2.1,1.2.2
# Ignorer les contrôles bruyants/connus comme acceptés
sudo kube-bench run --targets node --skip 4.2.6
6. Produire une sortie lisible par machine
Émettre du JSON ou JUnit pour ingestion dans des pipelines, SIEM ou tableaux de bord, et écrire dans un fichier :
# JSON vers un fichier
sudo kube-bench run --targets master,node --json --outputfile kube-bench-report.json
# JUnit (pour les rapports de tests CI)
sudo kube-bench --junit --outputfile kube-bench-junit.xml
# AWS Security Finding Format (pour Security Hub)
sudo kube-bench run --targets node --asff
7. Trier et corriger les résultats FAIL/WARN
Chaque contrôle échoué affiche une correction. Appliquer le correctif recommandé par le CIS sur le nœud/manifeste, par exemple en resserrant les flags de l'API server dans le manifeste de pod statique :
# Exemple de correction pour un FAIL courant du plan de contrôle :
# CIS 1.2.x — s'assurer que anonymous-auth est désactivé sur l'API server.
# Modifier le manifeste de pod statique et définir le flag :
sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml
# - --anonymous-auth=false
# Le kubelet redémarre automatiquement le pod statique.
# Exemple de correction pour un nœud — permissions du fichier de configuration kubelet (CIS 4.1.x) :
sudo chmod 600 /etc/kubernetes/kubelet/kubelet-config.json
sudo chown root:root /etc/kubernetes/kubelet/kubelet-config.json
8. Revalider après correction
Réexécuter la cible concernée et confirmer que les contrôles auparavant échoués sont maintenant PASS, puis suivre le score dans le temps :
sudo kube-bench run --targets master --check 1.2.1 --json --outputfile recheck.json
# Optionnel : persister les résultats dans PostgreSQL pour le suivi des tendances
sudo kube-bench run --targets master,node --pgsql
Outils et ressources
| Outil / Ressource | Objectif | Lien |
|---|---|---|
| kube-bench | Vérificateur du CIS Kubernetes Benchmark | https://github.com/aquasecurity/kube-bench |
| docs kube-bench | Exécution / plateformes / flags | https://aquasecurity.github.io/kube-bench/ |
| CIS Kubernetes Benchmark | Norme de durcissement source | https://www.cisecurity.org/benchmark/kubernetes |
| Trivy Operator | Scan continu de conformité + vulnérabilités in-cluster | https://github.com/aquasecurity/trivy-operator |
| kube-hunter | Outil complémentaire de test d'intrusion | https://github.com/aquasecurity/kube-hunter |
Critères de validation
- kube-bench installé (
kube-bench version) ou exécuté en tant que Job. - Scan exécuté avec le bon benchmark pour la version de Kubernetes du cluster.
- Cibles master, node, etcd et policies scannées.
- Sortie JSON/JUnit produite pour ingestion dans pipeline/tableau de bord.
- Résultats FAIL et WARN triés et priorisés.
- Corrections CIS appliquées aux manifestes du plan de contrôle et aux configurations des nœuds.
- Réexécution confirmant que les contrôles auparavant échoués sont maintenant PASS.
- Résultats suivis dans le temps (archive de fichiers ou PostgreSQL).