Dépannage RBAC Kubernetes : bonnes pratiques et exemples pratiques

Introduction

Le contrôle d'accès basé sur les rôles (RBAC) est le principal mécanisme d'autorisation dans Kubernetes, contrôlant qui peut effectuer quelles actions sur quelles ressources. Une configuration RBAC incorrecte est l'une des causes les plus courantes d'erreurs d'accès refusé, d'échecs de déploiement et de constats d'audit de sécurité. Ce guide propose une approche pratique, axée sur les commandes, pour dépanner les problèmes RBAC dans les clusters Kubernetes. Vous apprendrez à identifier systématiquement les problèmes d'autorisation, vérifier les configurations, appliquer des correctifs de moindre privilège et éviter les pièges courants.

Cet article s'adresse aux développeurs, ingénieurs DevOps et opérateurs de plateforme qui gèrent des clusters Kubernetes et doivent résoudre rapidement les échecs d'autorisation sans compromettre la sécurité. Chaque commande inclut la sortie attendue ou un signal clair de succès, et chaque recommandation est limitée à une version spécifique de Kubernetes (1.24+ sauf indication contraire). L'objectif est la sécurité opérationnelle : comprendre l'état actuel, apporter des modifications minimales, vérifier le résultat et documenter les étapes de récupération.

Inventaire des versions et de l'environnement

Avant de dépanner RBAC, confirmez la version et les caractéristiques de l'environnement. RBAC est stable dans toutes les versions prises en charge de Kubernetes, mais les noms de groupes d'API et certains indicateurs peuvent varier. Exécutez ces commandes en lecture seule pour capturer l'état actuel :

• kubectl version --short (obsolète en 1.26, utilisez kubectl version sans --short)
• kubectl cluster-info
• kubectl get nodes -o wide

Exemple de sortie pour kubectl version côté client :

Client Version: v1.27.3
Kustomize Version: v5.0.1
Server Version: v1.26.5

Confirmez que la version du serveur correspond à vos attentes. L'API RBAC est rbac.authorization.k8s.io/v1 depuis Kubernetes 1.8, donc aucun changement spécifique à la version n'est nécessaire pour le dépannage de base.

Identifiez le composant exact en échec. S'agit-il d'un utilisateur, d'un compte de service ou d'un groupe ? Utilisez kubectl auth can-i --list pour voir toutes les autorisations de l'utilisateur actuel, ou spécifiez un autre utilisateur avec --as :

kubectl auth can-i --list --as=system:serviceaccount:default:my-app

Cela produit un tableau des ressources et des verbes autorisés. Si vous n'obtenez aucune sortie, l'utilisateur n'a peut-être aucune autorisation.

Pour les comptes de service, confirmez l'espace de noms et l'existence :

kubectl get serviceaccount my-app -n default

S'il n'est pas trouvé, le pod qui le référence échouera au démarrage avec CreateContainerConfigError. Vérifiez les événements :

kubectl describe pod my-pod -n default | grep -A5 Events

Commencez toujours par des observations en lecture seule et évitez de faire des modifications avant de comprendre le rayon d'impact.

Chemin de configuration sûr

La configuration RBAC se compose de quatre types d'objets principaux : Role, ClusterRole, RoleBinding et ClusterRoleBinding. Un chemin de dépannage sûr commence par l'affichage des objets existants et le test des autorisations avant de modifier quoi que ce soit.

Étape 1 : Afficher les objets RBAC actuels. Listez les rôles et les liaisons dans l'espace de noms concerné :

kubectl get roles,rolebindings -n my-namespace
kubectl get clusterroles,clusterrolebindings | grep my-app

Étape 2 : Tester les autorisations sans rien changer. Utilisez kubectl auth can-i pour vérifier des actions spécifiques pour un utilisateur ou un compte de service :

kubectl auth can-i create deployments --as=system:serviceaccount:default:my-app -n my-namespace

Sortie attendue si autorisé :

yes

Si refusé :

no

Étape 3 : Inspecter les règles effectives. Utilisez kubectl describe pour afficher les règles du rôle :

kubectl describe role my-app-role -n my-namespace

Exemple de sortie :

Name:         my-app-role
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources   Non-Resource URLs  Resource Names  Verbs
  ---------   -----------------  --------------  -----
  pods        []                 []              [get list watch]
  deployments []                 []              [get list watch create update patch delete]

Étape 4 : Apporter le plus petit changement justifié. Si le rôle ne possède pas un verbe requis, créez un fichier de correctif ou utilisez kubectl edit avec précaution. Par exemple, pour ajouter l'autorisation delete sur les pods, créez un correctif YAML :

# add-delete-pods.yaml
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch", "delete"]

Appliquez avec :

kubectl patch role my-app-role -n my-namespace --patch "$(cat add-delete-pods.yaml)"

