Objets RBAC : Roles, ClusterRoles, RoleBindings, ClusterRoleBindings

Les briques élémentaires du contrôle d'accès RBAC

Le système RBAC (Role-Based Access Control) de Kubernetes repose sur quatre types d'objets API fondamentaux qui fonctionnent en tandem pour définir et attribuer des permissions. Comprendre le rôle et la structure de chacun de ces objets est essentiel pour implémenter correctement le contrôle d'accès dans votre cluster.

Ces quatre objets sont :

• Role : Définit un ensemble de permissions au sein d'un Namespace spécifique.
• ClusterRole : Définit un ensemble de permissions à l'échelle du cluster, ou pour des ressources qui ne sont pas liées à un Namespace.
• RoleBinding : Lie un Role à un ou plusieurs sujets (Utilisateur, Groupe, ServiceAccount) dans un Namespace spécifique, leur accordant ainsi les permissions de ce Role dans ce Namespace.
• ClusterRoleBinding : Lie un ClusterRole à un ou plusieurs sujets, leur accordant les permissions de ce ClusterRole à travers tout le cluster.

Examinons chacun de ces objets plus en détail.

Role : Permissions dans un Namespace

Un Role est un objet API qui contient des règles représentant un ensemble de permissions. Les permissions définies dans un Role sont toujours limitées à un Namespace unique. Vous devez spécifier le Namespace dans les métadonnées du Role.

La partie la plus importante d'un Role est sa section rules. Chaque élément de cette liste définit :

• apiGroups : Une liste des groupes d'API auxquels appartiennent les ressources ciblées. Le groupe core (pour les objets comme Pods, Services, ConfigMaps, Secrets) est représenté par une chaîne vide (""). D'autres groupes courants incluent apps, batch, networking.k8s.io, etc. Mettre ["*"] cible tous les groupes d'API.
• resources : Une liste des types de ressources auxquels les permissions s'appliquent (ex: pods, deployments, configmaps, services/status pour la sous-ressource status d'un service). Mettre ["*"] cible toutes les ressources du ou des groupes d'API spécifiés.
• verbs : Une liste des actions autorisées sur ces ressources. Les verbes courants sont get, list, watch, create, update, patch, delete, deletecollection. Le verbe * accorde toutes les permissions.

Exemple : Un Role nommé `pod-reader` dans le Namespace `dev` qui permet de lister et lire (`get`, `list`, `watch`) les Pods.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-reader
rules:
- apiGroups: [""] # Groupe d'API core
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

ClusterRole : Permissions à l'échelle du Cluster

Un ClusterRole est très similaire à un Role dans sa structure (il contient aussi une section rules avec apiGroups, resources, verbs), mais il n'est pas lié à un Namespace. Les permissions définies dans un ClusterRole peuvent s'appliquer :

