RBAC (contrôle d’accès basé sur les rôles)

RBAC (Role-Based Access Control) est le mécanisme par lequel Kubernetes décide qui (un utilisateur, un ServiceAccount, un groupe) a le droit de faire quoi (lister, créer, modifier, supprimer) sur quelles ressources. Rien n’est autorisé par défaut : une action non explicitement permise par une règle RBAC est refusée par le serveur API, quelle que soit la ressource visée.

Quatre objets, deux niveaux

Un Role (ou ClusterRole pour une portée qui dépasse un namespace) liste des permissions : quels verbes (get, list, create, delete) sur quels types de ressources. Un RoleBinding (ou ClusterRoleBinding) rattache ce rôle à une identité concrète. Les deux paires existent séparément parce qu’un même rôle (« lecture seule sur les Secrets », par exemple) se réutilise souvent pour plusieurs identités différentes, sans le redéfinir à chaque fois.

Ce que RBAC protège réellement

Un Secret Kubernetes natif n’est protégé par aucun chiffrement par défaut : son contenu est simplement encodé en base64, trivialement réversible. Ce qui empêche réellement quelqu’un de le lire, c’est RBAC : la permission get sur l’objet Secret. Restreindre cette permission au strict nécessaire, et vérifier qu’aucun rôle trop large ne traîne (un ClusterRole avec get sur tous les Secrets de tous les namespaces, distribué par habitude), est le contrôle qui compte réellement, pas la nature du chiffrement en base64.

L’erreur classique

Élargir une permission pour débloquer un incident, puis oublier de la retirer une fois l’incident clos. Un audit RBAC régulier (kubectl auth can-i --list sur chaque ServiceAccount qui compte) rattrape ce que personne ne remarque en fonctionnement normal : les permissions en trop ne cassent jamais rien, elles se contentent d’exister.