Étape 5 : Vérifier le changement. Relancez kubectl auth can-i pour confirmer que la nouvelle autorisation est effective. Vérifiez également que la liaison référence toujours le bon rôle et le bon sujet :

kubectl get rolebinding my-app-binding -n my-namespace -o yaml

N'utilisez jamais le caractère générique * dans les verbes ou les ressources sauf en cas d'absolue nécessité, et évitez d'accorder cluster-admin aux comptes de service.

Vérification et diagnostics

Après avoir effectué un changement, vérifiez à la fois la configuration et le comportement réel. Voici les commandes de diagnostic clés :

Vérifier toutes les autorisations d'un compte de service :

kubectl auth can-i --list --as=system:serviceaccount:default:my-app -n my-namespace

Exemple de sortie :

Resources                                       Non-Resource URLs   Resource Names   Verbs
pods                                            []                  []               [get list watch]
deployments.apps                                []                  []               [create delete get list patch update watch]

Vérifier une action spécifique sur une ressource spécifique :

kubectl auth can-i get secret/my-secret --as=system:serviceaccount:default:my-app -n my-namespace

Afficher les événements liés à RBAC dans l'espace de noms :

kubectl get events -n my-namespace --field-selector reason=FailedToGetResource

Examiner les journaux d'audit du serveur d'API (si activés). Pour les clusters gérés, consultez les journaux du fournisseur cloud. Pour les clusters autogérés, utilisez grep sur le journal d'audit :

grep "my-app" /var/log/kubernetes/audit.log | grep "forbidden"

Les journaux d'audit fournissent des raisons détaillées des refus, comme des verbes manquants ou des noms de ressources manquants. Si vous voyez forbidden: User "system:serviceaccount:default:my-app" cannot get resource "pods", cela indique une autorisation RBAC manquante.

Tester l'exécution du pod avec le compte de service. Créez un pod temporaire avec le compte de service et exécutez kubectl à l'intérieur (si l'image possède kubectl) ou utilisez kubectl run :

kubectl run test-pod --image=bitnami/kubectl:latest --restart=Never --serviceaccount=my-app -n my-namespace -- sleep 3600

Ensuite, exécutez une commande dans le pod qui devrait être autorisée ou refusée :

kubectl exec -it test-pod -n my-namespace -- kubectl get pods

Si elle est refusée, vous verrez une erreur Forbidden. Nettoyez avec kubectl delete pod test-pod -n my-namespace.

Modes d'échec et récupération

Les échecs RBAC se manifestent généralement par des erreurs Forbidden dans les journaux, des appels API échoués ou des pods bloqués en CrashLoopBackOff. Voici les modes d'échec les plus courants et comment les récupérer.

1. Autorisation manquante pour un compte de service utilisé par un contrôleur.

Symptômes : Les journaux du contrôleur affichent 403 Forbidden lors de la surveillance des ressources. Exemple :

E0120 10:00:00.123456       1 reflector.go:138] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:167: Failed to watch *v1.Pod: failed to list *v1.Pod: pods is forbidden: User "system:serviceaccount:my-namespace:my-controller" cannot list resource "pods" in API group "" in the namespace "my-namespace"

Récupération : Créez ou mettez à jour un Role accordant list et watch sur pods, et liez-le au compte de service. Appliquez et redémarrez le pod du contrôleur pour prendre en compte les changements (si le rechargement dynamique n'est pas utilisé).

2. L'utilisateur ne peut pas effectuer une action mais possède un rôle qui semble suffisant.

Symptôme : kubectl auth can-i renvoie no malgré un rôle avec le verbe. Causes possibles : liaison de rôle dans le mauvais espace de noms, nom de sujet incohérent ou groupe d'API incohérent.

Récupération : Vérifiez les détails de la liaison :

kubectl get rolebinding my-binding -n my-namespace -o yaml

Vérifiez subjects et roleRef. Assurez-vous que le nom de l'utilisateur est exactement celui authentifié (sensible à la casse). Pour les ressources à l'échelle du cluster, assurez-vous d'avoir utilisé ClusterRole et ClusterRoleBinding, pas des objets limités à l'espace de noms.

3. Autorisations génériques entraînant un accès non intentionnel.

Symptôme : Un compte de service a plus d'accès que prévu, découvert lors d'un audit. Récupération : Remplacez les règles génériques par des ressources et verbes explicites. Exemple de mauvaise règle :

rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]

Remplacez par une liste explicite, par exemple uniquement pods et deployments avec des verbes spécifiques. Utilisez kubectl auth can-i --list pour documenter les autorisations réduites.

4. ClusterRoleBinding créé au lieu de RoleBinding pour un accès limité à l'espace de noms.

Symptôme : L'utilisateur peut accéder à tous les espaces de noms, pas seulement à celui prévu. Récupération : Supprimez le ClusterRoleBinding et créez un RoleBinding dans l'espace de noms spécifique. Vérifiez avec kubectl auth can-i --list --as=user -n target-ns.

