Kubernetes RBAC

cloud

Définition

Le RBAC (Role-Based Access Control) de Kubernetes est le système de contrôle d'accès qui régit qui peut effectuer quelles opérations sur quelles ressources Kubernetes. Il est activé par défaut depuis Kubernetes 1.6 et constitue le mécanisme central de contrôle des accès au cluster et aux namespaces. L'API Kubernetes RBAC définit quatre types de ressources. Les Roles définissent des permissions dans un namespace spécifique. Les ClusterRoles définissent des permissions au niveau du cluster entier (ou dans tous les namespaces). Les RoleBindings associent un Role à des subjects (Users, Groups, ServiceAccounts) dans un namespace. Les ClusterRoleBindings associent un ClusterRole à des subjects au niveau cluster. Les subjects dans Kubernetes RBAC sont de trois types : User (utilisateurs humains, authentifiés via des certificats, tokens OIDC, ou webhooks d'authentification), Group (groupes d'utilisateurs), et ServiceAccount (comptes de service pour les applications s'exécutant dans les pods, la principale surface d'attaque RBAC dans Kubernetes). Les erreurs RBAC les plus fréquentes incluent : l'utilisation de wildcards (verbs: ["*"] ou resources: ["*"]) donnant des droits excessifs, l'association de ClusterRoles privilegiés à des ServiceAccounts (cluster-admin pour une application applicative), le montage automatique du token de ServiceAccount dans tous les pods (automountServiceAccountToken: true par défaut avant Kubernetes 1.24), et la permission get/list/watch sur les Secrets au niveau cluster. Les outils d'audit RBAC Kubernetes incluent : kubectl auth can-i pour tester les permissions d'une identité, rbac-lookup pour visualiser les droits d'un sujet, rbac-police pour détecter les configurations dangereuses, rakkess pour afficher une matrice d'accès, et Kubescape pour un audit complet de la configuration RBAC selon le benchmark NSA/CISA Kubernetes Hardening Guide.

Principe du moindre privilège dans Kubernetes RBAC

Définissez des Roles granulaires par application : chaque Deployment a son propre ServiceAccount avec uniquement les permissions nécessaires (ex: lecture des ConfigMaps et Secrets de son namespace). Définissez automountServiceAccountToken: false dans les PodSpecs des applications n'utilisant pas l'API Kubernetes, et montez manuellement le token uniquement si nécessaire. Auditez mensuellement avec kubectl get rolebindings,clusterrolebindings -A -o yaml | grep -A2 "cluster-admin".

Chemins d'escalade de privilèges RBAC

De nombreuses permissions Kubernetes permettent une escalade vers cluster-admin : create Pods (peut monter des hostPath ou le socket Docker), create/bind RoleBindings (peut s'octroyer des permissions), create Secrets (peut lire les secrets existants), impersonate ServiceAccounts (peut agir en tant que n'importe quel SA), exec dans des pods (si un pod tourne avec des permissions élevées). L'outil rbac-police et Kubescape détectent ces chemins automatiquement.

Audit et monitoring du RBAC Kubernetes

Activez les Kubernetes Audit Logs et recherchez les patterns suspects : get/list Secrets (reconnaissance), create/update RoleBinding ou ClusterRoleBinding (persistance), exec dans des pods (possible post-exploitation), et create ServiceAccount suivi d'un ClusterRoleBinding (backdoor RBAC). Exportez les audit logs vers votre SIEM pour la corrélation et la détection d'anomalies.

Articles liés

Expert en cybersécurité offensive et intelligence artificielle. Pentest, audit et développement IA sur-mesure.

Services

Ressources

Projets & Outils

Contact

Nous contacter

Mentions légales Confidentialité Politique éditoriale Plan du site ⭐ Source préférée

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis