Mauvaises configurations RBAC critiques dans Kubernetes permettant une prise de contrôle complète du cluster

#1 — Permissions génériques (wildcard) dans les ClusterRoles

La mauvaise configuration la plus répandue : 23 % des clusters ont des ClusterRoles personnalisés avec des verbes ou des ressources génériques (*). Les équipes copient le rôle cluster-admin comme point de départ et oublient de le restreindre. Un seul pod dont le compte de service est lié à un tel rôle dispose d'un accès illimité à chaque ressource dans chaque espace de noms — secrets, configmaps, nœuds, et le serveur API lui-même.

# Dangereux : ClusterRole avec permissions génériques
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: devops-tools
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]        # ← Équivalent d'un cluster-admin complet

#2 — Abus du compte de service par défaut

Chaque espace de noms Kubernetes dispose d'un compte de service default qui est automatiquement monté dans les pods sauf désactivation explicite. Dans 41 % des clusters, le compte de service par défaut d'au moins un espace de noms s'est vu attribuer des permissions élevées — souvent parce qu'un opérateur a exécuté rapidement un kubectl create rolebinding pendant le débogage et ne l'a jamais nettoyé. Les attaquants qui obtiennent une exécution de code à distance dans n'importe quel pod de cet espace de noms héritent immédiatement de ces permissions.

#3 — ClusterRoleBindings excessifs

34 % des clusters ont plus de 10 ClusterRoleBindings personnalisés — des liaisons qui accordent des permissions sur tous les espaces de noms. Beaucoup lient des rôles étendus à des groupes comme system:authenticated ou system:serviceaccounts, accordant de fait un accès élevé à chaque utilisateur authentifié ou à chaque compte de service du cluster.

#4 — Évasion de l'espace de noms via la création de pods

Les utilisateurs disposant de la permission create pods dans n'importe quel espace de noms peuvent monter le système de fichiers de l'hôte, exécuter des conteneurs privilégiés, ou créer des pods avec n'importe quel compte de service de cet espace de noms. Dans 29 % des clusters, les développeurs disposent de droits de création de pods sans application des Pod Security Standards — permettant une évasion de conteneur triviale vers le nœud sous-jacent.

#5 — Montage automatique de jetons dans des pods privilégiés

Kubernetes monte par défaut les jetons de compte de service dans les pods. Combiné à des spécifications de pod privilégiées ou à un accès au réseau de l'hôte, les attaquants peuvent voler le jeton et s'authentifier auprès du serveur API depuis l'extérieur du cluster. Seuls 12 % des clusters analysés définissent automountServiceAccountToken: false sur les charges de travail qui n'ont pas besoin d'accès à l'API.

Audit RBAC automatisé avec KENSAI

Le module de sécurité Kubernetes de KENSAI inclut désormais une analyse RBAC automatisée qui cartographie chaque compte de service, rôle et liaison dans votre cluster afin d'identifier les chemins d'élévation de privilèges. Le scanner génère un graphe visuel des chaînes de permissions et met en évidence le chemin le plus court entre n'importe quelle charge de travail compromise et le niveau cluster-admin.

Principe du moindre privilège pour les comptes de service

Chaque charge de travail devrait disposer de son propre compte de service dédié avec uniquement les permissions dont elle a réellement besoin. Évitez de lier des ClusterRoles lorsque des Roles limités à l'espace de noms suffisent. Utilisez automountServiceAccountToken: false pour les pods qui n'ont pas besoin d'accès à l'API Kubernetes — ce qui est le cas de la majorité des charges de travail applicatives.

Appliquer les Pod Security Standards

Les Pod Security Standards (PSS) de Kubernetes au niveau restricted empêchent les pods de s'exécuter en tant que root, de monter des chemins de l'hôte, ou d'utiliser le mode privilégié. Appliquez-les au niveau de l'espace de noms via Pod Security Admission. Cela élimine le vecteur d'évasion de conteneur même si les permissions RBAC sont trop larges.

Révisions RBAC régulières

Mettez en place des audits RBAC trimestriels. Passez en revue tous les ClusterRoleBindings, identifiez les liaisons obsolètes provenant d'anciens membres de l'équipe ou de services mis hors service, et vérifiez qu'aucun compte de service ne dispose de permissions plus larges que nécessaire. KENSAI peut automatiser cela grâce à une détection continue des dérives.