Commandes de rôle Kubernetes : guide pratique avec exemples

Introduction

Le RBAC (Role-Based Access Control) de Kubernetes est le mécanisme qui permet d'accorder ou de restreindre des permissions au sein d'un cluster. Un Role définit un ensemble de permissions dans un espace de noms (namespace), comme « lire les pods » ou « créer des déploiements ». Un RoleBinding relie ensuite ce rôle à un utilisateur, un groupe ou un compte de service. Bien que le concept soit simple, l'exploitation sûre de ces ressources exige une approche structurée : observer l'état actuel, apporter des modifications minimales et vérifier le résultat avec les sorties attendues et des signaux d'échec clairs.

Ce guide se concentre sur les commandes de rôle Kubernetes destinées aux développeurs, aux consultants DevOps et aux équipes techniques de startups. Il couvre l'observation des rôles et des liaisons, leur création et leur modification, le diagnostic des problèmes d'accès et la récupération après des erreurs, le tout avec des commandes kubectl concrètes et des exemples de sortie. L'objectif est la sécurité opérationnelle : comprendre ce qui existe avant de le modifier, limiter le rayon d'impact, éviter de coder en dur des secrets et toujours disposer d'un plan de récupération.

Inventaire de l'environnement et des versions

Avant de modifier une configuration RBAC, établissez un état des lieux de votre cluster, des versions d'API pertinentes et des rôles et liaisons actuels. Cela évite les mauvaises suppositions et fournit un point de restauration.

Vérifier la version du cluster et de kubectl

Commandes :

kubectl version --short

Exemple de sortie :

Client Version: v1.25.3
Kustomize Version: v4.5.7
Server Version: v1.25.3

Cela indique la version d'API parlée par votre client et votre serveur. Les ressources RBAC (Role, RoleBinding, ClusterRole, ClusterRoleBinding) appartiennent au groupe d'API rbac.authorization.k8s.io/v1. Les clusters plus anciens peuvent utiliser v1beta1, donc confirmez avec :

kubectl api-versions | grep rbac

La sortie attendue inclut :

rbac.authorization.k8s.io/v1

Si seule v1beta1 apparaît, votre cluster est ancien et certaines fonctionnalités de la v1 peuvent ne pas être prises en charge.

Lister les rôles et liaisons actuels

Voir tous les rôles dans l'espace de noms courant :

kubectl get roles

Exemple :

NAME        CREATED AT
pod-reader  2023-03-15T10:30:00Z
deployer    2023-03-16T09:00:00Z

Pour lister les rôles dans tous les espaces de noms, ajoutez -A :

kubectl get roles -A

De même, listez les RoleBindings :

kubectl get rolebindings

Pour une vue détaillée d'un rôle spécifique, utilisez describe (lecture seule, sûr) :

kubectl describe role pod-reader

Extrait de sortie d'exemple :

Name:         pod-reader
Namespace:    default
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources   Non-Resource URLs  Resource Names  Verbs
  ---------   -----------------  --------------  -----
  pods        []                 []              [get, watch, list]

Cela indique exactement les permissions accordées par le rôle. Ici, il permet de lire les pods dans l'espace de noms default.

Identifier les comptes de service et les sujets

Les sujets RBAC sont souvent des comptes de service. Listez les comptes de service dans l'espace de noms :

kubectl get serviceaccounts

Exemple :

NAME      SECRETS   AGE
default   0         30d
my-app    0         10d

Si un RoleBinding fait référence à un compte de service, vous pouvez le voir dans sa sortie de description :

kubectl describe rolebinding read-pods

Lignes pertinentes :

Role:
  Kind:  Role
  Name:  pod-reader
Subjects:
  Kind            Name      Namespace
  ----            ----      ---------
  ServiceAccount  my-app    default

Cette association est essentielle pour le dépannage des problèmes d'accès.

Liste de contrôle pratique pour l'inventaire de l'environnement

• [x] Les versions du cluster et de kubectl sont compatibles et prennent en charge rbac.authorization.k8s.io/v1.
• [x] Vous avez listé les rôles et RoleBindings existants dans l'espace de noms cible.
• [x] Vous avez décrit le rôle spécifique impliqué et noté ses règles.
• [x] Vous avez identifié le sujet (utilisateur, groupe ou compte de service) qui a besoin d'accès.
• [x] Vous avez sauvegardé les manifestes des ressources existantes à l'aide de kubectl get role <name> -o yaml > role-backup.yaml et kubectl get rolebinding <name> -o yaml > rb-backup.yaml.

