~10 minutes
Cet article fait partie de la série Sécurité Kubernetes. Si vous cherchez l’introduction et le sommaire complet, commencez par là.
Introduction aux benchmarks CIS
Qu’est-ce que CIS ?
Le Center for Internet Security publie des guides de durcissement reconnus mondialement. Pour Kubernetes, CIS maintient des benchmarks détaillés couvrant :
- Control Plane Components (API Server, Controller Manager, Scheduler, etcd)
- Worker Nodes (Kubelet, kube-proxy)
- Policies (Pod Security Standards, Network Policies, RBAC)
- Managed Services (EKS, GKE, AKS avec leurs spécificités)
On constate que beaucoup d’équipes ignorent ces benchmarks ou les considèrent comme optionnels. C’est une erreur : ils représentent le socle minimal de conformité sécurité pour tout cluster Kubernetes en production.
Versions des benchmarks
CIS publie des versions alignées sur les releases Kubernetes :
| Benchmark CIS | Kubernetes Version | Statut |
|---|---|---|
| CIS 1.8.0 | 1.27+ | Actuel |
| CIS 1.7.1 | 1.23-1.26 | Stable |
| CIS 1.6.1 | 1.19-1.22 | Legacy |
Niveaux de sécurité
On commence toujours par le Level 1. Vouloir attaquer le Level 2 directement mène souvent à l’abandon face à la complexité. Le Level 1, c’est 80% de la valeur pour 20% de l’effort.
Level 1 : Configuration de base
- Impact minimal sur les fonctionnalités
- Recommandé pour tous les environnements
- Facile à implémenter
Level 2 : Configuration renforcée
- Peut impacter certaines fonctionnalités
- Recommandé pour environnements haute sécurité
- Nécessite validation approfondie
Architecture et fonctionnement de kube-bench
Présentation
kube-bench est un outil Go développé par Aqua Security. Il constitue le standard de fait pour auditer la sécurité des clusters Kubernetes selon les benchmarks CIS. L’outil lit les fichiers de configuration et les arguments des processus Kubernetes, puis les compare aux règles CIS. Pas de magie, pas d’agent permanent : un scan ponctuel et précis.
Principe de fonctionnement
L’architecture est simple et efficace :
- Lecture des fichiers de configuration du cluster (manifestes statiques, configs kubelet, certificats)
- Lecture des arguments de processus des composants K8s en cours d’exécution
- Comparaison avec les règles du benchmark CIS sélectionné
- Production d’un rapport avec statuts : PASS, FAIL, WARN, INFO ou Manual Review
Types de vérifications effectuées
| Catégorie | Ce qui est vérifié |
|---|---|
| Fichiers de configuration | Manifestes statiques dans /etc/kubernetes/manifests/, configs dans /etc/kubernetes/, config kubelet |
| Arguments de processus | Flags de démarrage des composants K8s, variables d’environnement |
| Permissions fichiers | Propriétaires et permissions des fichiers critiques, certificats et clés privées |
| Requêtes API Server | Configurations RBAC, Pod Security, Network Policies, ressources cluster-wide |
Installation et déploiement
Modes de déploiement
On peut déployer kube-bench de trois manières principales :
1. Binaire autonome : on télécharge le binaire Go depuis les releases GitHub d’Aqua Security et on l’exécute directement sur un noeud du cluster. C’est la méthode la plus rapide pour un audit ponctuel.
2. Job Kubernetes : on déploie un Job qui s’exécute sur les noeuds control-plane et/ou workers. Le Job monte les volumes nécessaires (fichiers de configuration, certificats) en lecture seule et produit un rapport JSON. C’est la méthode recommandée pour les audits réguliers car elle ne nécessite pas d’accès SSH aux noeuds.
3. DaemonSet pour audit continu : on déploie un DaemonSet qui exécute kube-bench périodiquement sur tous les noeuds et envoie les résultats vers un système de monitoring. C’est la méthode à privilégier pour le monitoring continu de conformité.
Points d’attention pour le déploiement
- Le Job nécessite
hostPID: truepour inspecter les processus en cours - Les volumes hostPath doivent être montés en lecture seule (
readOnly: true) - Sur les noeuds control-plane, il faut ajouter les tolerations appropriées
- Pour les clusters managés (EKS, GKE, AKS), on ne peut auditer que les worker nodes et les policies, le control-plane étant géré par le fournisseur cloud
Configuration et options principales
Benchmarks disponibles
kube-bench supporte plusieurs benchmarks selon l’environnement :
| Environnement | Benchmark | Cibles disponibles |
|---|---|---|
| Kubernetes vanilla | cis-1.8 |
master, node, etcd, policies |
| Amazon EKS | eks-1.2.0 |
node, policies, managedservices |
| Google GKE | gke-1.2.0 |
node, policies |
| Azure AKS | aks-1.0.0 |
node, policies |
Options clés
Les options les plus utiles en pratique :
- Sélection des cibles : on peut cibler uniquement les masters, les nodes, etcd ou les policies selon le périmètre d’audit
- Format de sortie : JSON pour l’intégration automatisée, texte pour la lecture humaine
- Filtrage des checks : possibilité d’ignorer certains checks par ID (utile quand un écart est accepté et documenté)
- Checks scorés uniquement : se concentrer sur les contrôles comptabilisés dans le score CIS
Configuration personnalisée
On peut personnaliser la configuration pour adapter kube-bench à un environnement spécifique :
- Chemins des fichiers : indiquer où se trouvent les fichiers de configuration si l’environnement utilise des chemins non standard
- Exclusions documentées : certains checks peuvent être légitimement désactivés (par exemple, health checks nécessitant un port spécifique)
- Checks custom : possibilité d’ajouter ses propres vérifications en plus du benchmark CIS standard
Interprétation des résultats
Statuts de sortie
Chaque vérification produit un statut :
| Statut | Signification | Action requise |
|---|---|---|
| PASS | Conforme au benchmark CIS | Aucune |
| FAIL (scored) | Non conforme, comptabilisé dans le score | Action immédiate |
| FAIL (non-scored) | Non conforme, non comptabilisé | Recommandation forte |
| WARN | Nécessite une vérification manuelle | À évaluer selon le contexte |
| INFO | Informatif | Pas d’action requise |
Priorisation des remédiations
On recommande de prioriser selon cette logique :
- FAIL scored + mots-clés critiques (privilege, root, admin, escalation) : risque d’escalade de privilèges, à corriger en priorité absolue
- FAIL scored restants : conformité CIS non respectée, à corriger rapidement
- FAIL non-scored : bonnes pratiques non respectées, à planifier
- WARN : à évaluer selon le contexte opérationnel
Un cluster qui obtient moins de 80% de PASS sur les checks scorés Level 1 présente des risques significatifs et nécessite un plan de remédiation immédiat.
Intégration CI/CD
Principes d’intégration
Un audit de sécurité qui n’est pas automatisé est un audit qui sera oublié. On intègre kube-bench dans les pipelines CI/CD selon ces principes :
- Quality gate : bloquer un déploiement si le nombre d’échecs scorés dépasse un seuil défini
- Audit pré-déploiement : vérifier la conformité avant chaque mise en production
- Audit post-déploiement : valider que le déploiement n’a pas introduit de régressions
- Audit planifié : exécution quotidienne ou hebdomadaire pour détecter les dérives
Bonnes pratiques d’intégration
- Définir un seuil d’échecs maximum acceptable (par exemple : 3 échecs scorés maximum)
- Générer un rapport consultable dans les artifacts du pipeline
- Commenter les PR avec les résultats pour sensibiliser les développeurs
- Envoyer des alertes (Slack, Teams, email) en cas de régression de conformité
- Historiser les résultats pour suivre l’évolution du score dans le temps
Monitoring continu de conformité
Pourquoi le monitoring continu ?
Le monitoring continu de la conformité CIS est le seul moyen de détecter les régressions. On observe régulièrement des clusters passant de 95% à 60% de conformité en une semaine suite à un déploiement mal maîtrisé ou un changement de configuration non contrôlé.
Architecture de monitoring recommandée
L’approche recommandée combine :
- Exécution périodique : kube-bench tourne toutes les heures ou toutes les 4 heures via un CronJob ou DaemonSet
- Stockage des résultats : envoi vers Elasticsearch, Prometheus ou tout système de métriques
- Visualisation : dashboard Grafana ou Kibana montrant l’évolution du score de conformité
- Alerting : notifications quand le score passe sous un seuil ou quand de nouveaux échecs critiques apparaissent
Métriques clés à surveiller
| Métrique | Description | Seuil d’alerte recommandé |
|---|---|---|
| Score de conformité global | % de checks PASS | < 80% |
| Échecs critiques (scored) | Nombre de FAIL scored | > 5 |
| Delta entre deux scans | Nouveaux FAIL depuis le dernier scan | > 0 |
| Échecs par composant | Répartition FAIL par type (master, node, policies) | Variable |
Cas d’usage pour les clusters managés
Spécificités des clusters managés
Pour les clusters managés, le périmètre d’audit est réduit puisque le control-plane est géré par le fournisseur cloud :
Amazon EKS :
- On utilise le benchmark
eks-1.2.0spécialisé - Les checks master et etcd sont inapplicables (gérés par AWS)
- Focus sur les worker nodes, les policies et les configurations spécifiques EKS (VPC CNI, IRSA, Pod Identity)
Google GKE :
- On utilise le benchmark
gke-1.2.0 - Spécificités : Container-Optimized OS sur les nodes, Workload Identity, Binary Authorization
- Focus sur les nodes et policies
Azure AKS :
- On utilise le benchmark
aks-1.0.0 - Spécificités : Azure CNI vs kubenet, Azure Key Vault integration, Entra ID pour le RBAC
- Focus sur les nodes et policies
Complémentarité avec les outils natifs cloud
kube-bench complète les outils de sécurité natifs des fournisseurs cloud :
- AWS : Inspector, GuardDuty, Security Hub
- GCP : Security Command Center, Binary Authorization
- Azure : Defender for Containers, Azure Policy
On recommande d’utiliser kube-bench en complément (et non en remplacement) de ces outils natifs pour avoir une vue unifiée multi-cloud de la conformité CIS.
Quelques références pour aller plus loin
- kube-bench sur GitHub (Aqua Security)
- CIS Kubernetes Benchmark
- OWASP Kubernetes Security Cheat Sheet
- OWASP Kubernetes Top 10
- ✓ kube-bench est le standard de fait pour l'audit CIS de clusters Kubernetes, développé par Aqua Security.
- ✓ Automatiser dans la CI/CD : un audit non automatisé est un audit qui sera oublié. Définir un seuil d'échecs maximum comme quality gate.
- ✓ Level 1 d'abord : commencer par les contrôles de base avant de s'attaquer au Level 2. C'est 80% de la valeur pour 20% de l'effort.
- ✓ Adapter aux clusters managés : EKS, GKE et AKS ont leurs propres benchmarks CIS. Le control-plane n'est pas auditable sur ces plateformes.
- ✓ Combiner avec d'autres outils : kube-bench seul ne suffit pas. On complète avec kube-hunter (pentest), Polaris (best practices) et Falco (runtime).