Commandes RBAC Kubernetes de base avec exemples pratiques

Introduction

Les commandes RBAC Kubernetes de base avec des exemples pratiques doivent aider les opérateurs à passer d'un problème observé à un résultat vérifié. Commencez par identifier la version installée, la topologie de déploiement, les prérequis et le composant exact inspecté.

Cet article se concentre sur les commandes RBAC Kubernetes pour les développeurs, les consultants DevOps et les équipes techniques de startups. Il relie les commandes RBAC Kubernetes de base, les exemples RBAC Kubernetes, l'aide-mémoire RBAC Kubernetes et les opérations RBAC Kubernetes aux commandes, aux sorties attendues, aux signaux d'échec et aux décisions de récupération qui correspondent à la technologie choisie.

L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés au lieu de secrets, vérifier le résultat et documenter comment récupérer si l'état attendu n'est pas atteint.

Inventaire de version et d'environnement

Avant d'émettre des commandes liées au RBAC, confirmez la version de Kubernetes et la disponibilité de l'API RBAC. Le RBAC est stable dans Kubernetes v1.8+ et activé par défaut dans la plupart des distributions gérées. Utilisez kubectl version pour voir les versions client et serveur, et kubectl api-versions pour confirmer que rbac.authorization.k8s.io/v1 est présent. Si le groupe API est absent, le cluster peut avoir des modes d'autorisation hérités activés ; vérifiez les drapeaux du serveur API avec kubectl cluster-info dump | grep authorization-mode ou consultez votre administrateur de cluster.

Un inventaire en lecture seule est la première étape pour des modifications sûres. Par exemple, pour lister les rôles existants dans l'espace de noms par défaut, exécutez :

kubectl get roles -n default

La sortie attendue montre un tableau avec les colonnes NOM et GE. S'il n'y a pas de rôles, la sortie est No resources found in default namespace. Cela vous indique si l'espace de noms a des rôles personnalisés ou s'appuie sur des rôles à l'échelle du cluster.

Pour les ressources à l'échelle du cluster, listez les rôles de cluster :

kubectl get clusterroles

Cela inclut les rôles intégrés comme admin, edit, view et cluster-admin, ainsi que tous les rôles personnalisés. Pour voir un rôle spécifique en détail, utilisez :

kubectl describe clusterrole view

La sortie liste les règles de politique : ressources, verbes et groupes API. Notez que les rôles intégrés sont souvent mis à jour lors des mises à niveau, donc les rôles personnalisés sont préférables pour les permissions à long terme.

Vérification pratique pour l'inventaire de version et d'environnement : commencez par kubectl get pods -o wide, puis utilisez kubectl describe pod <nom> pour les détails de planification et d'événements, kubectl logs <nom> --previous pour les boucles de crash, et kubectl rollout status deployment/<nom> avant de supposer qu'une version a réussi. Ces commandes aident à différencier les échecs d'autorisation RBAC des autres problèmes d'exécution ; par exemple, un CrashLoopBackOff peut être dû à une ConfigMap manquante plutôt qu'à une erreur de permission.

Pour un test local, gardez le rayon d'impact petit. Appliquez un manifeste, inspectez les ressources générées et vérifiez l'accès avec kubectl auth can-i ou un pod de test avant de passer en production. Exemple :

kubectl auth can-i create deployments --as=system:serviceaccount:default:test-sa -n default

Si la réponse est yes, le compte de service a la permission ; si no, inspectez les liaisons de rôle.

Chemin de configuration sûr

Un chemin de configuration sûr commence par définir le principe du moindre privilège. Plutôt que de réutiliser cluster-admin pour chaque équipe, créez des rôles à portée d'espace de noms ou des rôles de cluster avec des verbes et des ressources minimaux. Commencez par observer ce qu'un compte de service ou un utilisateur peut actuellement faire :

kubectl auth can-i --list --as=system:serviceaccount:default:test-sa -n default

Cela liste toutes les actions autorisées pour cette identité. Utilisez ceci avant et après les modifications pour vérifier le delta. Ensuite, faites une modification à la fois ; par exemple, ajoutez un Rôle qui permet de lire les pods dans l'espace de noms default :

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

Appliquez-le avec :

kubectl apply -f pod-reader-role.yaml

Puis liez-le à un utilisateur ou un compte de service en utilisant un RoleBinding :

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: "[email protected]"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

kubectl apply -f pod-reader-binding.yaml

Vérifiez avec :

kubectl auth can-i get pods [email protected] -n default

La sortie doit être yes. Ensuite, tentez une action refusée :

kubectl auth can-i delete pods [email protected] -n default

La sortie doit être no. Cela confirme le moindre privilège.

Pour un accès à l'échelle du cluster, utilisez ClusterRole et ClusterRoleBinding. Par exemple, pour permettre à un groupe de voir les nœuds :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-viewer
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: view-nodes
subjects:
- kind: Group
  name: "operations"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: node-viewer
  apiGroup: rbac.authorization.k8s.io

Appliquez et testez avec :

kubectl auth can-i list nodes --as=system:serviceaccount:default:ops-sa

Si la sortie est no, vérifiez le nom du compte de service et le sujet de liaison.

Vérification et diagnostic

La vérification repose sur kubectl auth can-i, kubectl auth reconcile et les journaux d'audit. Commencez par des vérifications de permission de base comme indiqué ci-dessus. Pour une vue plus exhaustive, listez toutes les règles d'un rôle :

kubectl get role pod-reader -n default -o yaml

Inspectez la sortie pour détecter des verbes ou des ressources inattendus. Utilisez kubectl describe pour un résumé lisible :

kubectl describe clusterrole admin

Cela montre les règles agrégées et les étiquettes.

Le diagnostic des refus d'accès implique souvent de vérifier les journaux d'audit Kubernetes s'ils sont activés. Recherchez des entrées avec requestURI et user correspondant à la requête refusée, et le champ authorization.k8s.io/decision défini sur forbid. Par exemple, dans un cluster géré comme EKS ou GKE, vous devrez peut-être activer la journalisation d'audit pour voir ces événements.

Un autre diagnostic consiste à inspecter les permissions effectives d'un utilisateur via kubectl auth can-i --list --as=user. Comparez-les avec la matrice de rôles prévue. Si des permissions manquent, vérifiez les fautes de frappe dans les noms de ressources, les groupes API (le groupe central est "") et les sujets. Vérifiez également que les RoleBindings sont dans le bon espace de noms ; une erreur courante est de créer un RoleBinding dans l'espace de noms kube-system alors que le Rôle est dans default.

Pour une vérification continue, utilisez des outils comme kubectl-who-can (un plugin kubectl) pour trouver qui peut effectuer une action sur une ressource. Installez-le via krew et exécutez :

kubectl who-can delete secrets -n default

Cela liste tous les sujets avec cette permission, facilitant l'audit et le nettoyage.

Modes d'échec et récupération

Les échecs RBAC se répartissent généralement en quelques modèles : rôles trop permissifs, permissions manquantes et sujets mal configurés. Un problème de sur-permission courant est l'utilisation de cluster-admin pour un compte de service d'application. Cela peut conduire à une compromission complète du cluster si l'application est exploitée. Détectez de telles liaisons avec :

kubectl get clusterrolebinding -o json | jq '.items[] | select(.roleRef.name=="cluster-admin") | .subjects'

Si vous trouvez un compte de service lié à cluster-admin, révoquez-le en supprimant le ClusterRoleBinding :

kubectl delete clusterrolebinding <nom-liaison>

Créez ensuite un Rôle et un RoleBinding à portée limitée comme indiqué précédemment.

Les permissions manquantes se manifestent souvent par des erreurs HTTP 403 Forbidden dans les journaux d'application ou kubectl. Utilisez kubectl auth can-i pour confirmer la permission manquante. Ensuite, créez un Rôle ou ClusterRole avec le verbe et la ressource requis, et liez-le. Par exemple, si un pod ne peut pas lire les ConfigMaps :

kubectl logs <nom-pod> | grep -i forbidden
kubectl auth can-i get configmaps --as=system:serviceaccount:default:my-app -n default

Si no, créez un Rôle avec get sur configmaps et liez-le au compte de service.

Les sujets mal configurés peuvent survenir lorsque le nom du sujet ne correspond pas à l'utilisateur ou au compte de service réel. Pour les comptes de service, le nom du sujet doit inclure l'espace de noms : system:serviceaccount:<namespace>:<name>. Pour les utilisateurs, assurez-vous que le nom correspond au système d'authentification (par exemple, e-mail d'OIDC). Vérifiez avec :

kubectl get rolebinding read-pods -n default -o yaml

Vérifiez le tableau des sujets et corrigez si nécessaire. Après correction, réexécutez kubectl auth can-i pour confirmer.

Pour récupérer d'un changement problématique, gardez les manifestes sous contrôle de version. Si un RoleBinding casse l'accès, vous pouvez revenir avec kubectl apply -f <version précédente> ou supprimer la liaison. Pour une récupération d'urgence, les administrateurs de cluster peuvent utiliser le groupe system:masters ou le rôle cluster-admin s'il est disponible, mais cela doit être étroitement contrôlé.