Créez toujours des sauvegardes avant de modifier le RBAC, car une mauvaise modification peut bloquer des utilisateurs ou casser des applications.

Chemin de configuration sûr

Lors de la modification des définitions de rôles ou des liaisons, suivez une approche de changement minimal : préférez mettre à jour une ressource existante plutôt que de la remplacer, et testez d'abord dans un espace de noms de non-production.

Créer un nouveau rôle

Définissez le rôle dans un fichier YAML. Exemple pod-reader-role.yaml :

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]  # "" indique le groupe d'API core
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Appliquez-le :

kubectl apply -f pod-reader-role.yaml

Sortie attendue :

role.rbac.authorization.k8s.io/pod-reader created

Vérifiez :

kubectl get role pod-reader

Sortie :

NAME         CREATED AT
pod-reader   2023-03-16T15:00:00Z

Créer un RoleBinding

Créez read-pods-binding.yaml :

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: ServiceAccount
  name: my-app
  namespace: default
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Appliquez :

kubectl apply -f read-pods-binding.yaml

Sortie :

rolebinding.rbac.authorization.k8s.io/read-pods created

Vérifiez :

kubectl get rolebinding read-pods

Sortie :

NAME       ROLE             AGE
read-pods  Role/pod-reader  10s

Modifier un rôle existant

Utilisez kubectl edit seulement lorsque vous comprenez parfaitement l'impact. Pour de petites modifications, patch est plus sûr car plus explicite. Exemple : ajouter le verbe "create" au rôle pod-reader.

kubectl patch role pod-reader --type='json' -p='[{"op": "add", "path": "/rules/0/verbs", "value": ["get", "watch", "list", "create"]}]'

Vérifiez :

kubectl describe role pod-reader

Les verbes incluent désormais create.

Sinon, si vous préférez modifier le fichier et le réappliquer :

kubectl apply -f pod-reader-role.yaml

apply fusionnera les modifications (si vous utilisez les bons champs) et affichera role.rbac.authorization.k8s.io/pod-reader configured.

Simuler les permissions avec auth can-i

Avant de déployer un changement, testez ce qu'un sujet peut faire avec kubectl auth can-i. C'est un excellent moyen en lecture seule de valider le RBAC.

Vérifiez si le compte de service my-app peut lister les pods dans l'espace de noms default :

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

Sortie attendue : yes ou no.

Cette commande usurpe l'identité du compte de service et effectue un contrôle d'autorisation sans réellement exécuter l'action. Elle est inestimable pour le dépannage.

Exemple : après avoir ajouté le verbe create, vérifiez :

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

Si elle renvoie yes, la modification est effective.

Pratiques de déploiement sécurisé

• Utilisez un espace de noms de test dédié (par exemple, rbac-test) pour essayer de nouveaux rôles et liaisons avant de les appliquer en production.
• Préférez kubectl create ou kubectl apply avec des fichiers explicites ; évitez kubectl edit sur des systèmes en direct sans revue.
• Utilisez toujours --dry-run=client -o yaml pour voir l'objet résultant sans le persister :

  kubectl create role test-role --verb=get,list --resource=pods --dry-run=client -o yaml > test-role.yaml

Inspectez ensuite le fichier, et s'il est correct, appliquez-le.

• Utilisez des rôles avec espace de noms (pas de ClusterRoles) sauf si vous avez vraiment besoin d'un accès à l'échelle du cluster. Cela limite le rayon d'impact.

Vérification et diagnostic

Après avoir effectué des modifications, vérifiez que la configuration est correcte et que les sujets prévus ont bien les permissions attendues. Utilisez à la fois l'inspection des ressources et des requêtes usurpées réelles.

Inspecter les ressources RBAC

Obtenez les rôles et liaisons avec des formats de sortie pour une lecture plus facile :

kubectl get roles -o wide

Exemple :

NAME         CREATED AT
pod-reader   2023-03-16T15:00:00Z
deployer     2023-03-17T09:00:00Z

wide peut afficher des colonnes supplémentaires selon la version.

Pour voir toutes les règles de tous les rôles dans un espace de noms, utilisez :

kubectl get roles -o yaml

Et pour les rolebindings, voyez les sujets et roleRef :

kubectl get rolebindings -o yaml

Tester l'accès réel

Utilisez kubectl auth can-i avec différents sujets et verbes. Pour un groupe d'utilisateurs, vous pouvez utiliser --as-group. Exemple : vérifiez si un utilisateur du groupe dev peut supprimer des pods :

