Concepts avancés de RBAC Kubernetes expliqués avec des exemples pratiques

Introduction

Le contrôle d'accès basé sur les rôles (RBAC) de Kubernetes est un mécanisme de sécurité fondamental qui régit qui peut faire quoi dans un cluster. Bien que les rôles, les liaisons de rôles et les rôles de cluster de base soient bien documentés, les clusters de production exigent des modèles avancés : mélanger des règles limitées à un espace de noms et des règles à l'échelle du cluster, lier à des groupes et des comptes de service, restreindre les audiences des jetons et construire des flux de travail vérifiables et réversibles.

Cet article comble le fossé entre les extraits de documentation et une confiance opérationnelle réelle. Il fournit des commandes pratiques, des manifestes, des sorties attendues et des procédures de récupération pour des scénarios RBAC avancés. L'accent est mis sur les développeurs, les consultants DevOps et les équipes techniques de startups qui doivent mettre en œuvre un accès à moindre privilège sans se bloquer eux-mêmes.

Nous allons parcourir un flux de travail structuré : inventorier l'environnement, apporter une modification minimale, la vérifier, diagnostiquer les échecs et préparer les étapes de récupération. En chemin, nous utiliserons des exemples concrets avec des valeurs d'espace réservé clairement indiquées et expliquerons comment les adapter à votre cluster.

Inventaire de la version et de l'environnement

Avant de toucher aux objets RBAC, connaissez la version de votre cluster, la disponibilité de l'API et l'état actuel. Le RBAC est devenu stable dans Kubernetes 1.8 (rbac.authorization.k8s.io/v1), mais les clusters plus anciens peuvent encore utiliser v1beta1. Utilisez kubectl api-versions pour confirmer :

kubectl api-versions | grep rbac

La sortie attendue inclut rbac.authorization.k8s.io/v1. Si vous ne voyez que v1beta1, prévoyez un chemin de mise à niveau avant de vous appuyer sur des fonctionnalités avancées comme LabelSelector dans les liaisons.

Ensuite, inventoriez les objets RBAC existants. Pour un aperçu rapide :

kubectl get roles,rolebindings,clusterroles,clusterrolebindings --all-namespaces

Pour le dépannage, vous avez souvent besoin des autorisations effectives d'un utilisateur ou d'un compte de service spécifique. Utilisez kubectl auth can-i comme observation en lecture seule :

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

Cela renvoie yes ou no. Pour plus de détails, utilisez --list :

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

Capturez toujours l'état actuel avant d'apporter des modifications. Exportez les fichiers YAML pertinents :

kubectl get role my-role -n dev -o yaml > my-role-backup.yaml
kubectl get rolebinding my-binding -n dev -o yaml > my-binding-backup.yaml

Cette sauvegarde est votre chemin de récupération si la modification casse quelque chose.

Observation en lecture seule avant modification

Un flux de travail sûr sépare l'observation de l'intervention. Par exemple, si un développeur signale « Impossible de lister les pods dans l'espace de noms dev », vérifiez d'abord ce que son jeton ou son kubeconfig autorise :

kubectl auth can-i list pods --as=system:serviceaccount:dev:developer-sa -n dev

Si la réponse est no, inspectez le rôle et la liaison de rôle associés :

kubectl get role developer-role -n dev -o yaml
kubectl get rolebinding developer-binding -n dev -o yaml

Ce n'est qu'après avoir compris l'écart que vous devez rédiger une modification. Cela évite une élévation accidentelle des privilèges.

Chemin de configuration sûr

Le RBAC avancé signifie souvent combiner plusieurs concepts : comptes de service, rôles, liaisons et parfois rôles de cluster pour les ressources à l'échelle du cluster. Commençons par un cas d'utilisation courant : accorder à un compte de service un accès en lecture à un espace de noms spécifique tout en autorisant un accès en lecture seule aux nœuds (une ressource à l'échelle du cluster).

Exemple : Lecteur d'espace de noms avec accès aux métriques des nœuds

Créez un compte de service :

apiVersion: v1
kind: ServiceAccount
metadata:
  name: dashboard-sa
  namespace: monitoring

Appliquez-le :

kubectl apply -f serviceaccount.yaml

Créez maintenant un rôle dans l'espace de noms monitoring qui permet de lire les pods, les services et les déploiements :

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: monitoring
  name: dashboard-reader
rules:
- apiGroups: [""] # groupe d'API core
  resources: ["pods", "services"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch"]

Liez le compte de service à ce rôle :

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dashboard-binding
  namespace: monitoring
subjects:
- kind: ServiceAccount
  name: dashboard-sa
  namespace: monitoring
roleRef:
  kind: Role
  name: dashboard-reader
  apiGroup: rbac.authorization.k8s.io

Pour les métriques des nœuds à l'échelle du cluster, créez un rôle de cluster :

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

Et une liaison de rôle de cluster :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: dashboard-node-binding
subjects:
- kind: ServiceAccount
  name: dashboard-sa
  namespace: monitoring
roleRef:
  kind: ClusterRole
  name: node-metrics-reader
  apiGroup: rbac.authorization.k8s.io

Appliquez tous les fichiers :

kubectl apply -f role.yaml -f rolebinding.yaml -f clusterrole.yaml -f clusterrolebinding.yaml

Vérifiez que le compte de service peut lister les pods dans monitoring mais ne peut pas créer de déploiements :

kubectl auth can-i list pods --as=system:serviceaccount:monitoring:dashboard-sa -n monitoring
# attendu : yes
kubectl auth can-i create deployments --as=system:serviceaccount:monitoring:dashboard-sa -n monitoring
# attendu : no

Cela démontre le moindre privilège à travers les espaces de noms et la portée du cluster.

Utiliser des groupes dans les liaisons

Pour les équipes, liez les rôles à des groupes plutôt qu'à des utilisateurs individuels. Cela simplifie la gestion : lorsqu'une personne rejoint ou quitte, vous mettez à jour uniquement l'appartenance au groupe dans votre fournisseur d'identité. Exemple de sujet de liaison de rôle :

subjects:
- kind: Group
  name: "dev-team"
  apiGroup: rbac.authorization.k8s.io

Testez ensuite l'accès en tant que membre :

kubectl auth can-i get pods --as=alice --as-group=dev-team -n dev

Cela évite de coder en dur les noms d'utilisateurs dans les liaisons.

Restreindre les liaisons avec des sélecteurs d'étiquettes

Dans Kubernetes 1.28+, vous pouvez utiliser labelSelector dans les liaisons de rôle ou de rôle de cluster pour lier un rôle à tous les espaces de noms correspondant à une étiquette, plutôt que d'énumérer chaque espace de noms individuellement. Exemple :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: dev-namespace-readers
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
subjects:
- kind: Group
  name: "dev-team"
  apiGroup: rbac.authorization.k8s.io
labelSelector:
  matchLabels:
    team: dev

Cela accorde automatiquement le rôle de cluster view à dev-team dans chaque espace de noms étiqueté team=dev. Ainsi, lorsqu'un nouvel espace de noms est créé avec cette étiquette, l'accès est accordé sans modifier la liaison.

Vérification et diagnostic

Après avoir appliqué des modifications RBAC, ne présumez pas du succès. Vérifiez du point de vue de l'utilisateur ou du compte de service réel en utilisant kubectl auth can-i. Cette commande vérifie les règles RBAC en direct et signale les autorisations effectives.

Vérification étape par étape

1. Interrogez en tant que compte de service :

kubectl auth can-i get secrets --as=system:serviceaccount:monitoring:dashboard-sa -n monitoring

Si la sortie est no, passez au diagnostic.

1. Examinez le rôle et la liaison de rôle :

kubectl describe role dashboard-reader -n monitoring
kubectl describe rolebinding dashboard-binding -n monitoring

1. Recherchez les erreurs courantes : noms de ressources mal orthographiés, mauvais groupe d'API, verbes manquants ou références de sujet incompatibles.

1. Utilisez kubectl auth reconcile pour corriger les écarts entre les fichiers déclaratifs et l'état en direct :

kubectl auth reconcile -f role.yaml -f rolebinding.yaml

Cette commande applique les objets RBAC tout en préservant les autorisations supplémentaires qui ont pu être accordées manuellement. Elle est idéale pour les pipelines CI/CD.

Diagnostic avec les journaux d'audit

Pour les problèmes plus profonds, les journaux d'audit Kubernetes peuvent montrer pourquoi une demande a été refusée. Assurez-vous que la journalisation d'audit est activée (généralement en définissant --audit-policy-file sur le serveur API). Une politique typique pour le débogage RBAC :

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata
  verbs: ["create", "update", "delete"]
  resources:
  - group: "rbac.authorization.k8s.io"
    resources: ["roles", "rolebindings", "clusterroles", "clusterrolebindings"]

Vérifiez ensuite les journaux d'audit pour les entrées authorization.k8s.io/decision=forbid. Elles révèlent souvent l'autorisation manquante exacte.

Vérifier les autorisations des jetons de compte de service

Si le compte de service d'un pod ne peut pas accéder aux ressources, inspectez le jeton monté dans le pod et testez avec lui directement. D'abord, trouvez le secret ou le jeton projeté :

kubectl get pod my-app -n dev -o jsonpath='{.spec.serviceAccountName}'

Ensuite, utilisez kubectl exec pour tester depuis l'intérieur du pod si possible, ou extrayez le jeton et utilisez curl contre le serveur API. Une vérification plus rapide consiste à utiliser kubectl auth can-i avec le nom du compte de service comme indiqué ci-dessus.

Modes de défaillance et récupération

Les mauvaises configurations RBAC peuvent bloquer les utilisateurs, accorder des privilèges excessifs ou casser des applications. Voici des scénarios de défaillance courants et comment récupérer.

Bloqué hors d'un espace de noms

Symptôme : Tous les utilisateurs d'une équipe reçoivent Forbidden lorsqu'ils accèdent à un espace de noms après une mise à jour de rôle.

Cause probable : Le roleRef de la liaison de rôle pointe vers un rôle qui n'existe plus ou a été renommé ; ou la liaison a été supprimée accidentellement.

Récupération :

1. Vérifiez si la liaison de rôle existe :

kubectl get rolebinding dev-binding -n dev

1. Si elle est manquante, recréez-la à partir de la sauvegarde :

kubectl apply -f dev-binding-backup.yaml

1. Si le rôle a été modifié, restaurez la version précédente :

kubectl apply -f dev-role-backup.yaml

Conservez toujours des sauvegardes des objets RBAC, surtout avant des modifications en masse.

Autorisations trop larges

Symptôme : Un compte de service peut lister les secrets dans tous les espaces de noms, mais il ne devrait accéder qu'à un seul.

Cause probable : Une liaison de rôle de cluster avec le rôle de cluster view, ou une liaison de rôle avec une ressource générique *.

Récupération :

1. Identifiez toutes les liaisons pour ce compte de service :

kubectl get clusterrolebindings -o json | jq '.items[] | select(.subjects[].name == "dashboard-sa") | .metadata.name'

1. Modifiez la liaison pour supprimer les autorisations inutiles ou remplacez-la par un rôle plus étroit.

1. Utilisez kubectl auth can-i --list pour auditer les autorisations restantes et vous assurer qu'elles respectent le moindre privilège.

Liaison à un compte de service inexistant

Symptôme : L'accès est toujours refusé même si le rôle et la liaison de rôle semblent corrects.

Cause probable : Les subjects référencent un compte de service qui n'existe pas dans l'espace de noms spécifié, ou l'espace de noms est mal orthographié.

Récupération :

• Vérifiez que le compte de service existe :

kubectl get serviceaccount dashboard-sa -n monitoring

• Vérifiez le YAML de la liaison de rôle pour la cohérence de l'espace de noms :

kubectl get rolebinding dashboard-binding -n monitoring -o yaml

• Corrigez la référence et réappliquez.

Pièges courants et comment les éviter

Le RBAC semble simple mais comporte des pièges subtils. Voici les plus fréquents, pourquoi ils se produisent et comment les éviter ou s'en remettre.

Piège 1 : Utiliser * dans les ressources ou les verbes

Pourquoi cela arrive : Les développeurs copient des exemples avec des autorisations génériques par commodité.

Comment éviter : Spécifiez des ressources et des verbes exacts. Utilisez kubectl auth can-i --list sur un compte de service de test pour voir les autorisations effectives avant de passer en production.

Récupération : Remplacez la règle large par une règle étroite. Par exemple, changez :

resources: ["*"]
verbs: ["*"]

en :

resources: ["pods", "deployments"]
verbs: ["get", "list", "watch"]

Piège 2 : Mal comprendre la différence entre ClusterRole et Role

Pourquoi cela arrive : Un ClusterRole est nécessaire pour les ressources à l'échelle du cluster (nœuds, volumes persistants) ou pour accorder un accès entre espaces de noms. Utiliser un Role dans un ClusterRoleBinding ne fonctionne pas.

Comment éviter : Utilisez toujours ClusterRole et ClusterRoleBinding pour les règles à l'échelle du cluster. Pour les règles spécifiques à un espace de noms, utilisez Role et RoleBinding.

Récupération : Si vous avez besoin d'un accès inter-espaces de noms, convertissez votre Role en ClusterRole et liez-le avec un ClusterRoleBinding.

Piège 3 : Oublier de lier le rôle

Pourquoi cela arrive : Vous créez un rôle mais oubliez de créer une liaison de rôle, ou la liaison référence le mauvais sujet.

Comment éviter : Utilisez des fichiers déclaratifs qui incluent à la fois le rôle et la liaison de rôle, et appliquez-les ensemble. Utilisez kubectl auth reconcile pour assurer la cohérence.

Récupération : Créez la liaison de rôle manquante. Vérifiez avec kubectl auth can-i.

Piège 4 : Ignorer l'expiration et l'audience des jetons

Pourquoi cela arrive : Les jetons de compte de service créés avant Kubernetes 1.24 peuvent être à longue durée de vie et manquer de restriction d'audience.

Comment éviter : Utilisez des jetons de compte de service projetés ou des jetons créés manuellement avec des audiences et une expiration :

kubectl create token my-service-account -n my-namespace --audience=my-api-audience --duration=1h

Récupération : Faites pivoter les jetons et imposez des durées de vie courtes. Mettez à jour les applications pour utiliser l'API TokenRequest au lieu de secrets statiques.

Liste de contrôle des opérations

Cette liste de contrôle garantit un processus de modification RBAC cohérent et sûr. Attribuez un responsable unique à chaque élément (par exemple, l'ingénieur de plateforme ou le chef d'équipe) et passez en revue la liste avant et après chaque modification.

Responsabilité et cadence de révision

• Priya Shah (Responsable Plateforme) est responsable des étapes 1, 4, 6 et 7. Elle est chargée des sauvegardes, de la vérification et du déploiement en production. Elle révise la liste de contrôle chaque semaine.
• Alex Chen (Ingénieur DevOps) est responsable des étapes 2 et 3. Il rédige les modifications et les teste en staging. Il met à jour le ticket avec les résultats dans un délai d'un jour ouvrable.
• Sam Rivera (Réviseur Sécurité) est responsable des étapes 5 et 7. Il examine la conformité au moindre privilège et audite les journaux. Il produit un rapport mensuel le premier lundi de chaque mois.

Cette division évite les conflits et garantit qu'une seule personne est responsable de chaque décision.

Conclusion

Le RBAC avancé de Kubernetes ne consiste pas seulement à écrire du YAML ; c'est une discipline opérationnelle. En inventoriant votre environnement avant les modifications, en apportant des modifications minimales, en vérifiant avec kubectl auth can-i et en ayant des plans de récupération, vous réduisez le risque de violations de sécurité et de perturbations de service.

Commencez par une amélioration à faible risque : par exemple, remplacez un rôle générique par des règles précises pour le compte de service de votre équipe. Enregistrez l'état actuel, appliquez la modification et vérifiez avec les commandes indiquées ci-dessus. Passez en revue les dépendances telles que Role, Role Binding, ClusterRole et ClusterRoleBinding pour vous assurer de comprendre le graphe d'accès complet.

Un flux de travail fiable rend les échecs visibles, 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. Mettez en œuvre ces pratiques, et le RBAC de votre cluster sera à la fois sécurisé et gérable.