Liste de contrôle des opérations

Utilisez la liste de contrôle suivante pour les opérations RBAC quotidiennes, adaptée pour un seul propriétaire responsable par élément :

- [ ] Inventorier les rôles et liaisons actuels : `kubectl get roles,rolebindings,clusterroles,clusterrolebindings --all-namespaces`
  Propriétaire : Priya Shah, responsable plateforme, revue hebdomadaire le lundi.
- [ ] Examiner les nouvelles demandes d'accès selon le principe du moindre privilège.
  Propriétaire : Priya Shah, responsable plateforme, décision sous 2 jours ouvrés.
- [ ] Appliquer les modifications via GitOps ou `kubectl apply` avec des manifestes versionnés.
  Propriétaire : Priya Shah, responsable plateforme, après approbation.
- [ ] Vérifier avec `kubectl auth can-i --as=<user> <verb> <resource> -n <namespace>`.
  Propriétaire : Priya Shah, responsable plateforme, immédiatement après l'application.
- [ ] Vérifier les journaux d'audit pour les requêtes refusées liées au changement.
  Propriétaire : Priya Shah, responsable plateforme, le jour ouvré suivant.
- [ ] Documenter les exceptions et fixer une date de revue (par exemple, trimestrielle).
  Propriétaire : Priya Shah, responsable plateforme, trimestriellement le premier lundi de janv/avr/juil/oct.

Chaque élément doit être complété dans l'ordre, et le propriétaire est responsable d'exécuter l'étape et de rapporter le résultat. Revoyez la liste de contrôle elle-même mensuellement pour l'ajuster aux nouvelles ressources ou structures d'équipe.

Pièges courants et comment les éviter

Un piège fréquent est d'accorder des permissions avec des caractères génériques ("*") dans les verbes ou les ressources pour plus de commodité. Cela sape le moindre privilège et augmente le risque. Au lieu de cela, énumérez l'ensemble minimal de verbes (get, list, watch, create, update, patch, delete) et des ressources spécifiques. Si un caractère générique est nécessaire, limitez-le étroitement (par exemple, pods/log plutôt que pods et toutes les sous-ressources).

Un autre piège est d'oublier que les Rôles sont à portée d'espace de noms tandis que les ClusterRoles sont à l'échelle du cluster. Un RoleBinding peut référencer un ClusterRole pour accorder des permissions de rôle de cluster dans un seul espace de noms, ce qui est utile pour réutiliser des définitions de rôle communes. Mais un RoleBinding vers un Rôle n'accorde pas de permissions en dehors de son espace de noms. Inversement, un ClusterRoleBinding accorde un accès à l'échelle du cluster. Une mauvaise compréhension de cela conduit à une sur- ou sous-permission.

Un troisième piège est d'ignorer les ClusterRoles agrégés. Kubernetes agrège des règles dans des rôles comme admin et edit en utilisant des étiquettes. Si vous modifiez accidentellement les étiquettes d'un rôle personnalisé, il peut être agrégé dans ces rôles intégrés et accorder des permissions de manière inattendue. Utilisez kubectl describe clusterrole admin pour voir ses règles agrégées.

Enfin, gérer le RBAC manuellement sans contrôle de version peut conduire à une dérive de configuration et à des retours en arrière difficiles. Stockez tous les manifestes RBAC dans un dépôt Git et utilisez un outil GitOps comme Argo CD ou Flux, ou au moins un pipeline CI/CD qui exécute kubectl apply. Examinez les modifications via des demandes de tirage et exigez deux approbateurs pour les clusters de production.

Conclusion

Les commandes RBAC Kubernetes de base avec des exemples pratiques ne sont utiles que si chaque recommandation est limitée à la version, observable et réversible là où la technologie le permet. Copier une commande sans vérifier les prérequis et la sortie attendue n'est pas une procédure d'exploitation.

Comme prochaine étape, choisissez une vérification à faible risque pour les commandes RBAC Kubernetes : exécutez kubectl auth can-i --list --as=<user> pour un utilisateur de test, enregistrez l'état actuel, comparez le résultat avec la matrice de permissions attendue et examinez les dépendances telles que le Rôle, la Liaison de rôle et le Rôle de cluster.

Un flux de travail technique fiable rend l'échec visible, protège les valeurs sensibles, limite les modifications à la ressource prévue et définit la vérification de récupération avant qu'un incident ne force la décision. En appliquant les commandes et les pratiques de cet article, vous pouvez gérer le RBAC Kubernetes en toute sécurité et efficacement.