Commandes d'autorisation Kubernetes : guide pratique avec exemples

Introduction

L'autorisation Kubernetes détermine les actions qu'un utilisateur, un groupe ou un compte de service peut effectuer sur les ressources du cluster. Alors que l'authentification prouve qui vous êtes, l'autorisation contrôle ce que vous êtes autorisé à faire. Une autorisation mal configurée est l'une des principales causes d'incidents de sécurité et de surprises opérationnelles dans les clusters Kubernetes.

Ce guide explique les modèles d'autorisation courants, montre des commandes kubectl pratiques avec des sorties réalistes et démontre comment vérifier et dépanner les accès. Il est destiné aux développeurs, consultants DevOps et équipes techniques de startups qui doivent travailler de manière sûre et efficace. L'accent est mis sur le système de contrôle d'accès basé sur les rôles (RBAC, Role-Based Access Control) par défaut, mais les concepts s'appliquent également aux autres modes d'autorisation.

Nous supposons que vous disposez d'un cluster Kubernetes en cours d'exécution avec kubectl configuré et au moins un accès en lecture à certaines ressources. Tous les exemples utilisent des noms illustratifs ; remplacez-les par les valeurs de votre environnement.

Pourquoi l'autorisation est importante

Prenons le cas d'une équipe qui accueille un nouveau développeur. Vous créez un fichier kubeconfig qui accorde des droits complets de cluster-admin parce que c'est facile. Des mois plus tard, une mauvaise configuration supprime un namespace de production. C'est une histoire courante. L'autorisation doit suivre le principe du moindre privilège : n'accorder que les permissions requises pour un rôle spécifique.

Le RBAC dans Kubernetes repose sur quatre objets clés :

• Role : définit les permissions au sein d'un seul namespace.
• ClusterRole : définit les permissions au niveau du cluster ou pour les ressources namespacées dans tous les namespaces.
• RoleBinding : accorde les permissions d'un Role à des utilisateurs, des groupes ou des comptes de service au sein d'un namespace.
• ClusterRoleBinding : accorde les permissions d'un ClusterRole au niveau du cluster.

Ces objets sont gérés via l'API rbac.authorization.k8s.io/v1.

Prérequis et vérification de version

Avant d'exécuter des commandes d'autorisation, vérifiez votre environnement. Vérifiez la version du serveur Kubernetes :

kubectl version --short

Une sortie attendue inclut à la fois les versions client et serveur, par exemple :

Client Version: v1.29.2
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.29.2

Le RBAC est stable depuis Kubernetes 1.8, mais les versions plus récentes peuvent ajouter des champs comme aggregationRule ou conditions. Assurez-vous que votre serveur API est joignable :

kubectl cluster-info

Si vous voyez Unable to connect to the server, votre kubeconfig ou la configuration réseau nécessite une attention.

Confirmez également votre identité et vos permissions actuelles :

kubectl auth whoami

Cette commande, disponible dans Kubernetes 1.24+, affiche l'utilisateur authentifié et ses groupes. Exemple de sortie :

ATTRIBUTE   VALUE
Username    [email protected]
Groups      [system:authenticated, dev-team]

Afficher les rôles et les liaisons

Commencez par lister les Roles existants dans un namespace :

kubectl get roles -n development

Exemple de sortie :

NAME        CREATED AT
pod-reader  2024-03-15T10:30:00Z

Pour voir les détails d'un Role spécifique :

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

Cela produit la définition YAML complète, y compris les règles. Extrait d'exemple :

rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

Pour les permissions au niveau du cluster, listez les ClusterRoles :

kubectl get clusterroles

Vous verrez de nombreux rôles définis par le système. Pour vous concentrer sur les rôles personnalisés, filtrez par étiquette ou par nom. Par exemple, pour trouver les rôles liés à la surveillance :

kubectl get clusterroles | grep monitoring

Pour afficher les liaisons :

kubectl get rolebindings -n development

Sortie :

NAME              ROLE              AGE
read-pods         Role/pod-reader   2d

Et les liaisons au niveau du cluster :

kubectl get clusterrolebindings

Pour inspecter une liaison :

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

Partie pertinente de la sortie :

subjects:
- kind: User
  name: [email protected]
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Cela montre que l'utilisateur [email protected] est lié au rôle pod-reader dans le namespace development.

Vérifier vos propres permissions

La commande la plus pratique pour l'autorisation est kubectl auth can-i. Elle teste si l'utilisateur actuel peut effectuer une action. Par exemple :

kubectl auth can-i create deployments --namespace development

Sortie :

yes

Si refusé, elle renvoie no. Ajoutez --list pour voir toutes les permissions :

kubectl auth can-i --list --namespace development

Cela produit un tableau comme :

Resources   Non-Resource URLs   Resource Names   Verbs
pods        []                  []               [get list watch]
services    []                  []               [get list]

Vous pouvez tester les permissions d'un autre utilisateur ou compte de service en utilisant --as :

kubectl auth can-i get secrets --namespace production --as system:serviceaccount:production:default

Cela vérifie si le compte de service par défaut dans le namespace production peut obtenir des secrets. La sortie est yes ou no.

Utile pour le dépannage lorsqu'un utilisateur signale un problème d'accès : exécutez la même commande can-i avec --as suivi de son nom d'utilisateur pour voir le résultat de son point de vue.

Exemple de création d'un Role et d'un RoleBinding

Créons un exemple pratique. Nous voulons accorder à un développeur nommé [email protected] un accès en lecture aux pods dans le namespace staging.

Tout d'abord, créez un manifeste de Role pod-reader-role.yaml :

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

Appliquez-le :

kubectl apply -f pod-reader-role.yaml

Ensuite, créez un manifeste de RoleBinding pod-reader-binding.yaml :

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

Appliquez-le :

kubectl apply -f pod-reader-binding.yaml

Vérifiez maintenant l'accès de Bob :

kubectl auth can-i list pods --namespace staging --as [email protected]

Sortie : yes.

Et vérifiez que Bob ne peut pas supprimer des pods :

kubectl auth can-i delete pods --namespace staging --as [email protected]

Sortie : no.

Cela démontre le principe du moindre privilège en action.

Exemple de création d'un ClusterRole et d'un ClusterRoleBinding

Pour un accès en lecture seule au niveau du cluster, utilisez un ClusterRole. Créez cluster-pod-reader.yaml :

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

Appliquez-le :

kubectl apply -f cluster-pod-reader.yaml

Puis liez-le à un groupe dev-team :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-pods-global
subjects:
- kind: Group
  name: dev-team
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-pod-reader
  apiGroup: rbac.authorization.k8s.io

Appliquez et testez pour un utilisateur de ce groupe :

kubectl auth can-i list pods --all-namespaces --as [email protected]

Si Carol est membre de dev-team, la sortie est yes. Sinon, no.

Autorisation des comptes de service

Les applications utilisent souvent des comptes de service pour interagir avec l'API Kubernetes. Pour accorder des permissions à un pod, créez un compte de service et liez-lui un rôle.

Créez le compte de service app-reader dans le namespace webapp :

kubectl create serviceaccount app-reader -n webapp

Créez ensuite un RoleBinding qui accorde le rôle pod-reader existant à ce compte de service :

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

Appliquez la liaison, puis vérifiez si le compte de service peut lister les pods :

kubectl auth can-i list pods --namespace webapp --as system:serviceaccount:webapp:app-reader

Sortie attendue : yes.

Pour permettre à un pod d'utiliser ce compte de service, définissez serviceAccountName: app-reader dans la spécification du pod. L'application du pod pourra alors appeler le serveur API avec le jeton du compte de service et disposer de ces permissions.

Inspecter l'accès du point de vue du serveur API

Parfois, vous devez voir si une requête entrante serait autorisée. Vous pouvez utiliser le drapeau --v=8 sur le serveur API pour journaliser les décisions d'autorisation, mais cela nécessite un accès au plan de contrôle. Plus couramment, utilisez kubectl auth reconcile pour vous assurer que les liaisons correspondent à l'état souhaité.

Par exemple, avant d'appliquer des modifications, vous pouvez réconcilier les objets RBAC à partir d'un fichier :

kubectl auth reconcile -f rbac-policies.yaml

Cette commande garantit que les rôles et les liaisons du fichier correspondent au cluster, en ajoutant ou en supprimant les permissions nécessaires. Elle est plus sûre que kubectl apply car elle supprime également les permissions qui ne sont plus dans le fichier (avec le drapeau --remove-extra-permissions). Utilisez-la avec prudence.

kubectl auth reconcile -f rbac-policies.yaml --remove-extra-permissions

Examinez toujours le diff d'abord en ajoutant --dry-run=client :

kubectl auth reconcile -f rbac-policies.yaml --remove-extra-permissions --dry-run=client -o yaml

Cela montre ce qui changerait sans appliquer.

Dépanner les problèmes d'autorisation

Lorsqu'un utilisateur ou une application signale des erreurs « interdit », suivez une approche systématique.

Étape 1 : Identifier l'utilisateur et l'action demandée

Demandez le message d'erreur exact. Kubernetes renvoie des messages clairs comme :

Error from server (Forbidden): pods is forbidden: User "[email protected]" cannot list resource "pods" in API group "" in the namespace "production"

Cela vous indique l'utilisateur ([email protected]), la ressource (pods), le namespace (production) et le verbe (list).

Étape 2 : Vérifier les liaisons existantes

Listez les liaisons de rôle dans le namespace :

kubectl get rolebindings -n production

Et les liaisons de cluster :

kubectl get clusterrolebindings | grep alice

Examinez les rôles référencés par ces liaisons pour voir quels verbes sont autorisés.

Étape 3 : Utiliser can-i avec --as

Simulez l'accès de l'utilisateur :

kubectl auth can-i list pods --namespace production --as [email protected]

Si la sortie est no, l'utilisateur n'a pas cette permission.

Étape 4 : Vérifier les règles du rôle pour les correspondances

Vérifiez si le rôle inclut le groupe d'API, la ressource et le verbe nécessaires. Une erreur courante est d'utiliser le mauvais groupe d'API. Par exemple, les deployments sont dans le groupe apps, pas dans le groupe central (""). Un rôle qui accorde l'accès aux pods n'accorde pas l'accès à pods/log ; c'est une sous-ressource distincte.

Étape 5 : Vérifier les refus dus au RBAC ou à d'autres contrôleurs d'admission

Le RBAC est l'une des étapes d'autorisation et d'admission. Si l'utilisateur a le rôle mais est toujours refusé, considérez les webhooks d'admission ou les Pod Security Policies (obsolètes). Vérifiez les journaux d'audit du serveur API si disponibles.

Utiliser l'usurpation d'identité pour des tests avancés

Pour tester en tant qu'un autre utilisateur sans avoir ses identifiants, utilisez l'usurpation d'identité. Vous avez besoin de la permission d'usurper des utilisateurs, souvent accordée aux administrateurs de cluster. Le drapeau --as de kubectl demande l'usurpation.

Exemple :

kubectl get pods --namespace development [email protected]

Si vous recevez forbidden, cela signifie que le serveur API a rejeté l'usurpation (il vous manque le verbe impersonate sur l'utilisateur) ou qu'Alice n'a pas accès.

Pour usurper un groupe :

kubectl get pods --as=system:serviceaccount:webapp:app-reader

Cela est utile pour vérifier les permissions d'un compte de service.

Auditer les modifications d'autorisation

Suivez les modifications des objets RBAC à l'aide de kubectl get events ou des journaux d'audit. Les événements ne sont pas détaillés pour le RBAC, mais vous pouvez consulter l'historique d'un rôle via kubectl rollout status (non applicable) ou en vérifiant les métadonnées et les annotations de l'objet si vous les avez ajoutées.

Une meilleure pratique consiste à activer la journalisation d'audit de Kubernetes. Configurez le serveur API avec une politique d'audit qui journalise les modifications des ressources rbac.authorization.k8s.io. Ensuite, lors du dépannage, vous pouvez interroger le journal d'audit pour voir qui a apporté des modifications et quand.

Par exemple, une politique pourrait inclure :

rules:
- level: RequestResponse
  resources:
  - group: "rbac.authorization.k8s.io"
    resources: ["roles", "rolebindings", "clusterroles", "clusterrolebindings"]

Utilisez ensuite des outils comme jq ou grep pour filtrer le journal d'audit à la recherche de modifications récentes.

Pratiques de configuration sûres

Lors de la modification de l'autorisation, suivez ces bonnes pratiques :

1. Utilisez un compte de service dédié pour l'IC/CD au lieu de votre utilisateur personnel. Cela limite le rayon d'impact en cas de fuite d'identifiants.
2. Évitez cluster-admin pour les utilisateurs réguliers. Réservez-le pour les comptes de secours.
3. Utilisez des groupes pour les liaisons de rôles. Liez les permissions à des groupes, puis gérez l'appartenance aux groupes dans votre fournisseur d'identité. Cela réduit la nécessité de modifier les objets Kubernetes lorsque des personnes rejoignent ou partent.
4. Testez les modifications dans un cluster non productif d'abord. Appliquez les mêmes manifestes RBAC à un cluster de staging et vérifiez avec can-i.
5. Utilisez --dry-run=client pour prévisualiser les modifications. Par exemple :

   kubectl apply -f role.yaml --dry-run=client -o yaml

Cela montre l'objet qui serait appliqué sans l'appliquer réellement.

1. Sauvegardez les objets RBAC existants avant suppression. Exportez-les :

   kubectl get rolebindings -n development -o yaml > rbac-backup.yaml

Vous pourrez ensuite les réappliquer si nécessaire.

1. Envisagez d'utiliser kubectl auth reconcile pour gérer le RBAC de manière déclarative, mais seulement après avoir examiné les modifications avec --dry-run.

Pièges courants et comment les éviter

1. Confondre les verbes et les ressources

Erreur : Accorder update mais pas patch, ou list mais pas get. Certains contrôleurs utilisent watch avec list pour un fonctionnement efficace. Omettre des verbes nécessaires provoque des échecs intermittents.

Évitement : Testez avec kubectl auth can-i --list pour voir toutes les permissions d'un sujet et alignez l'ensemble des verbes sur les actions que le sujet doit effectuer. Pour une surveillance en lecture seule, get, list et watch sont souvent nécessaires.

Récupération : Ajoutez le verbe manquant au rôle et réappliquez. Vérifiez avec can-i.

2. Utiliser le mauvais groupe d'API

Erreur : Créer un rôle pour deployments avec apiGroups: [""] (groupe central). Les déploiements sont dans le groupe apps.

Évitement : Vérifiez le groupe d'API de la ressource avec kubectl api-resources | grep deployment. La sortie montre le groupe, par exemple, deployments apps/v1 true Deployment.

Récupération : Corrigez le champ apiGroups du rôle en ["apps"] et réappliquez.

3. Oublier les sous-ressources

Erreur : Accorder l'accès à pods mais pas à pods/log. Un utilisateur peut lister les pods mais ne peut pas voir les journaux.

Évitement : Identifiez les sous-ressources nécessaires et incluez-les explicitement. Par exemple, pour autoriser l'accès aux journaux, ajoutez resources: ["pods/log"] avec le verbe get.

Récupération : Mettez à jour le rôle pour inclure la sous-ressource et réappliquez.

4. Permissions trop larges

Erreur : Utiliser * pour les verbes ou les ressources par commodité. Cela viole le moindre privilège et augmente le risque.

Évitement : Commencez par le plus petit ensemble de permissions et étendez seulement si nécessaire. Utilisez kubectl auth can-i --list pour voir ce qui est réellement accordé.

Récupération : Remplacez les jokers par des listes explicites. Par exemple, au lieu de verbs: ["*"], utilisez verbs: ["get", "list", "watch"] pour les rôles en lecture seule.

5. RoleBinding dans le mauvais namespace

Erreur : Lier un Role dans le namespace default alors que l'utilisateur a besoin d'un accès dans production. Les RoleBindings sont limités au namespace ; ils n'accordent pas d'accès hors de leur namespace.

Évitement : Vérifiez le champ namespace dans les manifestes de Role et de RoleBinding. Utilisez kubectl -n <namespace> de manière cohérente.

Récupération : Créez un nouveau RoleBinding dans le bon namespace, ou utilisez un ClusterRoleBinding si l'accès est nécessaire dans tous les namespaces.

6. Ne pas tester avec le contexte du compte de service

Erreur : Un pod ne parvient pas à accéder à l'API, mais l'erreur est enfouie dans les journaux de l'application. Le développeur suppose que le RBAC est correct parce qu'il a testé avec son propre utilisateur.

Évitement : Testez toujours les permissions du compte de service avec kubectl auth can-i --as system:serviceaccount:<namespace>:<sa-name>. Inspectez également le compte de service du pod et assurez-vous que le jeton est monté.

Récupération : Corrigez le nom du compte de service dans la spécification du pod, ou créez le RoleBinding approprié pour le compte de service.

Résumé des commandes de vérification et de diagnostic

Voici un aide-mémoire des commandes d'autorisation courantes :

Ces commandes couvrent la plupart des tâches d'autorisation quotidiennes.

Liste de contrôle des opérations pour la maintenance des autorisations

En tant qu'opérateur de cluster, planifiez des revues régulières du RBAC. Voici une liste de contrôle pratique :

• Hebdomadaire : Examinez les nouvelles liaisons de rôle de cluster (par exemple, kubectl get clusterrolebindings | grep -v system: pour voir les liaisons non système) et révoquez celles qui sont inutiles.
• Mensuel : Auditez les comptes de service avec des privilèges élevés en utilisant kubectl get serviceaccounts --all-namespaces et vérifiez s'ils sont liés à cluster-admin ou à d'autres rôles puissants.
• Trimestriel : Effectuez une revue RBAC complète : exportez tous les rôles et liaisons, comparez-les à une politique documentée et supprimez les permissions inutilisées ou trop larges.
• À la demande : Lorsqu'un incident de sécurité survient, inspectez immédiatement les journaux d'audit et révoquez les permissions risquées avec kubectl delete rolebinding <nom> -n <namespace> ou kubectl delete clusterrolebinding <nom>.

Responsabilité : Désignez un responsable de la sécurité Kubernetes (par exemple, le lead de l'équipe plateforme) qui est chargé du processus de revue RBAC. Ce responsable doit être nommé dans votre documentation avec un délégué de secours.

Modes de défaillance et récupération

Les échecs d'autorisation se manifestent souvent dans les journaux d'application ou les rapports des utilisateurs. Comprendre les modes de défaillance courants aide à une récupération rapide.

Défaillance : L'utilisateur perd soudainement l'accès

Cause : Un RoleBinding a été supprimé ou modifié, éventuellement par un script automatisé ou par inadvertance.

Diagnostic : Vérifiez les modifications récentes avec kubectl get events --sort-by=.lastTimestamp ou les journaux d'audit. Recherchez la suppression de liaisons.

Récupération : Recréez la liaison à partir de la sauvegarde ou de l'historique Git. S'il n'y a pas de sauvegarde, utilisez kubectl get rolebindings -n <namespace> -o yaml pour voir les liaisons existantes et comparer avec celles attendues. Si nécessaire, créez une nouvelle liaison.

Défaillance : Un nouvel utilisateur ne peut accéder à rien

Cause : L'utilisateur n'est lié à aucun rôle, ou la liaison existe mais l'identité d'authentification de l'utilisateur ne correspond pas (par exemple, e-mail vs nom d'utilisateur).

Diagnostic : Exécutez kubectl auth can-i --list --as=<utilisateur> pour voir qu'il n'a aucune permission. Confirmez l'identité de l'utilisateur avec kubectl auth whoami (s'il peut l'exécuter) ou demandez-lui d'exécuter kubectl config view pour voir son utilisateur de contexte actuel.

Récupération : Créez le RoleBinding approprié pour son nom d'utilisateur ou son groupe.

Défaillance : Jeton de compte de service invalide

Cause : Le jeton du compte de service a été renouvelé ou le pod n'utilise pas le bon compte de service.

Diagnostic : Décrivez le pod et vérifiez serviceAccountName. Vérifiez les secrets du compte de service (si le montage automatique est activé). Essayez d'utiliser le jeton manuellement avec curl vers le serveur API.

Récupération : Assurez-vous que la spécification du pod a le bon serviceAccountName. Si le jeton est compromis, supprimez le secret pour forcer la régénération (dans les anciennes versions) ou comptez sur les jetons projetés (par défaut dans 1.24+).

Défaillance : Les permissions semblent correctes mais toujours refusées

Cause : Un autre contrôleur d'admission (comme un webhook de validation) rejette la requête, ou une politique réseau bloque la connexion au serveur API.

Diagnostic : Vérifiez les journaux du serveur API pour les décisions d'autorisation. Si des webhooks sont utilisés, inspectez leurs journaux. Désactivez temporairement le webhook (si possible) pour isoler le problème.

Récupération : Corrigez la configuration du webhook ou ajustez la politique réseau.

Conclusion

L'autorisation Kubernetes est un composant critique de la sécurité du cluster. En utilisant les commandes pratiques et les exemples de ce guide, vous pouvez gérer efficacement les rôles, les liaisons et les comptes de service tout en respectant le principe du moindre privilège. Testez régulièrement les permissions avec kubectl auth can-i, examinez les configurations RBAC et surveillez les journaux d'audit pour maintenir un cluster sécurisé et performant.

Rappelez-vous : observez avant de changer, limitez le rayon d'impact, utilisez des espaces réservés au lieu de secrets, vérifiez les résultats et documentez les étapes de récupération. Avec ces pratiques, vous pouvez vous assurer que les bonnes personnes et les bons services ont exactement l'accès dont ils ont besoin.