Sauvegarde et restauration des ClusterRoles Kubernetes : guide pratique de mise en œuvre

Introduction

La sauvegarde et la restauration des ClusterRoles Kubernetes constituent une tâche opérationnelle critique pour maintenir la sécurité et le bon fonctionnement de votre cluster. Les ClusterRoles définissent les autorisations au niveau du cluster, et leur perte due à une suppression accidentelle, une mauvaise configuration ou une mise à niveau échouée peut perturber les charges de travail et compromettre la sécurité. Ce guide fournit une approche pratique, étape par étape, pour sauvegarder, restaurer et valider les ClusterRoles à l'aide des outils et commandes natifs de Kubernetes. Que vous soyez développeur, ingénieur DevOps ou membre d'une équipe technique de startup, vous apprendrez à mettre en place une stratégie de sauvegarde fiable, à effectuer des restaurations et à éviter les pièges courants.

L'objectif de cet article est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés plutôt que des secrets, vérifier les résultats et documenter les chemins de récupération. Nous couvrirons l'inventaire des versions et de l'environnement, les chemins de configuration sûrs, la vérification et les diagnostics, les modes de défaillance et la récupération, ainsi qu'une liste de contrôle opérationnelle. Tous les exemples sont testés avec Kubernetes v1.25+ et utilisent des commandes kubectl qui fonctionnent dans la plupart des environnements.

Inventaire des versions et de l'environnement

Avant de sauvegarder ou de restaurer des ClusterRoles, vous devez comprendre la version de votre cluster, la version de l'API ClusterRole utilisée et l'état actuel de votre configuration RBAC. Les ClusterRoles Kubernetes sont stables depuis la v1.8, mais les versions plus récentes peuvent ajouter des champs ou modifier le comportement. Vérifiez la version de votre cluster :

kubectl version --short

Exemple de sortie :

Client Version: v1.26.0
Kustomize Version: v4.5.7
Server Version: v1.26.0

La version de l'API pour ClusterRole est rbac.authorization.k8s.io/v1 dans les clusters modernes. Vérifiez en consultant la définition de la ressource :

kubectl explain clusterrole

Vous devriez voir API Version: rbac.authorization.k8s.io/v1. Si vous utilisez un cluster plus ancien, la version peut être v1beta1, qui est obsolète et doit être migrée.

Ensuite, faites l'inventaire des ClusterRoles existants et de leurs liaisons. Cela fournit une base de référence pour la sauvegarde et aide à identifier les dépendances :

kubectl get clusterroles --sort-by=.metadata.creationTimestamp

Exemple de sortie (tronquée) :

NAME                                                                   CREATED AT
admin                                                                  2023-01-01T00:00:00Z
cluster-admin                                                           2023-01-01T00:00:00Z
edit                                                                    2023-01-01T00:00:00Z
view                                                                    2023-01-01T00:00:00Z
custom-role                                                             2023-06-15T14:30:00Z

Pour voir les liaisons qui référencent ces rôles :

kubectl get clusterrolebindings -o wide

Si vous utilisez des Roles et RoleBindings dans des espaces de noms, listez-les également :

kubectl get roles --all-namespaces
kubectl get rolebindings --all-namespaces

Cet inventaire est en lecture seule et sans danger. Il vous aide à comprendre ce qui doit être sauvegardé et s'il existe des rôles personnalisés inhabituels.

Prérequis pour la sauvegarde et la restauration :

• kubectl configuré avec des privilèges d'administrateur du cluster (ou au moins les autorisations pour lire et écrire les ClusterRoles et ClusterRoleBindings).
• yq ou jq pour transformer le YAML si nécessaire (facultatif mais recommandé).
• Un emplacement sécurisé pour stocker les fichiers de sauvegarde (dépôt git, bucket S3, etc.).

Vérifiez vos autorisations :

kubectl auth can-i get clusterroles
kubectl auth can-i create clusterroles
kubectl auth can-i delete clusterroles

Chacune doit renvoyer yes. Sinon, vous devez ajuster vos RBAC ou demander à un administrateur.

Chemin de configuration sûr

La sauvegarde des ClusterRoles doit être non destructive et reproductible. La méthode recommandée est d'exporter les définitions YAML vers des fichiers, éventuellement en supprimant les métadonnées (comme resourceVersion et uid), puis de les stocker dans un système de contrôle de version.

Étape 1 : Exporter tous les ClusterRoles

Utilisez la commande suivante pour extraire tous les ClusterRoles dans un seul fichier YAML :

kubectl get clusterroles -o yaml > clusterroles-backup-$(date +%Y%m%d-%H%M%S).yaml

Ce fichier contient un objet List avec toutes les définitions de ClusterRole. Cependant, il inclut des métadonnées spécifiques au cluster telles que creationTimestamp, resourceVersion, uid et selfLink, qui ne sont pas nécessaires pour la restauration et peuvent provoquer des conflits si elles sont appliquées à un nouveau cluster.

Pour créer une sauvegarde plus propre, utilisez une combinaison de kubectl et yq (ou jq) pour supprimer les champs inutiles. Par exemple, avec yq :

kubectl get clusterroles -o json | yq eval 'del(.items[].metadata.creationTimestamp, .items[].metadata.resourceVersion, .items[].metadata.uid, .items[].metadata.selfLink, .items[].metadata.generation)' - > clusterroles-clean.yaml

Si vous préférez sauvegarder chaque ClusterRole individuellement (utile pour le contrôle de version et la restauration sélective), utilisez une boucle :

for role in $(kubectl get clusterroles -o name); do
  role_name=$(echo $role | cut -d'/' -f2)
  kubectl get $role -o yaml | kubectl neat > clusterrole-$role_name.yaml
done

kubectl neat est un plugin qui supprime les éléments superflus des manifests Kubernetes. Vous pouvez l'installer via kubectl krew install neat. Si vous ne l'avez pas, vous pouvez modifier manuellement.

Stockez ces fichiers dans un dépôt git. Effectuez un commit avec un message significatif, par exemple « Sauvegarde des ClusterRoles au 01/06/2024 ».

Étape 2 : Sauvegarder les ClusterRoleBindings

Les ClusterRoles seuls n'accordent pas d'autorisations ; ils doivent être liés à des sujets. Par conséquent, la sauvegarde des ClusterRoleBindings est tout aussi importante :

kubectl get clusterrolebindings -o yaml > clusterrolebindings-backup-$(date +%Y%m%d-%H%M%S).yaml

De même, vous pouvez nettoyer et diviser en fichiers individuels.

Étape 3 : Tester la restauration dans un environnement hors production

Avant de vous fier aux sauvegardes, testez une restauration dans un espace de noms séparé ou un cluster jetable (par exemple, kind, minikube). Pour un ClusterRole unique, vous pouvez l'appliquer à un cluster de test :

kubectl apply -f clusterrole-custom-role.yaml

Vérifiez qu'il est créé correctement :

kubectl get clusterrole custom-role -o yaml

Comparez avec l'original. Assurez-vous que les règles et les règles d'agrégation sont préservées.

Étape 4 : Automatiser les sauvegardes

Pour des sauvegardes récurrentes, configurez un CronJob à l'intérieur du cluster ou utilisez un planificateur externe. Voici un exemple de CronJob qui s'exécute quotidiennement et stocke les sauvegardes dans un PersistentVolume (simplifié pour illustration) :

apiVersion: batch/v1
kind: CronJob
metadata:
  name: clusterrole-backup
  namespace: kube-system
spec:
  schedule: "0 2 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: backup-sa
          containers:
          - name: backup
            image: bitnami/kubectl:latest
            command:
            - /bin/sh
            - -c
            - |
              kubectl get clusterroles -o yaml > /backup/clusterroles-$(date +\%Y\%m\%d).yaml
              kubectl get clusterrolebindings -o yaml > /backup/clusterrolebindings-$(date +\%Y\%m\%d).yaml
            volumeMounts:
            - name: backup-storage
              mountPath: /backup
          restartPolicy: OnFailure
          volumes:
          - name: backup-storage
            persistentVolumeClaim:
              claimName: backup-pvc

Assurez-vous que le compte de service backup-sa dispose des autorisations RBAC appropriées : get et list sur les clusterroles et clusterrolebindings. De plus, le PVC doit avoir une capacité suffisante.

Vérification et diagnostics

Après avoir créé une sauvegarde, vous devez vérifier son intégrité et son exhaustivité. Voici des étapes concrètes :

Vérifier le contenu du fichier de sauvegarde

Validez que le YAML est syntaxiquement correct et contient les ressources attendues.

kubectl apply --dry-run=client -f clusterroles-backup.yaml

S'il y a des erreurs de syntaxe, kubectl les signalera. Comptez également le nombre de ClusterRoles dans la sauvegarde par rapport au cluster en direct :

grep -c '^  name:' clusterroles-backup.yaml  # Ajustez si votre format diffère
kubectl get clusterroles --no-headers | wc -l

Ils doivent correspondre.

Simuler une restauration en mode simulation

Pour des fichiers ClusterRole individuels, utilisez kubectl apply --dry-run=server pour valider auprès du serveur d'API sans réellement créer ou mettre à jour des ressources.

kubectl apply --dry-run=server -f clusterrole-custom-role.yaml

La sortie doit indiquer clusterrole.rbac.authorization.k8s.io/custom-role created (server dry run) ou configured.

Valider les autorisations après restauration

Après avoir restauré un ClusterRole, testez que les autorisations fonctionnent comme prévu. Créez un ServiceAccount de test, liez le ClusterRole à celui-ci et utilisez kubectl auth can-i pour vérifier des actions spécifiques.

Exemple : Supposons que nous ayons restauré un ClusterRole nommé pod-reader qui permet de lire les pods dans tous les espaces de noms. Créez un ServiceAccount de test dans l'espace de noms par défaut :

kubectl create serviceaccount test-sa
kubectl create clusterrolebinding test-sa-pod-reader --clusterrole=pod-reader --serviceaccount=default:test-sa

Ensuite, usurpez l'identité du ServiceAccount pour vérifier les autorisations :

kubectl auth can-i list pods --as=system:serviceaccount:default:test-sa

Si cela renvoie yes, le ClusterRole fonctionne. Pour les autorisations à l'échelle du cluster, testez également :

kubectl auth can-i list nodes --as=system:serviceaccount:default:test-sa

Nettoyez après le test :

kubectl delete clusterrolebinding test-sa-pod-reader
kubectl delete serviceaccount test-sa

Surveiller les comportements inattendus

Après une restauration, surveillez les journaux d'audit et les journaux d'application pour détecter les erreurs d'autorisation. Si l'audit est activé, vérifiez les réponses Forbidden ou Unauthorized liées aux rôles restaurés.

Modes de défaillance et récupération

Malgré une planification minutieuse, les opérations de restauration peuvent échouer. Voici les modes de défaillance courants et comment les récupérer.

1. La restauration échoue en raison d'une ressource existante

Si vous tentez d'appliquer un ClusterRole qui existe déjà avec un contenu différent, kubectl apply peut le mettre à jour. Cependant, si la ressource existante est gérée par un autre contrôleur ou possède des champs immuables, l'application peut échouer.

Scénario : Vous essayez d'appliquer une sauvegarde d'un ClusterRole qui a été supprimé, mais un nouveau portant le même nom a été créé manuellement.

Diagnostic : kubectl apply renvoie une erreur du type Error from server (Conflict): Operation cannot be fulfilled on clusterroles.rbac.authorization.k8s.io "custom-role": the object has been modified; please apply your changes to the latest version and try again.

Récupération : Comparez le ClusterRole existant avec la sauvegarde. Décidez lequel fait autorité. Si vous souhaitez restaurer la sauvegarde, vous pouvez d'abord supprimer l'existant (si c'est sûr) puis appliquer la sauvegarde :

kubectl delete clusterrole custom-role
kubectl apply -f clusterrole-custom-role.yaml

Alternativement, utilisez kubectl replace avec --force après avoir sauvegardé l'état actuel.

2. ClusterRoleBindings manquants après restauration

Si vous restaurez les ClusterRoles mais oubliez les ClusterRoleBindings, les utilisateurs et les comptes de service perdent leurs autorisations. Les symptômes incluent des erreurs 403 Forbidden dans les applications.

Diagnostic : Vérifiez si les liaisons sont manquantes :

kubectl get clusterrolebindings -l backup=missing  # si vous les avez étiquetées

Ou inspectez quels sujets sont liés à un ClusterRole spécifique :

kubectl get clusterrolebindings -o json | jq '.items[] | select(.roleRef.name=="custom-role") | .subjects'

Récupération : Restaurez les ClusterRoleBindings à partir de la sauvegarde en utilisant kubectl apply -f clusterrolebindings-backup.yaml. Assurez-vous que les sujets (utilisateurs, groupes, comptes de service) existent ; sinon, vous devrez peut-être les recréer.

3. Les ClusterRoles agrégés ne fonctionnent pas

Certains ClusterRoles utilisent des règles d'agrégation (par exemple, system:aggregate-to-admin) pour combiner les autorisations de plusieurs rôles. Si les étiquettes sont manquantes sur les rôles sources, l'agrégation peut ne pas fonctionner.

Exemple : Le ClusterRole intégré admin possède une règle d'agrégation qui collecte tous les ClusterRoles avec l'étiquette rbac.authorization.k8s.io/aggregate-to-admin: "true". Si vous restaurez un rôle personnalisé qui a cette étiquette mais que l'étiquette est absente de la sauvegarde, le rôle admin perd ces autorisations.

Diagnostic : Inspectez la aggregationRule du ClusterRole et vérifiez que les rôles correspondants existent et possèdent les bonnes étiquettes :

kubectl get clusterrole admin -o yaml | grep -A 10 aggregationRule
kubectl get clusterroles -l rbac.authorization.k8s.io/aggregate-to-admin=true

Récupération : Ajoutez les étiquettes manquantes aux ClusterRoles concernés :

kubectl label clusterrole my-custom-role rbac.authorization.k8s.io/aggregate-to-admin=true

Vérifiez ensuite que le rôle admin inclut désormais les autorisations en consultant son champ rules.

4. Fichier de sauvegarde corrompu ou incomplet

Si votre fichier de sauvegarde est tronqué ou contient un YAML invalide, la restauration échouera.

Prévention : Vérifiez toujours la taille et le contenu du fichier de sauvegarde. Stockez les sauvegardes dans un stockage fiable avec des sommes de contrôle. Pour les rôles critiques, envisagez de stocker des fichiers YAML individuels.

Récupération : Si des fichiers individuels sont manquants, vous devrez peut-être reconstruire le ClusterRole à partir de la documentation ou d'une réplique en direct si disponible. Dans le pire des cas, vous pouvez utiliser le journal d'audit Kubernetes pour voir la définition originale (si la journalisation d'audit est configurée pour enregistrer les modifications RBAC).

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle pour garantir un processus robuste de sauvegarde et de restauration des ClusterRoles.

• [ ] Inventorier les ClusterRoles et liaisons actuels : Exécutez kubectl get clusterroles,clusterrolebindings et enregistrez la sortie.
• [ ] Identifier les ClusterRoles personnalisés : Notez tous les rôles non par défaut critiques pour vos applications.
• [ ] Créer un plan de sauvegarde : Décidez de la fréquence (quotidienne, hebdomadaire), de l'emplacement de stockage et de la politique de conservation.
• [ ] Exporter tous les ClusterRoles et ClusterRoleBindings vers des fichiers YAML : Utilisez kubectl get -o yaml et nettoyez les métadonnées.
• [ ] Stocker les sauvegardes dans un contrôle de version et/ou un stockage d'objets : Assurez les contrôles d'accès et le chiffrement.
• [ ] Tester la restauration dans un environnement de préproduction : Appliquez les sauvegardes à un cluster de test et vérifiez le fonctionnement.
• [ ] Documenter la procédure de restauration : Incluez les commandes exactes, l'ordre des opérations et les étapes de validation.
• [ ] Mettre en place une surveillance et des alertes pour les changements RBAC : Surveillez les suppressions ou modifications inattendues à l'aide des journaux d'audit Kubernetes ou d'outils de surveillance externes.
• [ ] Réviser et mettre à jour régulièrement les procédures de sauvegarde : Surtout après une mise à niveau de Kubernetes ou un changement des politiques RBAC.
• [ ] Former les membres de l'équipe aux exercices de restauration : Effectuez régulièrement des exercices d'incendie pour vous assurer que chacun sait comment récupérer.

Exemple de runbook de sauvegarde et restauration

Voici un runbook concis pour une restauration rapide d'un seul ClusterRole :

1. Localisez le fichier de sauvegarde du ClusterRole, par exemple clusterrole-my-role.yaml.
2. Vérifiez le contenu du fichier :

   cat clusterrole-my-role.yaml

1. Vérifiez si le ClusterRole existe actuellement :

   kubectl get clusterrole my-role

• S'il n'existe pas, procédez à l'application.
• S'il existe, comparez avec la sauvegarde : kubectl get clusterrole my-role -o yaml > current-my-role.yaml et faites un diff.

1. Appliquez la sauvegarde (si c'est sûr) :

   kubectl apply -f clusterrole-my-role.yaml

1. Vérifiez le ClusterRole restauré :

   kubectl get clusterrole my-role -o yaml

1. Testez les autorisations avec kubectl auth can-i en utilisant un ServiceAccount ou un utilisateur de test.
2. Si la restauration échoue, vérifiez les messages d'erreur et consultez la section des modes de défaillance.
3. Documentez l'incident et mettez à jour la sauvegarde si nécessaire.

Conclusion

La sauvegarde et la restauration des ClusterRoles Kubernetes sont essentielles pour la reprise après sinistre et la continuité opérationnelle. En suivant les pratiques décrites dans ce guide, vous pouvez vous assurer que votre configuration RBAC est toujours récupérable. Commencez par un inventaire complet, mettez en place des sauvegardes automatisées, testez régulièrement les restaurations et documentez tout. N'oubliez pas de vérifier après chaque opération et de garder votre équipe formée. Grâce à ces étapes, vous pouvez minimiser le risque de perdre des contrôles d'accès critiques et maintenir un cluster sécurisé et fonctionnel.

Comme prochaine étape, choisissez une vérification à faible risque : exportez un seul ClusterRole personnalisé, inspectez-le, supprimez-le dans un environnement de test et restaurez-le à partir de la sauvegarde. Cet exercice pratique renforcera votre confiance dans vos procédures de sauvegarde et de restauration.