Apprenez à estimer, surveiller et planifier la capacité des ClusterRoleBindings Kubernetes pour éviter la prolifération des permissions et garder vos clusters sécurisés et gérables.
---
## 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 ce que les utilisateurs et les comptes de service peuvent faire dans un cluster. Les ClusterRoleBindings, en particulier, accordent des permissions définies dans un ClusterRole à l'ensemble du cluster ou à des espaces de noms sélectionnés. À mesure que les clusters se développent, le nombre de ClusterRoleBindings peut augmenter rapidement, entraînant une surcharge de gestion, des risques de sécurité potentiels et des problèmes de performance. Dans ce guide, nous allons parcourir la planification pratique de la capacité des ClusterRoleBindings, en couvrant les stratégies de dimensionnement, les signaux de mise à l'échelle et les marges de sécurité opérationnelles. À la fin, vous saurez comment estimer le nombre de liaisons que votre cluster peut gérer, surveiller la croissance et mettre en place des garde-fous pour maintenir une configuration RBAC saine.
---
## Inventaire des versions et de l'environnement
Avant de planifier la capacité, établissez une base de référence de votre environnement Kubernetes. La version de Kubernetes est importante car les objets de l'API RBAC et les caractéristiques de performance évoluent. Pour ce guide, nous supposons Kubernetes 1.21 ou ultérieur, où l'API RBAC est stable et bien documentée. De plus, notez la configuration du serveur d'API car il est responsable de l'application des décisions d'autorisation. Le nombre de réplicas du serveur d'API, leur allocation CPU/mémoire et les performances du backend etcd influencent tous le nombre de ClusterRoleBindings pouvant être gérés efficacement.
Exécutez la commande suivante pour vérifier la version de votre cluster et le nombre de serveurs d'API :
kubectl version --short && kubectl get pods -n kube-system -l component=kube-apiserver
Exemple de sortie :
Client Version: v1.24.3
Server Version: v1.24.3
NAME READY STATUS RESTARTS AGE
kube-apiserver-1 2/2 Running 0 30d
kube-apiserver-2 2/2 Running 0 30d
kube-apiserver-3 2/2 Running 0 30d
Cela montre un plan de contrôle sain avec trois réplicas du serveur d'API, indiquant une haute disponibilité. La taille et les performances du cluster etcd sont également des facteurs ; un etcd plus grand peut stocker plus d'objets, mais la latence d'écriture peut augmenter.
Ensuite, inventoriez les objets RBAC existants :
kubectl get clusterrolebindings --all-namespaces
Cela liste tous les ClusterRoleBindings. Notez le nombre :
kubectl get clusterrolebindings -o name | wc -l
Vérifiez également les ClusterRoleBindings qui pourraient être inutilisés ou trop larges. La commande suivante extrait le nom, le rôle et les sujets de chaque liaison pour aider à identifier les modèles :
kubectl get clusterrolebindings -o custom-columns='NAME:.metadata.name,ROLE:.roleRef.name,SUBJECTS:.subjects[*].name' | head -20
Exemple de sortie :
NAME ROLE SUBJECTS
cluster-admin-binding cluster-admin system:masters
gitlab-runner-binding gitlab-runner gitlab-runner-sa
monitoring-binding pod-reader metrics-collector,logs-viewer
Cet inventaire rapide montre combien de liaisons existent, quels rôles elles référencent et quels sujets sont liés. Utilisez ces données pour identifier les liaisons trop larges (par exemple, celles accordant cluster-admin) ou les liaisons avec de nombreux sujets, qui peuvent être candidates à la division.
---
## Chemin de configuration sûr
Lors de la planification de la capacité, commencez par un ensemble limité et minimal de ClusterRoleBindings. Évitez de créer des liaisons qui accordent cluster-admin à de nombreux utilisateurs. À la place, décomposez les permissions en ClusterRoles plus petits et réutilisables et liez-les uniquement là où c'est nécessaire.
Pour ce guide, nous utiliserons un exemple pratique : une application qui a besoin d'un accès en lecture aux pods dans tous les espaces de noms pour la surveillance. Au lieu d'utiliser un rôle large, créez un ClusterRole dédié et liez-le à un compte de service.
Tout d'abord, créez un ClusterRole avec uniquement les permissions requises :
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
Appliquez-le :
kubectl apply -f pod-reader-clusterrole.yaml
Sortie attendue :
clusterrole.rbac.authorization.k8s.io/pod-reader created
Ensuite, créez un ClusterRoleBinding pour un compte de service spécifique. Supposons que nous ayons un espace de noms monitoring avec un compte de service metrics-collector :
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: read-pods-binding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: pod-reader
subjects:
- kind: ServiceAccount
name: metrics-collector
namespace: monitoring
Appliquez-le :
kubectl apply -f read-pods-binding.yaml
Sortie attendue :
clusterrolebinding.rbac.authorization.k8s.io/read-pods-binding created
Pour mettre à l'échelle à partir de cela, utilisez une convention de nommage et limitez le nombre de liaisons par rôle. Par exemple, si vous avez de nombreux comptes de service nécessitant le même rôle, envisagez d'utiliser un seul ClusterRoleBinding avec plusieurs sujets plutôt que de nombreuses liaisons séparées. Cela réduit le nombre total d'objets et facilite la gestion.
Voici un exemple de ClusterRoleBinding multi-sujets :
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: read-pods-binding-multi
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: pod-reader
subjects:
- kind: ServiceAccount
name: metrics-collector
namespace: monitoring
- kind: ServiceAccount
name: logs-viewer
namespace: logging
- kind: User
name: jane.doe
Appliquez et vérifiez :
kubectl apply -f read-pods-binding-multi.yaml
kubectl get clusterrolebinding read-pods-binding-multi -o json | jq '.subjects | length'
Sortie attendue :
clusterrolebinding.rbac.authorization.k8s.io/read-pods-binding-multi created
3
Cette approche maintient le nombre de liaisons bas tout en accordant l'accès à plusieurs sujets. Visez à regrouper les sujets qui partagent le même rôle et la même limite de confiance dans une seule liaison lorsque c'est possible. Cependant, soyez prudent : une seule liaison avec de nombreux sujets peut devenir un goulot d'étranglement de gestion si l'accès doit être révoqué pour un sujet, car cela nécessite de modifier la liaison. Une stratégie équilibrée consiste à regrouper par équipe ou par application plutôt que par rôle seul.
---
## Vérification et diagnostics
Après avoir créé ou modifié des ClusterRoleBindings, vérifiez que les permissions fonctionnent comme prévu. Utilisez kubectl auth can-i pour tester l'accès d'un sujet.
Pour le compte de service metrics-collector , vérifiez s'il peut lister les pods :
kubectl auth can-i list pods --as=system:serviceaccount:monitoring:metrics-collector --all-namespaces
Sortie attendue :
yes
S'il renvoie no , dépannez en inspectant le ClusterRole et le ClusterRoleBinding :
kubectl describe clusterrole pod-reader
kubectl describe clusterrolebinding read-pods-binding
Recherchez les noms de rôle mal appariés, les sujets incorrects ou les verbes manquants. Les problèmes courants incluent :
- Fautes de frappe dans le nom du roleRef.
- Espace de noms du sujet ne correspondant pas pour les comptes de service.
- Groupe d'API omis ou incorrect (par exemple, utiliser rbac.authorization.k8s.io incorrectement).
- Verbes insuffisants (par exemple, manquer watch pour un contrôleur).
Pour surveiller le nombre de ClusterRoleBindings au fil du temps, utilisez l'API Kubernetes ou un script. Par exemple, une simple boucle de surveillance :
watch -n 10 'kubectl get clusterrolebindings --no-headers | wc -l'
Cela affiche le nombre toutes les 10 secondes. Pour une solution plus robuste, intégrez les métriques Prometheus du serveur d'API. Le serveur d'API expose plusieurs métriques qui peuvent aider à la planification de capacité :
apiserver_request_duration_seconds
apiserver_request_total
etcd_object_counts
Plus précisément, etcd_object_counts montre le nombre d'objets de chaque type de ressource stockés dans etcd. Utilisez la commande suivante pour extraire le nombre de ClusterRoleBindings :
kubectl get --raw /metrics | grep etcd_object_counts | grep clusterrolebindings
Exemple de sortie :
etcd_object_counts{resource="clusterrolebindings"} 127
Cela montre 127 ClusterRoleBindings actuellement stockés. Surveillez ce nombre par rapport à votre base de référence pour détecter les tendances de croissance. De plus, suivez les percentiles de latence des requêtes du serveur d'API, car les vérifications d'autorisation contribuent au temps de requête global :
kubectl get --raw /metrics | grep apiserver_request_duration_seconds | grep 'quantile="0.99"'
Si la latence augmente en même temps que le nombre de liaisons, cela peut indiquer que l'évaluation RBAC devient un goulot d'étranglement. Bien que Kubernetes utilise un index en mémoire efficace pour RBAC, un très grand nombre de liaisons peut avoir un impact sur les performances.
---
## Modes de défaillance et récupération
La surprovisionnement de ClusterRoleBindings peut entraîner plusieurs risques :
- Prolifération des permissions : Trop de liaisons rendent difficile l'audit de qui a accès à quoi.
- Sur-octroi accidentel : Une liaison large peut accorder des permissions excessives si elle n'est pas soigneusement examinée.
- Dégradation des performances : Chaque requête d'autorisation peut impliquer la vérification de toutes les liaisons pertinentes. Bien que Kubernetes utilise une indexation efficace, un nombre extrêmement élevé de liaisons pourrait affecter les performances du serveur d'API, en particulier dans les grands clusters avec des taux de requêtes élevés.
- Références pendantes : Une liaison qui pointe vers un ClusterRole inexistant provoque des refus d'autorisation pour tous les sujets.
Pour récupérer des modifications accidentelles, maintenez le contrôle de version pour les manifestes RBAC. Si une mauvaise liaison est appliquée, revenez en arrière en utilisant kubectl :
kubectl delete clusterrolebinding read-pods-binding
kubectl apply -f previous-read-pods-binding.yaml
Un autre mode de défaillance est une liaison qui référence un ClusterRole inexistant. Cela entraîne des refus d'autorisation. Détectez-le en vérifiant le statut du ClusterRoleBinding : bien que Kubernetes ne remplisse pas de champ de statut pour les objets RBAC, vous pouvez tester l'accès :
kubectl auth can-i list pods --as=some-user
S'il renvoie no , inspectez la référence de rôle de la liaison :
kubectl get clusterrolebinding some-binding -o jsonpath='{.roleRef.name}'
kubectl get clusterrole || echo "ClusterRole not found"
Sortie attendue en cas de manque :
Error from server (NotFound): clusterroles.rbac.authorization.k8s.io "missing-role" not found
ClusterRole not found
Pour revenir en arrière, recréez le ClusterRole ou corrigez la liaison.
Pour la planification de capacité, définissez des seuils : par exemple, alertez lorsque le nombre de ClusterRoleBindings dépasse 500 (selon la taille du cluster). Ce seuil doit être basé sur les performances observées de votre cluster et la capacité de gestion. Un point de départ courant est d'alerter à 50 % au-dessus de votre nombre de base, puis d'affiner en fonction de la capacité de votre équipe à examiner et gérer les liaisons. Utilisez des règles d'alerte Prometheus ou un simple cron job pour vérifier le nombre. Voici un exemple de règle d'alerte Prometheus :
groups:
- name: rbac-capacity
rules:
- alert: ClusterRoleBindingCountHigh
expr: etcd_object_counts{resource="clusterrolebindings"} > 500
for: 10m
labels:
severity: warning
annotations:
summary: "ClusterRoleBinding count is high"
description: "ClusterRoleBinding count is {{ $value }}, exceeding the threshold of 500."
Alternativement, un simple cron job qui exécute kubectl get clusterrolebindings --no-headers | wc -l et envoie un e-mail ou un message Slack lorsque le nombre dépasse un seuil est suffisant pour les petits clusters.
---
## Liste de contrôle des opérations
Utilisez la liste de contrôle suivante pour maintenir une capacité saine de ClusterRoleBindings.
| Étape | Action | Fréquence |
|---|
| 1 | Inventorier les ClusterRoleBindings et comparer à la base de référence | Hebdomadaire |
| 2 | Examiner les nouvelles liaisons pour le moindre privilège | À la création |
| 3 | Tester l'accès des comptes de service critiques après les modifications | À chaque modification |
| 4 | Surveiller la latence du serveur d'API et le nombre d'objets RBAC | Continu |
| 5 | Auditer les liaisons inutilisées (aucun sujet ou aucune utilisation) | Mensuel |
| 6 | Documenter les conventions de nommage et les stratégies de liaison | Au besoin |
| 7 | Définir des alertes pour une croissance inattendue du nombre de liaisons | Continu |
Commandes pour les vérifications courantes :
- Lister les liaisons avec sujets : kubectl get clusterrolebindings -o wide
- Compter les liaisons : kubectl get clusterrolebindings --no-headers | wc -l
- Trouver les liaisons sans sujets : kubectl get clusterrolebindings -o json | jq '.items[] | select(.subjects | length == 0) | .metadata.name'
- Vérifier les percentiles de durée des requêtes du serveur d'API : kubectl get --raw /metrics | grep apiserver_request_duration_seconds | grep 'quantile="0.99"'
- Lister les rôles et leurs liaisons : kubectl get clusterrolebindings -o custom-columns='NAME:.metadata.name,ROLE:.roleRef.name'
- Trouver les liaisons référençant un rôle spécifique : kubectl get clusterrolebindings -o json | jq '.items[] | select(.roleRef.name == "pod-reader") | .metadata.name'
Utilisez ces commandes dans des scripts pour automatiser les vérifications de routine. Pour les équipes utilisant GitOps, intégrez ces vérifications dans les pipelines CI/CD pour empêcher la fusion de liaisons non conformes.
---
## Conclusion
La planification de capacité des ClusterRoleBindings Kubernetes est un processus continu. Commencez par comprendre l'environnement de votre cluster, puis implémentez des liaisons limitées avec des permissions minimales. Vérifiez l'accès et surveillez la croissance à l'aide des outils et métriques intégrés. En cas de mauvaise configuration, revenez en arrière en utilisant des manifestes sous contrôle de version. En suivant la liste de contrôle des opérations et en définissant des seuils appropriés, vous pouvez prévenir la prolifération des permissions et maintenir une configuration RBAC sécurisée et gérable. Prochaines étapes : établir un nombre de base, configurer des alertes de surveillance et planifier des examens d'accès réguliers. Rappelez-vous que l'objectif n'est pas seulement de limiter le nombre de liaisons, mais de garantir que chaque liaison est nécessaire, correctement délimitée et facilement auditable.