Auditer et durcir un cluster Kubernetes avec kube-bench

Un audit Kubernetes utile ne consiste pas à collectionner des échecs rouges dans un rapport. Il faut relier chaque écart à une exposition réelle, corriger dans un ordre qui préserve le cluster, puis vérifier que la correction survit aux mises à jour et aux reconstructions de nœuds.

→ Lire l’explication complète de la marmotte

Périmètre Kubernetes, prérequis et compromis

kube-bench compare la configuration d’un cluster aux recommandations du CIS (Center for Internet Security) Kubernetes Benchmark. Il inspecte notamment le serveur d’API (Application Programming Interface), le magasin de données etcd, les composants du plan de contrôle, le kubelet et la configuration des nœuds. Ce n’est pas un scanner de vulnérabilités des images, ni un analyseur de droits applicatifs complet.

Le compromis central est net : suivre le benchmark augmente le cloisonnement et réduit les privilèges implicites, mais peut casser une extension, un opérateur ou une intégration d’infrastructure qui vivait confortablement sur un accès excessif. La recommandation est de viser la conformité CIS comme référence de configuration, puis d’accepter explicitement et temporairement les exceptions documentées. Désactiver un contrôle parce qu’un composant opaque le réclame n’est pas une stratégie, c’est une dette avec un gyrophare.

Avant l’exécution, identifier la distribution Kubernetes, sa version exacte et le mode d’hébergement. Un cluster managé masque souvent le plan de contrôle : kube-bench ne peut pas évaluer les fichiers ou processus administrés par le fournisseur. Ces contrôles doivent être déclarés N/A avec une justification et couverts par les garanties contractuelles, les journaux accessibles et la configuration exposée par le fournisseur. Un échec sur un composant inaccessible n’est pas une remédiation possible, seulement un rappel que le périmètre de responsabilité existe.

Prévoir les éléments suivants :

un accès administrateur au cluster, limité dans le temps et journalisé ;
une version de kube-bench compatible avec la version Kubernetes auditée ;
un accès aux nœuds, ou un mécanisme autorisé pour exécuter un conteneur privilégié sur chaque nœud ;
les manifestes du plan de contrôle, les paramètres du kubelet et la configuration du runtime de conteneurs ;
une sauvegarde testée d’etcd avant toute modification du plan de contrôle ;
une fenêtre de changement pour les correctifs qui redémarrent kubelet, API server ou scheduler.

Le RBAC (Role Based Access Control) doit être inspecté séparément : kube-bench détecte quelques paramètres d’activation, pas les délégations métier qui transforment un compte de lecture en administrateur de fait. La page sur les identités aide à replacer cette revue dans une gouvernance d’accès cohérente. Pour les flux interservices, compléter l’audit par les contrôles réseau décrits dans l’architecture réseau et conteneurs.

Exécuter kube-bench sur les nœuds du cluster

Exécuter kube-bench comme DaemonSet garantit une observation par nœud. Le conteneur doit voir le système de fichiers de l’hôte et les processus locaux, ce qui impose des privilèges élevés. C’est précisément le genre de composant qui ne doit pas rester installé par confort : créer, exécuter, exporter le résultat, supprimer. Un scanner permanent avec accès hôte devient vite un outil de sécurité qui demande lui-même un audit. Ironie assez classique du métier.

L’exemple suivant lance kube-bench sur les nœuds Linux, collecte les résultats puis supprime le DaemonSet. Adapter l’image au benchmark correspondant à la version ciblée.

# Exécution ponctuelle : supprimer cette ressource après export des résultats.
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: kube-bench
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: kube-bench
  template:
    metadata:
      labels:
        app: kube-bench
    spec:
      hostPID: true # Nécessaire pour inspecter les processus de l'hôte.
      tolerations:
        - operator: Exists # Inclure les nœuds portant un taint.
      containers:
        - name: kube-bench
          image: aquasec/kube-bench:v0.10.4
          command: ["sh", "-c", "kube-bench run --json > /host/var/tmp/kube-bench-$(hostname).json; sleep 3600"]
          securityContext:
            privileged: true # À accepter uniquement pour cette opération contrôlée.
          volumeMounts:
            - name: rootfs
              mountPath: /host
      volumes:
        - name: rootfs
          hostPath:
            path: /

Appliquer le manifeste, attendre qu’un pod soit planifié par nœud, puis récupérer les fichiers sous /var/tmp. Conserver le résultat JSON (JavaScript Object Notation) avec la version de Kubernetes, l’horodatage et l’identifiant de configuration du cluster. Le rapport texte est pratique pour lire, le JSON sert à comparer les itérations sans confondre un changement de règle avec un progrès réel.

Ne jamais exécuter ce manifeste dans un namespace ouvert aux développeurs, ni accorder le droit de modifier ce DaemonSet à un groupe large. Le montage de la racine hôte et le mode privilégié permettent une prise de contrôle complète du nœud. Le mot « audit » ne transforme pas un accès racine en tisane.

Trier les contrôles CIS et prioriser la remédiation

Traiter les résultats par catégorie est une erreur fréquente. Prioriser par chemin d’attaque et impact, pas par ordre d’affichage. Un écart critique sur l’exposition du serveur d’API passe avant cinquante permissions de fichier trop larges sur un nœud isolé. La conformité qui commence par réparer les voyants est une décoration réglementaire, pas une réduction du risque.

Placer en priorité 1 les écarts qui permettent de compromettre le plan de contrôle ou d’en extraire les secrets :

serveur d’API accessible depuis des réseaux non maîtrisés ;
authentification anonyme activée ;
autorisation AlwaysAllow au lieu du RBAC ;
port d’etcd exposé sans chiffrement TLS (Transport Layer Security) ni authentification mutuelle ;
fichiers de certificats ou clés privées lisibles par des comptes non administrateurs ;
journaux d’audit désactivés ou stockés sur un volume éphémère.

Placer en priorité 2 les écarts qui facilitent le mouvement latéral depuis un nœud ou un pod : kubelet accessible sans authentification forte, ports en lecture seule actifs, admission de pods privilégiés sans exception contrôlée, ou absence de restriction sur les volumes hostPath. Activer PSA (Pod Security Admission) en mode warn et audit avant le mode enforce permet d’inventorier les charges incompatibles. Passer directement à l’application bloquante sur un cluster ancien est une méthode fiable pour découvrir, à une heure créative, quel agent de supervision dépendait de privilèges indéfendables.

La priorité 3 couvre les réglages d’hygiène : permissions locales, profils de chiffrement, paramètres de journalisation insuffisants, comptes système inutilisés. Ces écarts restent à corriger, mais ne doivent pas retarder la fermeture d’une interface d’administration publiquement atteignable.

Pour chaque constat, produire une fiche courte : identifiant CIS, actif affecté, exposition, dépendance potentiellement cassée, propriétaire technique, correctif, test de non-régression, date de réexamen. Une exception doit expirer. Une exception sans date est une fonctionnalité non documentée, avec le niveau de confiance associé.

Remédier sans casser le plan de contrôle

Modifier un paramètre du serveur d’API exige de connaître le mécanisme de déploiement. Sur un plan de contrôle auto-administré par des pods statiques, modifier le manifeste sous /etc/kubernetes/manifests déclenche généralement un redémarrage par kubelet. Vérifier la haute disponibilité avant : sur un seul nœud de contrôle, la modification coupe nécessairement le service pendant le redémarrage.

Activer les journaux d’audit impose une politique de rétention et une destination résistante à l’altération. Les événements doivent au minimum permettre de reconstruire les créations de pods, modifications de droits, accès aux secrets et appels d’administration. Éviter de journaliser les corps complets des requêtes contenant des secrets : une collecte exhaustive peut déplacer la fuite vers le système de journalisation. Le chiffrement au repos des objets Kubernetes protège les données dans etcd, mais ne protège ni un administrateur autorisé, ni un pod qui lit un secret déjà monté.

La rotation des certificats du plan de contrôle et des jetons de comptes de service doit être testée. Un certificat renouvelé mais non rechargé laisse des processus avec l’ancienne identité. Un jeton révoqué ne coupe pas forcément une session déjà établie ou un cache d’autorisation encore valide. Prévoir les délais de propagation, les redémarrages nécessaires et le retour arrière.

Après chaque lot, rejouer kube-bench, comparer le JSON et exécuter des tests fonctionnels : planification d’un pod non privilégié, résolution réseau, accès aux registres, sauvegarde et restauration d’etcd, authentification des administrateurs. Une sauvegarde non restaurée n’est pas une sauvegarde, c’est un fichier optimiste.

