Sauvegarde et restauration des ClusterRoleBindings Kubernetes : guide pratique

Introduction

Le contrôle d'accès basé sur les rôles (RBAC) de Kubernetes régit qui peut faire quoi dans un cluster. Les ClusterRoleBindings sont des autorisations au niveau du cluster qui attachent un ClusterRole à des sujets tels que des utilisateurs, des groupes ou des comptes de service (ServiceAccounts). Perdre ou corrompre un ClusterRoleBinding peut bloquer les administrateurs hors d'espaces de noms critiques ou supprimer silencieusement des permissions d'applications. Restaurer des liaisons à la main est source d'erreurs et lent. Ce guide explique comment sauvegarder et restaurer les ClusterRoleBindings en toute sécurité, valider les résultats et récupérer des modes de défaillance courants.

Vous apprendrez à inventorier les liaisons existantes, à les exporter en YAML, à utiliser les modes de simulation (dry-run), à appliquer des sauvegardes avec des options de retour en arrière et à vérifier les permissions restaurées. Chaque étape inclut des commandes concrètes et des extraits de sortie attendus pour que vous puissiez suivre dans votre propre cluster.

Avant de commencer, assurez-vous d'avoir kubectl installé et configuré avec un accès à un cluster de test. N'exécutez pas ces procédures en production avant de les avoir validées dans un environnement de préproduction.

Inventaire de la version et de l'environnement

Commencez par confirmer la version de votre cluster et les ressources d'API disponibles pour le RBAC. ClusterRoleBinding fait partie du groupe d'API rbac.authorization.k8s.io/v1, disponible à partir de Kubernetes 1.8. Vérifiez votre version de serveur :

kubectl version --short

La sortie attendue affiche les versions du client et du serveur. Si le serveur est plus ancien que la version 1.8, vous devez utiliser l'API v1beta1, mais pour les clusters modernes, v1 est la norme.

Listez tous les ClusterRoleBindings actuellement dans le cluster :

kubectl get clusterrolebindings

Exemple de sortie :

NAME                            ROLE                                    AGE
cluster-admin                   cluster-admin                           13d
system:basic-user               system:basic-user                      13d
system:discovery                system:discovery                       13d
system:node                     system:node                            13d
system:node-proxier             system:node-proxier                    13d
my-app-binding                  cluster-admin                          2d

Remarquez l'entrée my-app-binding : c'est une liaison personnalisée créée par un utilisateur. C'est le genre de liaison que vous devez sauvegarder.

Utilisez kubectl get clusterrolebindings -o wide pour voir les sujets et les références de rôle dans un tableau :

kubectl get clusterrolebindings -o wide

Sortie attendue :

NAME                ROLE                AGE   USERS   GROUPS   SERVICEACCOUNTS
cluster-admin       cluster-admin       13d
my-app-binding      cluster-admin       2d    jane    devs     default/my-app-sa

Pour inspecter une liaison spécifique en détail, utilisez kubectl describe :

kubectl describe clusterrolebinding my-app-binding

Cela montre le rôle, les sujets et l'horodatage de création. Par exemple :

Name:         my-app-binding
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  ClusterRole
  Name:  cluster-admin
Subjects:
  Kind            Name        Namespace
  ----            ----        ---------
  User            jane
  Group           devs
  ServiceAccount  my-app-sa  default

Capturez toujours les horodatages et l'état actuel avant d'apporter des modifications. Exécutez kubectl get clusterrolebindings my-app-binding -o yaml > my-app-binding-backup-$(date +%Y%m%d).yaml pour enregistrer le manifeste exact. Ce fichier devient votre sauvegarde principale.

Chemin de configuration sûr

Un changement de configuration sûr suit un schéma : observer, exporter, modifier, simuler, appliquer, vérifier. Ne modifiez jamais un objet en direct directement sans sauvegarde. Commencez par exporter la liaison actuelle :

kubectl get clusterrolebinding my-app-binding -o yaml > my-app-binding-original.yaml

Inspectez le fichier. Il contient les métadonnées, roleRef et subjects. Une liaison minimale ressemble à :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: my-app-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: devs
  apiGroup: rbac.authorization.k8s.io
- kind: ServiceAccount
  name: my-app-sa
  namespace: default

Pour créer en toute sécurité une nouvelle liaison, utilisez kubectl apply --dry-run=client pour valider la syntaxe sans persister :

kubectl auth reconcile -f my-app-binding-original.yaml --dry-run=client

Sortie :

clusterrolebinding.rbac.authorization.k8s.io/my-app-binding created (dry run)

Si vous devez tester une modification, copiez le fichier, modifiez le sujet ou le rôle et appliquez avec la simulation. Par exemple, pour ajouter un nouvel utilisateur bob :

# my-app-binding-modified.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: my-app-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
- kind: User
  name: bob
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: devs
  apiGroup: rbac.authorization.k8s.io
- kind: ServiceAccount
  name: my-app-sa
  namespace: default

Simulez-le :

kubectl auth reconcile -f my-app-binding-modified.yaml --dry-run=client

La sortie confirme que le changement serait adopté. Si vous voyez des avertissements concernant des champs manquants, corrigez-les avant d'appliquer réellement.

Utilisez kubectl auth reconcile pour vous assurer que l'objet en direct correspond à votre fichier souhaité. Cette commande applique les différences sans supprimer les sujets qui ne sont pas dans le fichier à moins d'utiliser --remove-extra-subjects. Par exemple, pour garder la liaison exactement comme spécifié dans my-app-binding-original.yaml :

kubectl auth reconcile -f my-app-binding-original.yaml

Sortie :

clusterrolebinding.rbac.authorization.k8s.io/my-app-binding reconciled

Si vous voulez supprimer tout sujet absent du fichier, ajoutez --remove-extra-subjects :

kubectl auth reconcile -f my-app-binding-original.yaml --remove-extra-subjects

C'est utile lors d'une restauration à partir d'une sauvegarde pour réinitialiser la liaison à un état connu.

Procédures de sauvegarde

La sauvegarde des ClusterRoleBindings implique l'exportation de leurs manifestes. Vous pouvez sauvegarder toutes les liaisons en une seule commande en itérant sur la liste.

D'abord, listez tous les noms de liaisons :

kubectl get clusterrolebindings -o name

Sortie :

clusterrolebinding.rbac.authorization.k8s.io/cluster-admin
clusterrolebinding.rbac.authorization.k8s.io/my-app-binding
...

Ensuite, bouclez et enregistrez chacune dans un répertoire horodaté :

mkdir -p clusterrolebinding-backup-$(date +%Y%m%d)
for binding in $(kubectl get clusterrolebindings -o name); do
  name=$(echo $binding | cut -d'/' -f2)
  kubectl get clusterrolebinding $name -o yaml > clusterrolebinding-backup-$(date +%Y%m%d)/$name.yaml
done

Cela crée des fichiers YAML individuels pour chaque liaison. Alternativement, vous pouvez enregistrer toutes les liaisons dans un seul fichier en utilisant kubectl get clusterrolebindings -o yaml > all-bindings.yaml. Cependant, les fichiers individuels sont plus faciles à restaurer sélectivement.

Pour des calendriers de sauvegarde automatisés, envisagez d'intégrer cette commande dans une tâche cron ou un outil de gestion Kubernetes. Mais les exportations manuelles suffisent pour la plupart des petits et moyens clusters.

Vérifiez que les fichiers de sauvegarde sont complets :

ls -l clusterrolebinding-backup-20250315/

La sortie attendue liste chaque fichier YAML. Vérifiez qu'un fichier contient le bon apiVersion et kind :

head -5 clusterrolebinding-backup-20250315/my-app-binding.yaml

Sortie :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: my-app-binding

Stockez les sauvegardes dans un endroit sécurisé, tel qu'un stockage d'objets chiffré ou un dépôt Git avec des contrôles d'accès. Évitez de les garder uniquement sur des disques locaux.

Procédures de restauration

Restaurer une liaison à partir d'un fichier de sauvegarde est simple avec kubectl apply, mais des vérifications de sécurité empêchent les écrasements accidentels.

Si la liaison a été supprimée, appliquez le fichier pour la recréer :

kubectl apply -f clusterrolebinding-backup-20250315/my-app-binding.yaml

Sortie :

clusterrolebinding.rbac.authorization.k8s.io/my-app-binding created

Si la liaison existe mais a été modifiée, kubectl apply la mettra à jour pour correspondre au fichier. Cependant, soyez prudent : apply peut ne pas supprimer les sujets ajoutés ultérieurement. Pour restaurer l'état original exact, y compris la suppression de sujets supplémentaires, utilisez kubectl auth reconcile :

kubectl auth reconcile -f clusterrolebinding-backup-20250315/my-app-binding.yaml --remove-extra-subjects

Sortie :

clusterrolebinding.rbac.authorization.k8s.io/my-app-binding reconciled

Après la restauration, vérifiez que les détails de la liaison correspondent à la sauvegarde :

kubectl get clusterrolebinding my-app-binding -o yaml

Comparez la sortie avec le fichier de sauvegarde. Recherchez des différences dans roleRef et subjects.

Pour une restauration en masse, bouclez sur le répertoire de sauvegarde :

for file in clusterrolebinding-backup-20250315/*.yaml; do
  kubectl apply -f $file
done

Sachez que cela recréera ou mettra à jour toutes les liaisons, y compris celles du système. C'est généralement sûr car les liaisons système sont recréées par Kubernetes si elles sont supprimées, mais faites preuve de prudence en production.

Vérification et diagnostics

Après la sauvegarde ou la restauration, vérifiez que les permissions fonctionnent comme prévu. La commande principale est kubectl auth can-i pour tester l'accès du point de vue d'un sujet.

Pour vérifier si l'utilisateur jane peut lister les pods dans l'espace de noms par défaut :

kubectl auth can-i list pods --as jane

Sortie attendue :

yes

Pour un compte de service, utilisez --as=system:serviceaccount:default:my-app-sa :

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

Si la liaison accorde cluster-admin, la sortie est yes pour tout verbe et toute ressource. Si la liaison est mal configurée, la sortie est no.

Pour diagnostiquer les problèmes de liaison, inspectez le YAML de la liaison et les permissions du rôle. Par exemple, si jane ne peut pas lister les pods, vérifiez si la liaison référence toujours le bon rôle :

kubectl get clusterrolebinding my-app-binding -o jsonpath='{.roleRef.name}'

Sortie attendue :

cluster-admin

Si le nom du rôle est vide ou incorrect, corrigez la liaison. Vérifiez également que le sujet est correctement listé :

kubectl get clusterrolebinding my-app-binding -o jsonpath='{.subjects[*].name}'

Sortie attendue :

jane devs my-app-sa

Utilisez kubectl describe clusterrolebinding my-app-binding pour un résumé lisible des mêmes informations.

Pour des diagnostics à l'échelle du cluster, listez toutes les liaisons et voyez s'il en manque ou si certaines ont des rôles inhabituels :

kubectl get clusterrolebindings -o custom-columns=NAME:.metadata.name,ROLE:.roleRef.name,SUBJECTS:.subjects[*].name

Exemple de sortie :

NAME                ROLE                SUBJECTS
cluster-admin       cluster-admin       jane, devs, my-app-sa
...

Si une liaison est manquante, cela explique les refus d'accès. Restaurez-la à partir de la sauvegarde comme décrit.

Modes de défaillance et récupération

Les modes de défaillance courants incluent la suppression accidentelle, l'écrasement avec de mauvais sujets et les problèmes de dépréciation d'API.

Suppression accidentelle

Si un ClusterRoleBinding est supprimé, les utilisateurs perdent immédiatement l'accès. Pour récupérer, vous avez besoin d'une sauvegarde. Si aucune sauvegarde n'existe, vous pouvez recréer la liaison à partir de la documentation ou d'un cluster similaire. Par exemple, pour restaurer my-app-binding s'il est supprimé :

kubectl apply -f clusterrolebinding-backup-20250315/my-app-binding.yaml

Si vous n'avez pas de sauvegarde, vous devez reconstruire manuellement la liaison en vous basant sur les enregistrements de votre équipe. C'est pourquoi les sauvegardes régulières sont essentielles.

Écrasement avec de mauvais sujets

Si quelqu'un applique un nouveau fichier de liaison qui supprime des sujets nécessaires, vous pouvez restaurer à partir de votre sauvegarde. Supposons que la liaison actuelle ne contienne que l'utilisateur bob mais devrait aussi avoir jane et le compte de service. Restaurez avec kubectl auth reconcile comme ci-dessus.

Dépréciation de version d'API

Sur les anciens clusters, vous pouvez voir des erreurs comme :

error: unable to recognize "my-app-binding.yaml": no matches for kind "ClusterRoleBinding" in version "rbac.authorization.k8s.io/v1"

Cela indique que votre client essaie d'utiliser v1 mais que le serveur ne prend en charge que v1beta1. Vérifiez les versions prises en charge :

kubectl api-versions | grep rbac

La sortie peut inclure rbac.authorization.k8s.io/v1 et rbac.authorization.k8s.io/v1beta1. Si seul v1beta1 est disponible, convertissez votre manifeste en changeant apiVersion en rbac.authorization.k8s.io/v1beta1, ou mettez à niveau le cluster.

Perte d'accès administrateur au cluster

Si vous supprimez accidentellement toutes les liaisons cluster-admin, vous risquez de perdre l'accès administratif. La récupération nécessite un utilisateur avec un accès direct au serveur d'API du cluster ou un mécanisme de secours. Certains clusters configurent des jetons statiques ou un super-utilisateur dans le kubeconfig qui contourne le RBAC. Sinon, vous devrez peut-être restaurer à partir de la sauvegarde etcd ou contacter votre fournisseur cloud. Ce scénario souligne l'importance d'avoir plusieurs utilisateurs administrateurs et des sauvegardes hors cluster.

Stratégies de retour en arrière

Gardez toujours un historique des modifications. Utilisez kubectl rollout undo pour les déploiements, mais pour les objets RBAC, il n'y a pas de retour en arrière intégré. Maintenez plutôt plusieurs versions des fichiers de liaison dans Git et appliquez la version souhaitée pour revenir en arrière. Par exemple, si un changement récent a cassé l'accès, extrayez le commit précédent et exécutez :

git checkout HEAD~1 -- clusterrolebinding-backup-20250315/my-app-binding.yaml
kubectl auth reconcile -f clusterrolebinding-backup-20250315/my-app-binding.yaml --remove-extra-subjects

Cela remet la liaison à l'état précédent.

Liste de contrôle des opérations

Utilisez cette liste de contrôle avant et après toute opération de sauvegarde ou de restauration sur les ClusterRoleBindings.

Exécutez cette liste de contrôle dans un cluster de préproduction d'abord, puis adaptez-la pour la production. Ayez toujours un plan de retour en arrière avant d'appliquer des changements.

Conclusion

La sauvegarde et la restauration des ClusterRoleBindings Kubernetes sont une pratique fondamentale pour la gestion du RBAC. Avec les commandes et procédures de ce guide, vous pouvez protéger votre cluster contre la perte accidentelle de permissions et récupérer rapidement. N'oubliez pas d'exporter régulièrement les liaisons, de stocker les sauvegardes en toute sécurité, de tester les restaurations avec des simulations et de vérifier l'accès après chaque changement. Incluez les ClusterRoleBindings dans votre plan de reprise après sinistre aux côtés des charges de travail et de la configuration. En suivant ces pratiques, vous assurez que les contrôles d'accès de votre cluster restent fiables et récupérables.