RBAC : Role-Based Access Control
Sécurité
RBAC : Role-Based Access Control. « Contrôle d'accès fondé sur les rôles », par analogie avec le trousseau remis selon le poste occupé plutôt qu'au nom de la personne.
Principe : Les permissions sont attachées à des rôles, et les identités reçoivent des rôles. Quand quelqu'un change de poste, on change son rôle au lieu de refaire la liste de ses droits un par un.
Séparation des tâches : Bien découpés, les rôles empêchent qu'une même identité puisse à la fois modifier un pipeline, changer une politique et promouvoir en production. La vertu humaine étant une ressource non renouvelable, on préfère la remplacer par un découpage de rôles.
Explosion des rôles : Le travers classique consiste à créer un rôle par exception, jusqu'à obtenir plus de rôles que d'utilisateurs. Des revues régulières et des rôles construits sur les besoins réels limitent la dérive.
En pratique : Kubernetes, les annuaires et les plateformes cloud l'implémentent nativement : un rôle définit des verbes sur des ressources, une liaison l'accorde à un compte ou à un groupe.
Ce qui arrive si on s'en passe
Sans contrôle d'accès par rôles, les droits s'accordent au cas par cas et s'accumulent : chaque compte garde les permissions de tous ses postes successifs, et plus personne ne sait dire qui peut faire quoi. Un compte compromis ouvre alors bien plus que ce dont son titulaire avait besoin, et un attaquant peut enchaîner modification de code, changement de politique et déploiement en production avec une seule identité. Les revues d'accès deviennent impossibles faute de structure à relire, et le départ d'un collaborateur laisse des droits orphelins. Des rôles définis, attribués selon le moindre privilège et revus périodiquement bornent ce que chaque identité peut atteindre.
Explication de la marmotte
Dans un grand hôtel, on ne décide pas une par une quelles portes chaque employé peut ouvrir. On dit plutôt : les femmes et valets de chambre ont accès à tel étage, les cuisiniers à la cuisine, les comptables aux bureaux. Chaque personne reçoit un badge selon son métier, et ce métier donne automatiquement les bons accès. Si quelqu'un change de poste, on change son métier sur le badge, et tous ses droits suivent d'un coup. En informatique, c'est la même idée : on regroupe les autorisations par fonction, puis on attribue les fonctions aux personnes et aux programmes.
Où ce terme est utilisé
- DAC, MAC, RBAC, ABAC ou ReBAC : quel modèle choisir (14 occurrences)
- Réduire RBAC Kubernetes et bloquer les pods dangereux (8 occurrences)
- Accès juste-à-temps et privilèges temporaires (6 occurrences)
- Jeton de compte de service Kubernetes monté par défaut (6 occurrences)
- ReBAC Zanzibar pour les autorisations relationnelles fines (5 occurrences)
- Auditer et durcir un cluster Kubernetes avec kube-bench (4 occurrences)
- Mettre en œuvre les revues d’accès IGA et la SoD (4 occurrences)
- Auditer l'héritage des permissions et le droit effectif (3 occurrences)
- Déployer des NetworkPolicy Kubernetes pas à pas (3 occurrences)
- Isolation des conteneurs Docker : namespaces, cgroups et évasions (3 occurrences)