Autorisation avec RBAC (Role-Based Access Control)
Découvrez le fonctionnement de RBAC (Role-Based Access Control) dans Kubernetes pour définir précisément qui peut faire quoi sur les ressources de votre cluster.
Après l'identité, les permissions : l'autorisation
Une fois qu'une requête vers l'API Server Kubernetes a été authentifiée avec succès, établissant l'identité de l'appelant (un Utilisateur ou un ServiceAccount), l'étape suivante est l'autorisation. Cette phase cruciale détermine si l'identité authentifiée a effectivement la permission d'effectuer l'action demandée (par exemple, lire, créer, supprimer) sur la ressource spécifique ciblée (par exemple, un Pod, un Secret, un Node).
Pour gérer cette étape de manière fine et sécurisée, Kubernetes s'appuie principalement sur un mécanisme appelé RBAC (Role-Based Access Control), ou Contrôle d'Accès Basé sur les Rôles. RBAC est devenu le standard de facto pour l'autorisation dans Kubernetes, remplaçant des méthodes plus anciennes et moins granulaires. Son objectif est de permettre aux administrateurs de définir des ensembles de permissions (des rôles) et de les attribuer aux identités (sujets) de manière organisée.
L'importance du RBAC réside dans sa capacité à implémenter le principe de moindre privilège. Au lieu d'accorder des permissions larges et potentiellement dangereuses, RBAC permet de définir précisément quelles actions sont autorisées pour chaque utilisateur ou processus, réduisant ainsi considérablement la surface d'attaque et l'impact potentiel d'une compromission de credentials ou d'une erreur humaine.
La philosophie RBAC : Définir les permissions, puis les assigner
Le modèle RBAC repose sur une séparation claire entre la définition des permissions et leur attribution aux sujets (utilisateurs, groupes, ou ServiceAccounts). Cette séparation rend la gestion des droits plus claire et plus facile à maintenir.
Au coeur de RBAC se trouvent les objets qui définissent les permissions : les Roles et les ClusterRoles. Un Role ou un ClusterRole contient un ensemble de règles (rules). Chaque règle spécifie un ensemble de verbes (les actions autorisées comme `get`, `list`, `watch`, `create`, `update`, `patch`, `delete`) qui peuvent être appliqués à un ensemble de ressources (comme `pods`, `services`, `secrets`) au sein de groupes d'API spécifiques. La différence principale est qu'un Role est limité à un Namespace spécifique, tandis qu'un ClusterRole contient des permissions qui s'appliquent à l'échelle de tout le cluster (y compris pour les ressources non-namespacées comme les Nodes ou les Namespaces eux-mêmes).
Une fois ces rôles définis, ils sont attribués aux sujets via des objets de liaison : les RoleBindings et les ClusterRoleBindings. Un RoleBinding accorde les permissions définies dans un Role à un sujet (ou plusieurs) au sein d'un Namespace spécifique. Un ClusterRoleBinding accorde les permissions définies dans un ClusterRole à un sujet (ou plusieurs) à travers tout le cluster.
Activation et fonctionnement par défaut
Dans la plupart des installations Kubernetes modernes, RBAC est le mode d'autorisation activé par défaut. Cela est généralement configuré via les options de démarrage de l'API Server, notamment le flag --authorization-mode qui inclut `RBAC` (souvent avec `Node`, soit --authorization-mode=Node,RBAC). D'autres modes comme ABAC (Attribute-Based Access Control) ou Webhook existent mais sont moins courants que RBAC.
Lorsque le mode d'autorisation RBAC est activé, le comportement par défaut est un refus implicite (default deny). Cela signifie que si une requête authentifiée est reçue, et qu'aucun RoleBinding ou ClusterRoleBinding n'accorde explicitement la permission requise au sujet identifié, la requête sera rejetée avec une erreur d'autorisation (souvent un code HTTP 403 Forbidden).
Il est donc essentiel de bien comprendre comment créer et lier ces différents objets RBAC pour accorder les permissions nécessaires aux utilisateurs et aux ServiceAccounts. Les sections suivantes détailleront la structure et l'utilisation des Roles, ClusterRoles, RoleBindings et ClusterRoleBindings.