RBAC et identités

Pourquoi ce chapitre est le plus utile

Sur un cluster Kubernetes, la question n'est pas de savoir si une identité finira par dépasser le périmètre qui lui était destiné, mais quand. RBAC (Role-Based Access Control) est le mécanisme natif qui décide qui peut faire quoi sur quelles ressources — et c'est aussi, dans une bonne part des incidents de sécurité Kubernetes documentés publiquement, le maillon qui a cédé en premier : un ServiceAccount trop permissif, un ClusterRoleBinding cluster-admin oublié après un test, un secret lisible par un pod qui n'en avait strictement aucun besoin.

Comprendre RBAC en profondeur n'est pas un exercice académique. C'est ce qui permet de répondre, pour chaque pod en production, à une question simple et rarement posée avant qu'un incident ne la pose à votre place : que pourrait faire un attaquant qui prendrait le contrôle de ce conteneur précis ?

Les quatre objets du modèle RBAC

RBAC repose sur quatre types d'objets, combinés deux à deux.

Role définit un ensemble de permissions à l'intérieur d'un namespace : quels verbes (get, list, watch, create, update, patch, delete) sur quelles ressources (pods, secrets, deployments...).

ClusterRole définit le même type de permissions, mais sans portée namespace : soit parce que la ressource elle-même est cluster-wide par nature (les nodes, les persistentvolumes, les namespaces eux-mêmes), soit parce qu'on veut réutiliser une même définition de rôle dans plusieurs namespaces sans la dupliquer.

RoleBinding attache un Role — ou un ClusterRole — à une ou plusieurs identités, pour un namespace donné.

ClusterRoleBinding attache un ClusterRole à une ou plusieurs identités, pour l'ensemble du cluster.

Un ClusterRole peut aussi être construit par agrégation, via aggregationRule : plutôt que de lister ses règles directement, il sélectionne d'autres ClusterRoles par label et absorbe automatiquement leurs règles. C'est le mécanisme utilisé par les rôles intégrés view, edit et admin : une extension (CRD, opérateur) peut ajouter ses propres règles à ces rôles standards simplement en labellisant son propre ClusterRole additionnel, sans jamais modifier le rôle agrégé lui-même.

Un point qui prête souvent à confusion : un ClusterRole peut parfaitement être référencé par un RoleBinding namespacé. Cela permet de définir un rôle générique une seule fois (par exemple view-secrets) et de le distribuer namespace par namespace via des RoleBindings distincts, sans dupliquer la définition des règles. Dans ce cas, la portée effective est celle du binding, pas celle du rôle référencé.

Exemple minimal — un rôle qui autorise la lecture des pods dans le namespace billing :

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: billing
  name: pod-reader
rules:
  - apiGroups: ['']
    resources: [pods]
    verbs: [get, list, watch]

Et le binding qui l'attache à un ServiceAccount applicatif :

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: billing
subjects:
  - kind: ServiceAccount
    name: billing-api
    namespace: billing
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

roleRef.kind précise explicitement si le binding référence un Role ou un ClusterRole — il n'y a jamais d'ambiguïté sur ce point. La véritable source d'incident est ailleurs : un ClusterRoleBinding créé « pour tester rapidement », jamais supprimé, qui donne une permission cluster-wide à un compte censé rester local à un seul namespace.

Les identités : qui peut être sujet d'un binding

Trois types de sujets peuvent apparaître dans un binding.

• User — une identité humaine, authentifiée par certificat client, par OIDC, ou par tout webhook d'authentification externe. Kubernetes ne gère pas de base d'utilisateurs en interne : l'identité vient toujours d'un système externe au cluster.
• Group — un regroupement d'utilisateurs, généralement porté par le même mécanisme d'authentification (un claim OIDC groups, une organisation encodée dans un certificat).
• ServiceAccount — une identité native à Kubernetes, gérée directement par l'API, utilisée par les pods pour s'authentifier auprès de l'API server.

Le ServiceAccount est de loin l'identité la plus manipulée au quotidien, car chaque pod en possède une, qu'on le veuille ou non. Si aucun serviceAccountName n'est spécifié dans le manifeste, le pod utilise le ServiceAccount default du namespace — qui, par défaut, ne porte aucune permission RBAC propre, mais dont le tokentokenIAFragment de texte manipulé par un modèle de langage, généralement plus court qu'un mot — trois à quatre caractères en français. La tarification et la limite de contexte se comptent en tokens.Voir dans le glossaire est tout de même monté dans le pod sauf configuration contraire explicite.

Le montage automatique du token de ServiceAccount (automountServiceAccountToken) est activé par défaut. Un pod qui n'a besoin d'aucun accès à l'API Kubernetes expose quand même, par défaut, un token valide dans son système de fichiers (/var/run/secrets/kubernetes.io/serviceaccount/token). C'est une surface d'attaque gratuite : si le rôle métier du pod ne requiert aucun appel à l'API, désactivez ce montage.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: billing-api
  namespace: billing
automountServiceAccountToken: false

RBAC face aux autres modes d'autorisation

L'API server Kubernetes ne se limite pas à RBAC : le flag --authorization-mode accepte aussi ABAC, Webhook et Node. En pratique, RBAC s'est imposé comme mode par défaut sur la quasi-totalité des distributions gérées (EKS, GKE, AKS) pour une raison simple : ses règles sont déclaratives, versionnables dans un dépôt Git, et évaluables sans dépendance à un service externe.