kubectl auth can-i delete pods --as=someuser --as-group=dev -n default

Si elle renvoie no, vous savez que le rôle ne possède pas cette permission (ou que la liaison est incorrecte).

Testez avec un compte de service comme montré précédemment. Testez également les actions refusées pour confirmer que les restrictions sont en place :

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

Attendu : no (si non accordé).

Vérifier les événements d'audit

Pour un diagnostic plus approfondi, utilisez kubectl get events --all-namespaces pour voir les événements récents, mais les refus RBAC peuvent ne pas y apparaître. Si votre cluster a la journalisation d'audit activée, vous pouvez inspecter les journaux d'audit de apiserver pour les lignes mentionnant system:serviceaccount:default:my-app et forbidden.

Exemple de commande (sur le nœud du plan de contrôle ou via la pile de journalisation) :

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

Cela révèle souvent la ressource et le verbe exacts refusés.

Flux de travail de diagnostic pratique

1. Identifiez le sujet (utilisateur, groupe, SA) qui est bloqué.
2. Exécutez kubectl auth can-i <verbe> <ressource> --as=<sujet> -n <espace de noms>.
3. Si no, vérifiez le RoleBinding pour voir si le sujet est inclus.

   kubectl describe rolebinding <binding-name>

1. Si la liaison semble correcte, décrivez le rôle pour voir si le verbe/la ressource est accordé(e).

   kubectl describe role <role-name>

1. Si la règle est manquante, ajoutez-la et re-testez avec auth can-i.
2. Si toujours refusé, vérifiez les politiques de réseau ou DNS au niveau du cluster, ou si le sujet a des permissions remplacées par une autre liaison.

Modes de défaillance et récupération

Les erreurs RBAC peuvent bloquer des utilisateurs, casser des applications ou ouvrir des failles de sécurité. Reconnaissez les modes de défaillance courants et sachez comment récupérer rapidement.

Scénarios de défaillance courants

1. Permission manquante pour une application Symptôme : les journaux d'application affichent Error: pods is forbidden: User "system:serviceaccount:default:my-app" cannot list resource "pods" in API group "" in the namespace "default". Diagnostic : le rôle ou le RoleBinding n'accorde pas la permission nécessaire. Récupération : ajoutez la règle manquante au rôle, ou créez un nouveau rôle et liez-le. Vérifiez avec auth can-i.

2. Rôle trop permissif Symptôme : l'audit de sécurité signale qu'un rôle accorde * sur secrets. Diagnostic : les règles du rôle sont trop larges. Récupération : modifiez le rôle pour restreindre les verbes et les ressources. Exemple :

rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get"]
  resourceNames: ["specific-secret"]  # uniquement ce secret

Appliquez et vérifiez.

3. Suppression accidentelle d'un RoleBinding Symptôme : les utilisateurs perdent soudainement l'accès. Diagnostic : kubectl get rolebinding <name> renvoie NotFound. Récupération : si vous avez un YAML de sauvegarde (comme recommandé), réappliquez :

kubectl apply -f rb-backup.yaml

Si aucune sauvegarde, recréez la liaison à partir de la documentation ou d'une liaison similaire dans un autre espace de noms.

4. Sujet ne correspondant pas en raison de l'espace de noms Symptôme : un compte de service dans staging ne peut pas accéder aux ressources dans production, même si un RoleBinding existe. Diagnostic : le RoleBinding est limité à un espace de noms ; un RoleBinding dans production ne peut pas accorder l'accès à un compte de service dans staging à moins que la liaison ne le référence explicitement (l'espace de noms du sujet peut différer, mais la liaison elle-même est dans l'espace de noms de la ressource). Récupération : assurez-vous que le RoleBinding est créé dans l'espace de noms de la ressource, et que l'espace de noms du sujet est correctement spécifié.

5. Inadéquation de version d'API Symptôme : error: unable to recognize "role.yaml": no matches for kind "Role" in version "rbac.authorization.k8s.io/v1beta1". Diagnostic : le cluster est plus récent et ne sert plus v1beta1. Récupération : changez apiVersion en rbac.authorization.k8s.io/v1 et réappliquez.

Meilleures pratiques de récupération

• Conservez toujours des sauvegardes YAML avant les modifications : kubectl get role <name> -o yaml > role-backup-$(date +%F).yaml.
• Utilisez kubectl apply --record (obsolète dans certaines versions) ou la gestion de version pour les manifestes.
• Testez les changements dans un espace de noms de non-production d'abord.
• Ayez un compte d'urgence « break-glass » avec des privilèges cluster-admin (ou au moins des permissions pour modifier le RBAC) pour la récupération.
• Documentez le comportement attendu et un plan de restauration pour chaque modification RBAC.

Simuler une défaillance pour gagner en confiance

Vous pouvez intentionnellement créer une liaison mal configurée pour voir comment les erreurs apparaissent et pratiquer la récupération. Exemple : Créez un rôle sans verbes (invalide) :

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: empty-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: []

L'application de ceci entraînera une erreur : spec.rules[0].verbs: Required value: at least one verb must be specified. Cela vous apprend les champs requis.

Liste de contrôle des opérations

Utilisez cette liste de contrôle pour les opérations RBAC quotidiennes. Chaque élément comprend une commande ou une vérification concrète avec le résultat attendu.

Avant tout changement

• [ ] Vérifiez la version du cluster : kubectl version --short - assurez-vous que RBAC v1 est pris en charge.
• [ ] Listez les rôles et liaisons existants dans l'espace de noms cible : kubectl get roles,rolebindings -n <namespace>.
• [ ] Décrivez le rôle spécifique impliqué : kubectl describe role <role-name> -n <namespace>.
• [ ] Identifiez le sujet nécessitant l'accès : utilisateur, groupe ou compte de service.
• [ ] Sauvegardez les ressources RBAC actuelles : kubectl get role <name> -o yaml > backup/role-<name>-$(date +%F).yaml et de même pour le rolebinding.

Création ou modification de rôles

• [ ] Écrivez un manifeste avec le moindre privilège : uniquement les groupes d'API, ressources et verbes nécessaires.
• [ ] Faites un essai à blanc de la création : kubectl create role test --verb=get,list --resource=pods --dry-run=client -o yaml > test.yaml puis inspectez.
• [ ] Appliquez le manifeste : kubectl apply -f role.yaml - attendez role.rbac.authorization.k8s.io/<name> created ou configured.
• [ ] Vérifiez le nouveau rôle : kubectl get role <name> -o yaml.

Création ou modification de liaisons

• [ ] Assurez-vous que l'espace de noms du sujet est correct (si compte de service).
• [ ] Appliquez la liaison : kubectl apply -f binding.yaml.
• [ ] Vérifiez la liaison : kubectl get rolebinding <name> -o yaml.

Vérification

• [ ] Testez l'accès avec usurpation : kubectl auth can-i <verbe> <ressource> --as=system:serviceaccount:<namespace>:<sa-name> -n <namespace> - attendez yes ou no.
• [ ] Testez une action refusée pour confirmer le moindre privilège : kubectl auth can-i delete secrets --as=... - attendez no.
• [ ] Vérifiez les journaux d'application ou exécutez rapidement un pod avec le compte de service pour tester le comportement réel (si nécessaire).

Après le changement

• [ ] Mettez à jour la documentation (procédures, commentaires dans les manifestes).
• [ ] Stockez les manifestes finaux dans la gestion de version.
• [ ] Informez les membres de l'équipe concernés du changement d'accès.

Récupération d'urgence

• [ ] En cas de verrouillage, utilisez un compte administrateur break-glass ou un chemin alternatif (par exemple, accès direct à l'API avec certificat client) pour restaurer le RBAC.
• [ ] Réappliquez les derniers manifestes connus bons.
• [ ] Vérifiez l'accès restauré avec auth can-i et un test utilisateur réel.
• [ ] Menez une revue post-incident : pourquoi est-ce arrivé ? Comment l'éviter ?

Conclusion

Les commandes de rôle Kubernetes sont essentielles pour gérer l'accès au sein des espaces de noms, mais elles exigent une discipline opérationnelle rigoureuse. En suivant l'approche structurée décrite ici — inventaire, configuration sûre, vérification, récupération après échec et listes de contrôle — vous pouvez éviter les pièges courants comme les rôles trop permissifs, les liaisons cassées et les verrouillages.

Comme prochaine étape, choisissez un scénario à faible risque : créez un rôle en lecture seule pour un compte de service dans un espace de noms de test, vérifiez avec kubectl auth can-i, puis refusez intentionnellement une action pour voir le mode de défaillance. Enregistrez les commandes et les résultats dans le runbook de votre équipe. Cette pratique concrète renforce la confiance et les habitudes sûres.

Une gestion fiable du RBAC repose sur l'observabilité, le moindre privilège et la réversibilité. Avec les bonnes commandes et une approche méthodique, vous pouvez garder votre cluster sécurisé et vos applications opérationnelles.