## Introduction Le contrôle d'accès basé sur les rôles (RBAC, Role-Based Access Control) de Kubernetes est une pierre angulaire de la sécurité du cluster. Parmi ses ressources, le ClusterRoleBinding est particulièrement puissant car il accorde des permissions sur tous les espaces de noms ou sur des ressources de portée cluster. Un ClusterRoleBinding mal configuré peut exposer des données sensibles, permettre une escalade de privilèges ou perturber l'accès des applications. Cet article fournit une liste de contrôle des opérations de production avec des exemples pratiques. Ce n'est pas une introduction conceptuelle au RBAC ; il suppose que vous comprenez déjà les bases de ClusterRole, RoleBinding et ServiceAccount, et se concentre sur les tâches quotidiennes, les commandes et les vérifications nécessaires pour exploiter les ClusterRoleBindings en toute sécurité dans un environnement réel. En suivant cette liste de contrôle, vous réduirez le risque d'accès non intentionnel, pourrez vérifier et auditer efficacement les liaisons et récupérer rapidement des erreurs. ## Inventaire de la version et de l'environnement Avant d'effectuer toute modification, vous devez connaître votre environnement Kubernetes. Le RBAC est stable dans les versions récentes de Kubernetes, mais il existe des différences subtiles, notamment avec les ClusterRoles agrégés et la découverte d'API. Documentez les éléments suivants : - Version du serveur Kubernetes : exécutez kubectl version --short . Sortie attendue : Client Version: v1.27.3 et Server Version: v1.27.3 . Si la version du serveur est inférieure à 1.6, le RBAC n'est pas activé par défaut ; la plupart des clusters modernes l'ont. - Mode d'autorisation du serveur API : vérifiez le manifeste kube-apiserver ou les arguments du processus. Recherchez --authorization-mode=RBAC,Node . Si RBAC n'est pas listé, les ClusterRoleBindings n'ont aucun effet. - ClusterRoleBindings existants : listez-les avec kubectl get clusterrolebindings . Notez le nombre et les noms personnalisés. - Inventaire des espaces de noms : kubectl get namespaces pour savoir où les rôles et les utilisateurs sont délimités. - Inventaire des utilisateurs/ServiceAccounts : si vous utilisez une authentification externe (OIDC, LDAP), notez comment les utilisateurs sont mappés aux groupes. Les ServiceAccounts sont critiques car les liaisons les référencent souvent. Prérequis pour une exploitation sûre : accès administratif au cluster, un mécanisme de sauvegarde pour les objets RBAC (par exemple, dépôt git ou instantanés etcd), et un espace de noms ou cluster de test pour la validation en dry-run. Pour la production, assurez-vous de pouvoir revenir rapidement en arrière. Une pratique courante consiste à stocker tous les manifestes RBAC dans un système de contrôle de version et à les appliquer via un processus contrôlé. Exemple : pour capturer l'état actuel, exécutez : kubectl get clusterrolebindings -o yaml > clusterrolebindings-backup-$(date +%Y%m%d).yaml Cette commande crée un fichier de sauvegarde horodaté. Vérifiez que le fichier a du contenu : wc -l clusterrolebindings-backup-*.yaml doit renvoyer un nombre de lignes supérieur à zéro. ## Chemin de configuration sûr Le principe du moindre privilège dicte que les ClusterRoleBindings ne doivent accorder que les permissions nécessaires à une tâche. Évitez de lier à des ClusterRoles larges comme cluster-admin sauf si absolument nécessaire. Préférez les RoleBindings dans un espace de noms lorsque l'accès peut être limité. Si un accès à l'échelle du cluster est nécessaire, créez un ClusterRole dédié avec des règles minimales. ### Choix d'implémentation délimités - Utilisez le préfixe system: pour les rôles intégrés afin d'éviter les conflits ; les rôles personnalisés ne doivent pas utiliser ce préfixe. - Pour les comptes de service, utilisez un ServiceAccount séparé par application et liez-le à un ClusterRole spécifique. - Pour l'accès utilisateur, liez à des groupes plutôt qu'à des utilisateurs individuels lorsque c'est possible, car l'appartenance au groupe est gérée en externe. ### Exemple pas à pas : création d'un ClusterRole à moindre privilège et liaison - Définissez un ClusterRole qui permet de lire les pods dans tous les espaces de noms (pour la surveillance) : apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "watch"] Appliquez-le : kubectl apply -f pod-reader-clusterrole.yaml . Sortie attendue : clusterrole.rbac.authorization.k8s.io/pod-reader created . - Créez un ServiceAccount dans l'espace de noms monitoring : kubectl create serviceaccount monitoring-sa -n monitoring Sortie attendue : serviceaccount/monitoring-sa created . - Liez le ClusterRole au ServiceAccount : apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: monitoring-sa-pod-reader subjects: - kind: ServiceAccount name: monitoring-sa namespace: monitoring roleRef: kind: ClusterRole name: pod-reader apiGroup: rbac.authorization.k8s.io Appliquez-le : kubectl apply -f clusterrolebinding.yaml . Sortie attendue : clusterrolebinding.rbac.authorization.k8s.io/monitoring-sa-pod-reader created . ### Dry-run et diff Testez toujours avec --dry-run=client ou --dry-run=server avant d'appliquer en production. Par exemple : kubectl apply -f clusterrolebinding.yaml --dry-run=client Sortie attendue : clusterrolebinding.rbac.authorization.k8s.io/monitoring-sa-pod-reader created (dry run) . Pour un objet existant, utilisez kubectl diff pour voir les changements : kubectl diff -f clusterrolebinding.yaml Cela montre les différences entre l'objet actuel en direct et le fichier. S'il n'y a pas de différences, il n'y a pas de sortie. ## Vérification et diagnostics Après avoir créé ou modifié un ClusterRoleBinding, vous devez vérifier que l'accès prévu est accordé et qu'aucun accès non intentionnel n'est introduit. ### Commandes de vérification - Lister les liaisons : kubectl get clusterrolebindings affiche NOM et RÔLE. Vérifiez que la liaison souhaitée existe. - Décrire une liaison : kubectl describe clusterrolebinding monitoring-sa-pod-reader donne des détails complets comprenant les sujets, le rôle et les étiquettes. - Vérifier les permissions effectives : utilisez kubectl auth can-i --list --as=system:serviceaccount:monitoring:monitoring-sa pour lister toutes les permissions de ce compte de service. Vérifiez qu'il inclut get , list , watch sur les pods et exclut les autres. Exemple : kubectl auth can-i list pods --as=system:serviceaccount:monitoring:monitoring-sa --all-namespaces Sortie attendue : yes . Pour tester une action interdite : kubectl auth can-i delete pods --as=system:serviceaccount:monitoring:monitoring-sa --all-namespaces Sortie attendue : no . ### Audit des liaisons existantes Auditez régulièrement les liaisons pour détecter les rôles trop permissifs. Utilisez un script pour trouver les liaisons qui référencent cluster-admin : kubectl get clusterrolebindings -o json | jq -r '.items[] | select(.roleRef.name=="cluster-admin") | .metadata.name' Cela liste tous les ClusterRoleBindings qui accordent cluster-admin . Examinez chacun pour voir s'il est nécessaire. Vérifiez également les liaisons vers des comptes de service dans kube-system qui peuvent être trop larges. Certains composants système nécessitent certaines permissions, mais les ajouts personnalisés doivent être examinés attentivement. ## Modes de défaillance et récupération Les erreurs dans les ClusterRoleBindings peuvent avoir de graves conséquences. Les modes de défaillance courants comprennent : - Liaison trop permissive : lier accidentellement à cluster-admin donne un contrôle total. Cela peut se produire si un nom de ClusterRole incorrect est utilisé ou si un rôle intégré large est choisi sans examen. - Liaison manquante : si une liaison nécessaire est supprimée ou non appliquée, les applications peuvent échouer avec des erreurs de permission refusée. Par exemple, un agent de surveillance peut ne pas pouvoir lister les pods. - Sujet incorrect : lier au mauvais ServiceAccount ou utilisateur signifie que l'entité prévue n'a pas l'accès tandis qu'une entité non prévue l'obtient. - Liaison vers un ClusterRole inexistant : le serveur API accepte un ClusterRoleBinding même si le ClusterRole référencé n'existe pas. La liaison n'a aucun effet jusqu'à ce que le rôle soit créé, ce qui peut prêter à confusion. ### Étapes de récupération - Revenir à la sauvegarde : si vous avez une sauvegarde de vos objets RBAC, vous pouvez restaurer un état antérieur. Par exemple, si vous avez sauvegardé tous les ClusterRoleBindings dans un fichier, réappliquez-le : kubectl apply -f clusterrolebindings-backup-YYYYMMDD.yaml Cela recréera les liaisons telles qu'elles étaient. Assurez-vous de ne pas écraser involontairement des modifications plus récentes. - Supprimer une liaison trop large : supprimez la liaison problématique et recréez-la avec le moindre privilège : kubectl delete clusterrolebinding monitoring-sa-pod-reader kubectl apply -f correct-clusterrolebinding.yaml Sortie attendue pour la suppression : clusterrolebinding.rbac.authorization.k8s.io "monitoring-sa-pod-reader" deleted . - Corriger un sujet incorrect : utilisez kubectl edit clusterrolebinding pour modifier les sujets directement, ou appliquez un manifeste corrigé. - Créer le rôle manquant : si la liaison référence un ClusterRole manquant, créez-le. Vérifiez avec kubectl get clusterrole . - Tester après récupération : exécutez des commandes kubectl auth can-i en tant qu'utilisateur/compte de service affecté pour confirmer que les permissions sont correctes. ## Liste de contrôle des opérations Le tableau suivant résume une liste de contrôle des opérations reproductible pour les ClusterRoleBindings. Elle doit être intégrée dans vos processus de gestion des changements et de revue périodique.

Étape	Tâche	Commande ou action	Résultat attendu
1	Sauvegarder les liaisons actuelles	`kubectl get clusterrolebindings -o yaml > backup.yaml`	Fichier créé
2	Examiner l'accès demandé	Vérifier le moindre privilège	Aucune permission inutile
3	Tester les modifications en dry-run	`kubectl apply -f file.yaml --dry-run=client`	Aucune erreur affichée
4	Appliquer les modifications	`kubectl apply -f file.yaml`	Objet créé/mis à jour
5	Vérifier l'accès	`kubectl auth can-i --list --as=...`	Permissions attendues présentes
6	Auditer les liaisons à haut risque	`kubectl get clusterrolebindings -o json \| jq ...`	Liste examinée
7	Documenter le changement	Mettre à jour le journal des changements ou le ticket	Enregistré

### Liste de contrôle de revue périodique - Chaque trimestre, listez tous les ClusterRoleBindings et identifiez les propriétaires. Supprimez les liaisons qui ne sont plus nécessaires. - Vérifiez les liaisons vers cluster-admin et exigez une justification. - Recherchez les ServiceAccounts dans l'espace de noms default qui ont des permissions à l'échelle du cluster ; déplacez-les vers des espaces de noms dédiés. - Vérifiez que les groupes d'authentification externe sont mappés correctement. - Exécutez des outils automatisés comme kube-rbac-proxy ou kubectl-who-can pour analyser les permissions. Exemple d'utilisation de kubectl-who-can (à installer séparément) : kubectl who-can list pods --all-namespaces Cela liste tous les sujets qui peuvent lister les pods dans tous les espaces de noms. Utilisez-le pour détecter les accès trop larges. ## Conclusion L'exploitation des ClusterRoleBindings Kubernetes en production nécessite une approche délibérée, pilotée par liste de contrôle. Cet article a fourni une liste de contrôle pratique couvrant l'inventaire des versions, la configuration sûre, la vérification, la récupération en cas de défaillance et les opérations continues. En suivant les étapes et les exemples, vous pouvez maintenir le moindre privilège, auditer efficacement et récupérer rapidement des erreurs. Commencez par un projet pilote étroit, comme la création d'un ClusterRole en lecture seule pour un compte de service de surveillance, et élargissez à mesure que vous gagnez en confiance. Sauvegardez toujours avant les modifications, faites des dry-runs, vérifiez avec kubectl auth can-i et documentez les décisions. Un système RBAC bien géré est fondamental pour la sécurité et la stabilité du cluster.