ABAC (Attribute-Based Access Control) permet des règles plus expressives, fondées sur des attributs arbitraires de la requête, mais sa configuration repose sur un fichier statique chargé au démarrage de l'API server — impossible à modifier sans redémarrage, donc mal adapté à un cluster vivant. Le mode Webhook délègue la décision d'autorisation à un service HTTP externe, ce qui permet d'implémenter des politiques complexes (attributs métier, contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire temporel) au prix d'une dépendance réseau critique sur le chemin de chaque requête API. Le mode Node, enfin, est un mécanisme spécialisé qui limite les permissions du kubelet à ce qui concerne son propre node — il fonctionne toujours en complément de RBAC, jamais à sa place.

Ces modes ne s'excluent pas mutuellement : un cluster combine généralement Node et RBAC, et ajoute parfois un Webhook pour des décisions ponctuelles nécessitant un contexte externe. Mais pour la très large majorité des besoins applicatifs, RBAC seul couvre le terrain.

Schéma : du sujet à la ressource autorisée

Construire une politique en moindre privilège

Le principe de moindre privilège (least privilege) consiste à n'accorder à une identité que les permissions strictement nécessaires à sa fonction, pas plus. En pratique sur Kubernetes, cela se traduit par une méthode plutôt que par un réflexe :

1. Partir de zéro. Ne jamais copier un rôle existant « parce qu'il marche » — il hérite souvent de permissions accumulées sans jamais avoir été révisées.
2. Lister les verbes réellement utilisés. Un contrôleur qui surveille des pods a besoin de get, list, watch — rarement de delete ou create.
3. Restreindre resourceNames quand c'est possible. Un Role peut limiter l'accès à des objets nommés précisément plutôt qu'à toute une catégorie de ressources.
4. Séparer lecture et écriture. Deux rôles distincts (x-reader, x-writer) sont plus faciles à auditer qu'un rôle unique mélangeant les deux.
5. Namespacer par défaut. N'utiliser un ClusterRole ou un ClusterRoleBinding que lorsque la portée cluster-wide est réellement justifiée par le besoin métier.

kubectl auth can-i est le réflexe le plus rapide pour vérifier une permission sans relire tout le YAML : kubectl auth can-i delete secrets --as=system:serviceaccount:billing:billing-api -n billing. Utilisé avec --list, il affiche l'ensemble des permissions effectives d'une identité — indispensable en revue d'un manifeste RBAC avant fusion.

Pièges fréquents

Un contrôleur applicatif embarque un rôle hérité d'un tutoriel d'installation, avec resources: ['*'] et verbs: ['*'] dans son propre namespace. Six mois plus tard, une vulnérabilité de désérialisation dans l'application permet l'exécution de commandes dans le pod. L'attaquant utilise le token du ServiceAccount monté automatiquement pour lister tous les secrets du namespace — dont les identifiants de la base de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire de production. Le rôle initial n'avait jamais été revu depuis l'installation.

Auditer les permissions effectives

Écrire un Role correct au moment de sa création ne suffit pas : les permissions dérivent avec le temps, par empilement de RoleBindings successifs et par ajout de règles « temporaires » qui ne le restent jamais. Un audit RBAC régulier doit répondre à trois questions :

• Qui a accès à quoi, effectivement ? — pas seulement ce que dit un manifeste isolé, mais la résultante de tous les bindings actifs pour une identité donnée.
• Quelles identités ont des droits cluster-wide ? — lister tous les ClusterRoleBindings et vérifier que chaque sujet a une raison documentée d'y figurer.
• Quels tokens de ServiceAccount sont exposés inutilement ? — repérer les pods dont le token est monté sans qu'aucun appel API ne soit jamais effectué.

L'audit log de l'API server (--audit-log-path, piloté par une AuditPolicy adaptée) est la source de vérité sur ce qui s'est réellement passé, par opposition à ce que la configuration autorise en théorie. Une politique d'audit minimale doit au moins tracer les événements de niveau RequestResponse sur les verbes sensibles (create, update, patch, delete) touchant les secrets, les rolebindings et les clusterrolebindings — ce sont les ressources qui, modifiées, changent directement la surface de permissions du cluster.

Des outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire tiers comme rbac-tool ou kubectl-who-can automatisent une partie de cette analyse en résolvant les chaînes sujet → binding → rôle → règles, ce qui devient vite fastidieux à faire manuellement dès qu'un cluster dépasse quelques dizaines de bindings.

Checklist avant mise en production

• Chaque application dispose de son propre ServiceAccount, nommé explicitement dans son manifeste de déploiement.
• automountServiceAccountToken: false est appliqué à tout pod n'appelant jamais l'API Kubernetes.
• Aucun Role ou ClusterRole applicatif ne contient de wildcard sur resources ou verbs.
• Les ClusterRoleBindings sont recensés et chacun a un propriétaire identifié.
• cluster-admin n'est lié à aucun ServiceAccount.
• L'audit logging est actif sur les verbes d'écriture touchant secrets et les objets RBAC eux-mêmes.
• Une revue RBAC est planifiée à intervalle régulier, pas seulement au moment du déploiement initial.

RBAC ne protège que ce qu'il décrit correctement. Un cluster où les rôles sont précis mais jamais révisés dérivedériveIADégradation progressive des performances d'un modèle après son déploiement, causée par l'évolution des comportements ou du contexte. Elle impose surveillance et réentraînement.Voir dans le glossaire aussi sûrement qu'un cluster où ils sont larges dès le départ — simplement plus lentement, et de façon moins visible.