## 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 : ```bash 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 : ```bash 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 : ```bash 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 ` pour les détails de planification et d'événements, `kubectl logs --previous` pour les boucles de crash, et `kubectl rollout status deployment/` 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 : ```bash 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 : ```bash 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` : ```yaml 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 : ```bash kubectl apply -f pod-reader-role.yaml ``` Puis liez-le à un utilisateur ou un compte de service en utilisant un RoleBinding : ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: read-pods namespace: default subjects: - kind: User name: "jane@example.com" apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io ``` ```bash kubectl apply -f pod-reader-binding.yaml ``` Vérifiez avec : ```bash kubectl auth can-i get pods --as=jane@example.com -n default ``` La sortie doit être `yes`. Ensuite, tentez une action refusée : ```bash kubectl auth can-i delete pods --as=jane@example.com -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 : ```yaml 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 : ```bash 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 : ```bash 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 : ```bash 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 : ```bash 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 : ```bash 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 : ```bash kubectl delete clusterrolebinding ``` 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 : ```bash kubectl logs | 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::`. Pour les utilisateurs, assurez-vous que le nom correspond au système d'authentification (par exemple, e-mail d'OIDC). Vérifiez avec : ```bash 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 ` 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 : ```markdown - [ ] 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= -n `. 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=` 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.