RBAC

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

Qu'est-ce que le RBAC ?

Le RBAC (Role-Based Access Control) est le mécanisme d'autorisation de Kubernetes : après l'authentification (qui es-tu ?), le RBAC décide ce que tu as le droit de faire.

Il répond à une question simple :

Qui peut effectuer quelle action sur quelles ressources ?

Le RBAC s'appuie sur l'API rbac.authorization.k8s.io et est actif par défaut dans les clusters modernes.

Les concepts de base

• Sujet (le qui) : User, Group ou ServiceAccount.
• Verbe (le quoi faire) : get, list, watch, create, update, patch, delete, deletecollection…
• Ressource (le sur quoi) : pods, services, deployments, configmaps… (y compris les sous-ressources, ex. pods/log).
• Règle (rule) : la combinaison d'un apiGroup, de resources et de verbs.
• Rôle : un ensemble de règles (Role ou ClusterRole).
• Binding : l'association d'un rôle à un sujet (RoleBinding ou ClusterRoleBinding).

Autrement dit : le rôle dit ce qui est permis, le binding dit à qui.

Les sujets

• User : un être humain. Kubernetes ne stocke pas les utilisateurs : ils viennent d'un fournisseur d'identité externe (certificats, OIDC…).
• Group : un ensemble d'utilisateurs (souvent géré par ce même fournisseur).
• ServiceAccount : une identité interne au cluster, utilisée par les Pods (et les processus) pour parler à l'API. C'est le sujet le plus fréquent dans le RBAC applicatif.

Role ou ClusterRole ?

• Role : namespacé — ses permissions ne s'appliquent que dans un namespace.
• ClusterRole : de portée cluster — nécessaire pour les ressources non namespacées (nodes, persistentvolumes, namespaces…), ou pour réutiliser un même jeu de permissions dans plusieurs namespaces.

RoleBinding ou ClusterRoleBinding ?

• RoleBinding : accorde les permissions dans un namespace (il peut référencer un Role ou un ClusterRole).
• ClusterRoleBinding : accorde les permissions dans tout le cluster (il ne peut référencer qu'un ClusterRole).

⚠️ Un ClusterRoleBinding ne peut pas référencer un Role : c'est une erreur courante.

Les combinaisons possibles :

• Role + RoleBinding → des permissions dans un seul namespace.
• ClusterRole + RoleBinding → réutiliser un ClusterRole dans un namespace précis (sans donner les droits partout).
• ClusterRole + ClusterRoleBinding → des permissions sur tout le cluster.

Un Role et un RoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
  - apiGroups: [""]            # "" = groupe de l'API core
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
  - kind: ServiceAccount
    name: app-sa
    namespace: default
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Un ClusterRole et un ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-reader
rules:
  - apiGroups: [""]
    resources: ["nodes"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-nodes
subjects:
  - kind: Group
    name: monitoring
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: node-reader
  apiGroup: rbac.authorization.k8s.io

Les bonnes pratiques

• Moindre privilège : n'accorder que les permissions strictement nécessaires — ni plus, ni plus large.
• Préférer les Role (namespacés) aux ClusterRole quand c'est possible.
• Éviter les jokers (*) dans resources et verbs.
• Utiliser un ServiceAccount dédié par application, plutôt que le default.
• Ne pas monter automatiquement le jeton du ServiceAccount si inutile (automountServiceAccountToken: false).
• Auditer régulièrement qui peut faire quoi (kubectl auth can-i).

Vérifier et tester

• Ce que je peux faire : kubectl auth can-i --list
• Une action précise : kubectl auth can-i get pods
• Pour un autre sujet : kubectl auth can-i get pods --as=system:serviceaccount:default:app-sa
• Dans un namespace précis : kubectl auth can-i create deployments -n prod
• Inspecter un rôle : kubectl describe role pod-reader
• Lister les rôles et bindings d'un namespace : kubectl get roles,rolebindings -n default
• Lister les objets cluster : kubectl get clusterroles / kubectl get clusterrolebindings