ClusterRole Kubernetes

cloud

Définition

Un ClusterRole dans Kubernetes est un ensemble de règles de permission (rules) qui définissent les opérations autorisées sur des ressources Kubernetes au niveau du cluster entier. Contrairement aux Roles qui sont namespacés (scopés à un namespace spécifique), les ClusterRoles s'appliquent à toutes les ressources cluster-wide, incluant les ressources non-namespacées (nœuds, PersistentVolumes) et peuvent accorder des permissions dans tous les namespaces. Un ClusterRole se compose de rules, chacune spécifiant : les apiGroups (ex: "", "apps", "rbac.authorization.k8s.io"), les resources (ex: "pods", "secrets", "nodes"), et les verbs (ex: "get", "list", "watch", "create", "update", "patch", "delete"). Des resourceNames peuvent restreindre la règle à des ressources spécifiques par nom. Plusieurs verbs particuliers sont critiques : "escalate" (permet d'escalader les permissions d'un role), "bind" (permet de créer des RoleBindings), "impersonate" (permet d'agir au nom d'un autre utilisateur). Les ClusterRoles intégrés dans Kubernetes incluent cluster-admin (accès total à tout), admin, edit, et view. Le ClusterRole cluster-admin est l'équivalent du compte root Kubernetes : il doit être assigné à un minimum d'utilisateurs et de ServiceAccounts, uniquement avec des ClusterRoleBindings portant sur des cas d'usage spécifiques et documentés. Les risques RBAC associés aux ClusterRoles incluent : le clusterrolebinding vers cluster-admin (pattern de persistance dans la Kubernetes Threat Matrix), les règles avec wildcard (*) sur les ressources ou les verbs (accordent des permissions excessives), les règles permettant de créer des Pods avec des volumes hostPath ou privileged: true (équivalent à un accès root sur le nœud), et les permissions sur les Secrets dans tous les namespaces. L'audit régulier des ClusterRoles et de leurs bindings est essentiel. Des outils comme rbac-lookup, rakkess, et kubectl-who-can simplifient cet audit en permettant d'identifier rapidement qui peut effectuer quelle opération sur quelles ressources.

ClusterRole vs Role : quand utiliser lequel

Préférez les Roles namespacés aux ClusterRoles chaque fois que possible, même si vous créez des RoleBindings dans plusieurs namespaces. Un ClusterRole peut être lié via un RoleBinding (pas ClusterRoleBinding) pour accorder des permissions uniquement dans le namespace du RoleBinding. La règle est simple : utilisez ClusterRole uniquement si vous avez besoin de permissions sur des ressources non-namespacées (nœuds, PVs, CRDs cluster-wide) ou si vous avez besoin de permissions identiques dans TOUS les namespaces sans exception.

Audit des règles dangereuses

Ces règles ClusterRole sont particulièrement dangereuses : verbs [create, patch] sur resources [pods/exec] (permet d'exécuter des commandes dans tout pod du cluster), verbs [create] sur resources [clusterrolebindings] (permet d'escalader ses propres permissions), verbs [get, list] sur resources [secrets] (permet de récupérer tous les secrets du cluster), verbs [*] sur resources [*] (cluster-admin implicite). Détectez ces patterns avec : kubectl get clusterroles -o json | jq '.items[] | select(.rules[].verbs[] == "*")'.

Kyverno pour prévenir les ClusterRoles dangereux

Utilisez Kyverno pour empêcher la création de ClusterRoles ou Roles avec des règles dangereuses : créez une ClusterPolicy Kyverno avec une règle validate qui inspecte les ClusterRoles et rejette ceux contenant des wildcards sur les verbs ou des permissions sur les secrets cluster-wide. Cette politique s'applique même aux administrateurs (via les ClusterPolicies generate et mutate), ajoutant un filet de sécurité au-delà de RBAC pour prévenir les erreurs de configuration.

Articles liés

Expert en cybersécurité offensive et intelligence artificielle. Pentest, audit et développement IA sur-mesure.

Services

Ressources

Projets & Outils

Contact

Nous contacter

Mentions légales Confidentialité Politique éditoriale Plan du site ⭐ Source préférée

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis