RoleBinding Kubernetes

Définition

Un RoleBinding dans Kubernetes est une ressource qui lie (bind) un Role ou un ClusterRole à un ou plusieurs sujets (utilisateurs, groupes, ou ServiceAccounts) dans un namespace spécifique. C'est le mécanisme par lequel les permissions définies dans un Role ou ClusterRole sont accordées à une identité Kubernetes. Sans RoleBinding (ou ClusterRoleBinding), un Role n'a aucun effet : les permissions ne sont jamais accordées automatiquement. Il existe deux types de binding. Le RoleBinding est namespacé : il lie des permissions (d'un Role ou ClusterRole) à des sujets dans un namespace spécifique. Un ClusterRoleBinding lie des permissions cluster-wide (d'un ClusterRole uniquement) à des sujets sans restriction de namespace. Un RoleBinding peut référencer un ClusterRole mais restreint son application au namespace du RoleBinding. Cette combinaison est utile pour définir des permissions communes dans un ClusterRole réutilisable (ex: un ClusterRole "dev-permissions" avec les permissions standard d'un développeur) et les appliquer dans des namespaces spécifiques via des RoleBindings, sans accorder ces permissions à l'échelle du cluster. Les risques de sécurité liés aux RoleBindings incluent : les ClusterRoleBindings vers cluster-admin (le pattern de persistance le plus commun dans les attaques Kubernetes - l'attaquant crée un ClusterRoleBinding liant son compte compromis à cluster-admin), les RoleBindings accordant des permissions excessives aux ServiceAccounts applicatifs, et la prolifération de RoleBindings obsolètes (liés à des comptes supprimés ou des applications désinstallées). L'audit des RoleBindings est une activité de sécurité régulière : kubectl get rolebindings,clusterrolebindings --all-namespaces -o wide permet d'obtenir une vue globale de toutes les liaisons de permissions. Des outils comme rbac-lookup, kubectl-who-can, et rakkess simplifient l'audit en permettant des requêtes inversées : "qui peut créer des pods dans le namespace production ?".