• Aux ressources non-namespacées (qui n'existent pas à l'intérieur d'un Namespace), comme les Nodes, les Namespaces eux-mêmes, les PersistentVolumes, les ClusterRoles, etc.
• Aux ressources namespacées, mais appliquées à travers tous les Namespaces du cluster.
• Aux URLs non liées à des ressources (ex: /healthz, /metrics). Ceci est défini via une section nonResourceURLs dans les règles.

Les ClusterRoles sont souvent utilisés pour définir des rôles administratifs larges (comme l'administrateur de cluster complet) ou des permissions nécessaires aux composants du control plane ou aux contrôleurs qui opèrent sur l'ensemble du cluster.

Exemple : Un ClusterRole nommé `secret-reader` qui permet de lire (`get`, `watch`, `list`) les Secrets dans n'importe quel Namespace.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # Pas de namespace ici !
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

Exemple : Un ClusterRole permettant de lire les Nodes.

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

Kubernetes est livré avec plusieurs ClusterRoles par défaut, comme `cluster-admin` (accès complet), `admin` (accès admin dans un namespace via RoleBinding), `edit` (accès en modification dans un namespace), `view` (accès en lecture seule dans un namespace).

RoleBinding : Lier un Role à un Sujet dans un Namespace

Un RoleBinding est l'objet qui accorde les permissions définies dans un Role à un ou plusieurs sujets (utilisateurs, groupes ou ServiceAccounts) au sein d'un Namespace spécifique. Il crée le lien entre 'qui' (le sujet) et 'ce qui est permis dans ce namespace' (le Role).

Un RoleBinding contient trois informations clés :

• subjects : Une liste des identités auxquelles les permissions sont accordées. Chaque sujet est défini par :
  • kind : Le type d'identité (User, Group, ou ServiceAccount).
  • name : Le nom de l'utilisateur, du groupe, ou du ServiceAccount.
  • apiGroup : Généralement rbac.authorization.k8s.io pour User et Group. Peut être omis pour ServiceAccount.
  • namespace (uniquement pour kind: ServiceAccount) : Le Namespace dans lequel se trouve le ServiceAccount.
• roleRef : Une référence au Role dont les permissions sont accordées. Il faut spécifier :
  • kind : Doit être Role.
  • name : Le nom du Role à lier (qui doit exister dans le même Namespace que le RoleBinding).
  • apiGroup : Doit être rbac.authorization.k8s.io.
• metadata.namespace : Le Namespace dans lequel ce binding s'applique (qui doit être le même que celui du Role référencé).

Exemple : Lier le Role `pod-reader` (défini précédemment dans le namespace `dev`) à l'utilisateur `jane` et au ServiceAccount `robot` (dans le namespace `prod`). Attention : ce binding est dans le namespace `dev`, il donne donc accès aux pods de `dev`.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-in-dev
  namespace: dev # S'applique au namespace 'dev'
subjects:
- kind: User
  name: jane # Nom de l'utilisateur
  apiGroup: rbac.authorization.k8s.io
- kind: ServiceAccount
  name: robot # Nom du ServiceAccount
  namespace: prod # Namespace où se trouve le SA 'robot'
roleRef:
  kind: Role # Fait référence à un Role
  name: pod-reader # Nom du Role dans le namespace 'dev'
  apiGroup: rbac.authorization.k8s.io

Il est aussi possible pour un RoleBinding de référencer un ClusterRole. Dans ce cas, les permissions définies dans le ClusterRole sont accordées au sujet, mais uniquement pour les ressources à l'intérieur du Namespace du RoleBinding. C'est une façon courante d'utiliser les ClusterRoles par défaut `admin`, `edit`, `view`.

ClusterRoleBinding : Lier un ClusterRole à un Sujet au niveau Cluster

Un ClusterRoleBinding accorde les permissions définies dans un ClusterRole à un ou plusieurs sujets à travers l'ensemble du cluster. Il n'est pas lié à un Namespace.

Sa structure est très similaire à celle d'un RoleBinding, mais :

• Il n'a pas de champ metadata.namespace.
• Son champ roleRef doit obligatoirement référencer un ClusterRole (kind: ClusterRole).

Les ClusterRoleBindings sont utilisés pour accorder des permissions à l'échelle du cluster, comme l'administration globale, l'accès aux ressources non-namespacées, ou les permissions nécessaires aux composants du control plane.

Exemple : Accorder au groupe `system:monitoring` les permissions du ClusterRole `monitoring-reader` (qui permettrait par exemple de lire les métriques de tous les noeuds).

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-monitoring-global
subjects:
- kind: Group
  name: system:monitoring # Nom du groupe
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole # Fait référence à un ClusterRole
  name: monitoring-reader # Nom du ClusterRole
  apiGroup: rbac.authorization.k8s.io

En combinant judicieusement ces quatre types d'objets, vous pouvez construire un système d'autorisations RBAC précis et sécurisé, en définissant clairement les permissions (Roles, ClusterRoles) et en les appliquant de manière ciblée aux identités qui en ont besoin (RoleBindings, ClusterRoleBindings), tout en respectant le principe fondamental de moindre privilège.