Surface d’attaque et limites de kube-bench

kube-bench ne garantit pas qu’un cluster est sûr. Il vérifie des paramètres observables selon un benchmark, pas les intentions. Un cluster conforme peut exposer une application vulnérable, accepter une image compromise ou contenir un rôle RBAC trop large. Inversement, un écart CIS peut être compensé par une isolation fournisseur, sans devenir souhaitable par magie.

Compléter l’audit par :

une revue des rôles RBAC et des liaisons de rôles ;
un inventaire des secrets, de leurs consommateurs et de leur rotation ;
des politiques réseau limitant les flux pod à pod et vers l’extérieur ;
la signature et l’analyse des images de conteneurs ;
une revue des admission controllers, notamment les politiques empêchant privilèges, capacités Linux dangereuses et images non approuvées ;
une supervision des appels d’administration, redémarrages de kubelet et créations de pods privilégiés.

Un résultat d’audit doit aussi être surveillé dans le temps. Rejouer kube-bench après une montée de version Kubernetes, un changement de distribution, une modification d’Infrastructure as Code, ou l’ajout d’un opérateur. Les paramètres de sécurité régressent souvent par dépendance : une mise à jour rétablit une valeur par défaut, un script de bootstrap écrase une permission, puis tout le monde célèbre le déploiement vert. Les principes de gouvernance servent justement à attribuer cette surveillance, au lieu de la confier au folklore.

🐝 Ce qui arrive si on s’en passe

Sans audit et durcissement du cluster, les écarts de configuration de Kubernetes restent des portes ouvertes que personne ne relie à une exposition réelle. Des permissions trop larges, des composants accessibles sans authentification ou des réglages laxistes laissent un attaquant, une fois un pied dans un conteneur, viser l’API du cluster, rebondir vers d’autres charges de travail ou atteindre le plan de contrôle. L’absence de vérification régulière signifie aussi que ces écarts reviennent silencieusement à chaque mise à jour ou reconstruction de nœud, annulant des corrections que personne n’a retestées. La conséquence est un cluster dont la surface d’attaque dérive sans qu’on le sache, où les entrées réellement dangereuses ne sont pas fermées en priorité faute de les avoir reliées à leur impact. Les alarmes débranchées et les accès trop larges ressortent seulement quand la tempête est déjà passée.

🦫 Explication de la marmotte 🍫

Un cluster Kubernetes est un ensemble de machines qui lancent et surveillent des applications. Certaines machines décident quoi lancer et gardent des informations très sensibles, comme des mots de passe techniques et des droits d’accès. L’audit commence par identifier la version du logiciel, les machines accessibles et celles qui sont gérées par un fournisseur externe.

L’outil kube-bench lit ensuite la configuration des machines et compare chaque réglage à une liste de protections reconnues. Il cherche par exemple un accès ouvert sans contrôle, des fichiers secrets lisibles par trop de comptes, ou des journaux absents. Il ne modifie rien seul. Son rapport montre des écarts, pas des preuves qu’une attaque a déjà réussi.

Les écarts sont classés selon leurs conséquences. Un accès qui permet de contrôler toutes les machines doit être fermé avant un réglage local moins dangereux. Chaque correction est testée, car changer la sécurité peut empêcher une application ancienne ou un outil de surveillance de fonctionner. Certaines modifications redémarrent des services essentiels : une sauvegarde testée est donc nécessaire avant de les appliquer.

Après les corrections, le même contrôle est relancé pour vérifier le résultat. Il faut aussi examiner les droits des comptes, les programmes installés et les échanges entre applications, car l’outil ne couvre pas tout. Enfin, l’audit doit revenir après chaque mise à jour : une configuration corrigée peut redevenir fragile si un nouveau réglage remplace l’ancien.

Pages voisines

La citent

Auditer et durcir un cluster Kubernetes avec kube-bench

Elle cite

Auditer et durcir un cluster Kubernetes avec kube-bench

Auditer et durcir un cluster Kubernetes avec kube-bench

Périmètre Kubernetes, prérequis et compromis

Exécuter kube-bench sur les nœuds du cluster

Trier les contrôles CIS et prioriser la remédiation

Remédier sans casser le plan de contrôle

Surface d’attaque et limites de kube-bench

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines