~10 minutes
Cet article fait partie de la série OWASP Top 10 Kubernetes 2026. Retrouvez le tableau de bord complet des dix risques et la matrice STRIDE sur la page d’entrée de la série.
K08 couvre le RBAC. J’en ai déjà parlé dans K01 pour la partie authentification ; ici, on parle de l’autorisation.
Le RBAC Kubernetes est un système expressif. C’est précisément le problème : on peut très facilement exprimer des règles qui semblent raisonnables et qui ouvrent en réalité un boulevard. get et list sur les secrets d’un namespace applicatif, c’est une escalade de privilèges immédiate pour qui a compromis un pod. Un ClusterRoleBinding sur cluster-admin pour “dépanner un ops/sre un vendredi soir”, c’est souvent encore là le lundi suivant, puis le mois d’après.
Note de votre PandaRedacteur préféré : La règle du ‘on ne touche pas a la PROD un VENDREDI’ devrait toujours être respectée pour quiconque :
- Dèvs : On ne PUSH/MERGE pas sur PROD!
- CD : en pause de déploye sur PROD !
- OPS/SRE : qui ne touche a rien, et ne font que regarder la PROD Bien sur en dehors des patchs de sécurité ou de PROD Critiques !
La règle du moindre privilège existe dans Kubernetes, elle s’appelle “n’accorder que ce dont le compte de service a besoin, sur les ressources exactes dont il a besoin, dans le namespace où il en a besoin”. En pratique, elle est rarement appliquée dès le départ parce que trouver les bons droits demande du temps et que cluster-admin “fonctionne toujours”.
Vecteurs d’attaque
Le classique silencieux
Le verbe * sur les ressources * dans un ClusterRole donne accès à tout. C’est l’équivalent RBAC de chmod 777 -R /. On le voit dans des ClusterRoles créés pour des opérateurs tiers dont le chart Helm propose des valeurs par défaut permissives, dans des roles de CI/CD qui ont besoin d’un accès “admin” pour déployer, dans des rôles d’administration créés pour “avoir la main en cas d’urgence” (kof….kof….).
La question à poser sur chaque ClusterRole avec wildcard : quel est le scénario d’exploitation si le compte de service qui porte ce rôle est compromis ? La réponse est presque toujours “accès total au cluster”.
kubectl get clusterroles -o json | jq '.items[] | select(.rules[].verbs[] == "*") | .metadata.name'
Cette commande retourne souvent plus de résultats qu’on ne l’attend sur un cluster en production. Certains sont légitimes (kube-system, opérateurs système), les autres….
Note du PandaRedacteur : en tout cas un bon inventaire aidera toujours….
Le get/list sur les secrets
C’est le vecteur que j’explique le plus souvent lors des sensibilisations : un compte de service avec get et list sur secrets dans un namespace peut lire tous les secrets de ce namespace. Sans avoir besoin d’autres droits. Sans que ça paraisse particulièrement dangereux dans un audit simple.
Un pipeline CI/CD qui a besoin de lire un secret de déploiement reçoit souvent get + list sur l’ensemble des secrets du namespace, parce que c’est plus simple à configurer. Résultat : si le pipeline est compromis, l’attaquant dispose de tous les secrets du namespace de production.
La facilité qui devient un risque
On le vois très souvent : des ClusterRoleBindings sur cluster-admin pour des utilisateurs humains, des comptes de CI/CD, parfois des service accounts de monitoring. Ils sont créés pour résoudre un problème ponctuel, jamais supprimés…
Un ClusterRoleBinding sur cluster-admin pour un compte de CI/CD signifie que toute compromission du système CI donne un accès total au cluster de production. Sans restriction. Sans audit trail si l’audit log n’est pas ou mal activé.
La blague a Denisot : un
ClusterRoleBindingsur un compte de service dansdefaultqui a hérité decluster-adminparce que Michel a copié-collé un exemple de la documentation officielle d’un opérateur tiers sans lire les droits demandés.
Mitigations 2026
Audit régulier avec rbac-police et kubectl-who-can
L’audit RBAC ne se fait pas à la main sur un cluster actif. Deux outils permettent de l’automatiser :
rbac-police: évalue les configurations RBAC contre un ensemble de règles de sécurité et produit un rapport lisible. Il détecte notamment les paths d’escalade de privilèges, les accès dangereux aux secrets et les wildcards.kubectl-who-can: répond à la question “qui peut faire quoi sur quelle ressource” dans un format directement exploitable pour l’audit.
L’audit doit couvrir explicitement : les bindings cluster-admin, les verbes wildcard, les droits get/list sur secrets, et les service accounts dans des namespaces applicatifs avec des droits sur des ressources système.
Scoper les rôles au namespace, pas au cluster
La règle de base : un Role namespaced est préférable à un ClusterRole dès que les besoins sont bornés à un namespace. Un ClusterRole est justifié pour les opérateurs qui doivent gérer des ressources cluster-wide ; il ne l’est pas pour un service applicatif qui lit ses propres ConfigMaps.
Pour les comptes de service des applications :
- lister les opérations réellement effectuées sur l’API Kubernetes,
- créer un Role minimal avec ces verbes sur ces ressources spécifiques,
- et vérifier que le rôle n’est pas plus large que nécessaire.
Note du PandaRedacteur : Moindre Privilège powa !
Supprimer les bindings cluster-admin non justifiés
La suppression des bindings cluster-admin non justifiés est la mitigation à impact le plus direct. Sur les clusters cloud managés, les bindings créés en plus du compte d’administration natif doivent tous avoir une justification documentée et une revue périodique.
Pour les pipelines CI/CD : les droits nécessaires au déploiement sont typiquement create, update, patch sur deployments, services, configmaps dans un namespace donné. Très Rarement plus.
ValidatingAdmissionPolicy pour bloquer les wildcards à la création
Kubernetes 1.28 a stabilisé ValidatingAdmissionPolicy avec CEL. On peut exprimer des règles qui bloquent la création de ClusterRoleBindings sur cluster-admin depuis des namespaces non-système, ou alertent sur des Roles avec wildcard créés hors d’un namespace d’opérateur approuvé.
Note du PandaRedateur : C’est un garde-fou à la création ; cela ne remplace pas vos audits des configurations
DevSecOps : intégrer K08 dans la chaîne CI/CD
Ce contenu représente de nombreuses heures de travail, d'expérience etc... J'ai remarqué que mon contenu était repris par certaines sociétés/personnes et j'ai donc décidé de donner du contenu minimal sur ce blog. C'est pourquoi je vous invite a me contacter sur LinkedIn en mentionnant cet article pour plus d'informations.
- ✓ get + list sur les secrets = lecture de tous les secrets du namespace : ce droit doit être réservé et audité, pas distribué pour "simplifier la config".
- ✓ Supprimer les bindings cluster-admin non justifiés : chaque binding doit avoir un propriétaire, une justification et une date de revue.
- ✓ Wildcards sur les verbes = signal d'alarme : les auditer systématiquement, même pour les opérateurs système.
- ✓ rbac-police et kubectl-who-can automatisent l'audit : les intégrer dans le pipeline avant de passer à la correction manuelle.
- ✓ Role namespaced > ClusterRole pour tout ce qui est borné à un namespace ; le ClusterRole se justifie, pas se distribue.