5. Les changements RBAC ne prennent pas effet.

Symptôme : Après l'application d'un nouveau rôle, l'accès est toujours refusé. RBAC est éventuellement cohérent, mais les changements devraient se propager en quelques secondes. Sinon, vérifiez les fautes de frappe ou que le serveur d'API a l'autorisation RBAC activée (par défaut). Vérifiez avec kubectl get clusterrolebinding system:node -o yaml pour vous assurer que RBAC fonctionne. Si les problèmes persistent, redémarrez le serveur d'API (uniquement pour les clusters autogérés).

Liste de contrôle des opérations

Utilisez cette liste de contrôle lors de toute session de dépannage RBAC. Attribuez un responsable à chaque élément (par exemple, l'ingénieur de garde) et révisez la liste après chaque incident ou changement. Pour une hygiène RBAC continue, examinez les autorisations chaque trimestre.

Pièges courants

Évitez ces erreurs fréquentes lors de la gestion de Kubernetes RBAC.

Piège 1 : Assigner cluster-admin aux comptes de service. C'est tentant pour des correctifs rapides mais crée un risque de sécurité massif. Si le pod est compromis, l'attaquant obtient le contrôle total du cluster.

Pourquoi cela arrive : Les développeurs veulent souvent éviter les problèmes d'autorisation pendant le développement. Comment éviter : Utilisez le moindre privilège dès le début. Créez des rôles spécifiques pour chaque compte de service. Utilisez des outils comme kubectl auth can-i pour déterminer les autorisations exactes nécessaires. Récupération : Remplacez le ClusterRoleBinding par un RoleBinding limité à l'espace de noms avec des autorisations minimales.

*Piège 2 : Utiliser le caractère générique dans les verbes ou ressources.** Les caractères génériques accordent un accès large qui peut violer les politiques de sécurité et rendre l'audit plus difficile.

Pourquoi cela arrive : C'est plus rapide que de lister chaque ressource. Comment éviter : Prenez les minutes supplémentaires pour lister des ressources et verbes précis. Récupération : Auditez les caractères génériques existants avec kubectl get clusterroles,roles -o yaml | grep -B5 -A5 '\*' et remplacez-les par des règles explicites.

Piège 3 : Oublier que RBAC est uniquement additif. Il n'y a pas de règle de « refus » dans RBAC. Si un utilisateur possède un rôle autorisant une action, il peut l'exécuter, même si un autre rôle semble la refuser.

Pourquoi cela arrive : Mauvaise compréhension de la sémantique RBAC. Comment éviter : Concevez des rôles mutuellement exclusifs ou utilisez des moteurs de politiques externes comme OPA si vous avez besoin de règles de refus. Récupération : Examinez toutes les liaisons de l'utilisateur et supprimez les rôles indésirables.

Piège 4 : Incohérence des groupes d'API. Par exemple, accorder deployments dans le groupe d'API de base au lieu de apps ne fonctionnera pas.

Pourquoi cela arrive : Confusion sur les groupes de ressources. Comment éviter : Utilisez kubectl api-resources pour trouver le bon groupe pour une ressource. Récupération : Mettez à jour le rôle avec le champ apiGroups correct.

Piège 5 : Ignorer la portée de l'espace de noms. Créer un RoleBinding au lieu d'un ClusterRoleBinding pour des ressources à l'échelle du cluster ou vice versa.

Pourquoi cela arrive : Ne pas vérifier si la ressource est limitée à l'espace de noms ou à l'échelle du cluster. Comment éviter : Utilisez kubectl api-resources --namespaced=true/false pour déterminer la portée. Récupération : Convertissez le type de liaison de manière appropriée.

Conclusion

Le dépannage de Kubernetes RBAC nécessite une approche systématique : identifier le sujet, inspecter les autorisations actuelles, tester avec kubectl auth can-i, apporter des modifications minimales et vérifier. En suivant les pratiques de ce guide, vous pouvez résoudre rapidement les problèmes d'accès tout en maintenant une posture de sécurité à moindre privilège. Documentez toujours les changements et examinez régulièrement les politiques RBAC pour prévenir les incidents futurs.

Comme prochaine étape, exécutez kubectl auth can-i --list pour votre propre utilisateur et pour tous les comptes de service de votre cluster afin d'identifier les autorisations trop larges. Ensuite, choisissez un compte de service et resserrez ses autorisations en utilisant le chemin de configuration sûr décrit ci-dessus. Enregistrez l'état actuel, appliquez une mise à jour de rôle minimale et vérifiez avec une commande de test. N'oubliez pas : l'objectif n'est pas seulement de corriger l'erreur immédiate, mais d'assurer la sécurité et l'auditabilité à long terme.