## Introduction L'automatisation CI/CD des comptes de service Kubernetes transforme la gestion manuelle des identités en un pipeline reproductible, mais un pipeline qui applique du YAML sans vérification n'est qu'un script. Ce guide offre aux développeurs, consultants DevOps et équipes plateforme de startups un chemin pratique allant de l'observation de l'état initial au changement vérifié pour les comptes de service, leurs rôles, liaisons et la gestion des jetons. Nous nous concentrons sur la boucle opérationnelle quotidienne : inspecter l'état actuel, appliquer le plus petit changement justifié, vérifier le résultat et savoir comment récupérer. Vous trouverez des commandes kubectl concrètes, des vérifications adaptées aux versions et des exemples de manifestes pour chaque étape. Les exemples supposent un cluster Kubernetes fonctionnel (v1.24 ou ultérieure) et un namespace nommé payments , sauf indication contraire. L'objectif 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 le résultat et documenter la récupération avant qu'un incident ne force la décision. ## Inventaire des versions et de l'environnement Avant de toucher aux comptes de service, enregistrez les versions du plan de contrôle et des API du cluster. De nombreux échecs CI/CD surviennent parce que le client kubectl local, l'API du cluster ou l'apiVersion d'un manifeste ne concordent pas. Commencez par des commandes en lecture seule et capturez la sortie avec des horodatages. ### Vérifier la version du cluster et du client Exécutez kubectl version --short (ou kubectl version sur les clients récents) pour voir les versions du client et du serveur. Par exemple : $ kubectl version --short Client Version: v1.28.2 Server Version: v1.28.1 Si votre pipeline cible un cluster avec une version d'API plus ancienne, le manifeste échouera. Les comptes de service, rôles et liaisons de rôles sont des objets stables v1 . Mais les API de demande de jetons diffèrent : l'API TokenRequest est disponible depuis la v1.20, et les jetons de compte de service hérités basés sur Secret ne sont plus créés automatiquement depuis la v1.24. Utilisez kubectl api-versions | grep authentication pour confirmer les API liées aux jetons. ### Inspecter les comptes de service existants et leurs dépendances Listez les comptes de service dans le namespace cible : kubectl get serviceaccounts -n payments Sortie attendue si seul le compte par défaut existe : NAME SECRETS AGE default 0 45d Si un pipeline CI/CD attend un compte de service spécifique, confirmez son existence avec kubectl get serviceaccount ci-deployer -n payments -o yaml . Le YAML montrera ses annotations, les secrets d'extraction d'images et tout jeton généré automatiquement. Enregistrez les objets RBAC associés : les rôles ( kubectl get roles -n payments ), les liaisons de rôles ( kubectl get rolebindings -n payments ) et les secrets si vous montez encore des jetons hérités ( kubectl get secrets -n payments | grep ci-deployer ). ### Exemple de capture de l'état initial Enregistrez une capture de la configuration d'identité actuelle avant tout changement. C'est votre référence de récupération : mkdir -p /tmp/sa-baseline && cd /tmp/sa-baseline kubectl get serviceaccount ci-deployer -n payments -o yaml > sa-before.yaml kubectl get role ci-deployer-role -n payments -o yaml > role-before.yaml kubectl get rolebinding ci-deployer-binding -n payments -o yaml > binding-before.yaml Utilisez des horodatages dans les noms de fichiers ou un commit git pour figer l'état initial. Si le changement échoue, kubectl apply -f sa-before.yaml restaure le compte de service précédent. Le chemin de récupération est clair avant de modifier quoi que ce soit.
Question rapide 1 sur 2 Quelle est une méthode recommandée pour valider les informations d'identification de compte de service Kubernetes dans votre propre code ? - TokenReview API - OIDC discovery - Analyse manuelle de JWT - Utilisation de kubectl auth can-i
Le passage indique que le projet Kubernetes recommande d'utiliser l'API TokenReview pour valider les informations d'identification de compte de service, car elle invalide les jetons liés à des objets d'API supprimés.
## Chemin de configuration sûre Les comptes de service sont inoffensifs sans rôles ni liaisons, mais une liaison mal configurée peut accorder un accès non intentionnel à un pod. Le chemin sûr consiste à créer ou mettre à jour un objet à la fois, à vérifier son effet, puis à passer à l'étape suivante. Cette section couvre la séquence recommandée pour un compte de service CI/CD typique. ### Étape 1 : Définir le compte de service avec des métadonnées minimales Créez un compte de service pour un pipeline de déploiement qui déploiera des applications dans le namespace payments . Appliquez ce YAML : # sa-ci-deployer.yaml apiVersion: v1 kind: ServiceAccount metadata: name: ci-deployer namespace: payments labels: app.kubernetes.io/name: payments app.kubernetes.io/component: deployer Appliquez et vérifiez le résultat : kubectl apply -f sa-ci-deployer.yaml kubectl get serviceaccount ci-deployer -n payments -o wide Sortie attendue sans secrets (depuis la v1.24) : NAME SECRETS AGE ci-deployer 0 2m Ne définissez pas automountServiceAccountToken: false à moins d'être absolument certain que la charge de travail n'a jamais besoin de s'authentifier auprès de l'API Kubernetes. Pour les tâches CI/CD, le jeton est généralement requis, laissez donc la valeur par défaut true . ### Étape 2 : Créer un rôle avec le moindre privilège Définissez un rôle qui permet au système CI/CD de gérer uniquement les déploiements, services et configmaps dans payments . C'est un rôle limité, pas à l'échelle du cluster. Appliquez ce YAML : # role-ci-deployer.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: ci-deployer-role namespace: payments rules: - apiGroups: ["apps"] resources: ["deployments"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] - apiGroups: [""] resources: ["services", "configmaps"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] Appliquez et inspectez le rôle : kubectl apply -f role-ci-deployer.yaml kubectl describe role ci-deployer-role -n payments La sortie attendue inclut chaque règle avec les ressources et les verbes. Si vous devez autoriser le pipeline à mettre à l'échelle des déploiements, ajoutez "scale" aux verbes pour deployments/scale sous apps . ### Étape 3 : Lier le rôle au compte de service Un rôle est inerte tant qu'il n'est pas lié. Utilisez une RoleBinding pour connecter le compte de service au rôle dans le même namespace : # rolebinding-ci-deployer.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: ci-deployer-binding namespace: payments subjects: - kind: ServiceAccount name: ci-deployer namespace: payments roleRef: kind: Role name: ci-deployer-role apiGroup: rbac.authorization.k8s.io Appliquez la liaison : kubectl apply -f rolebinding-ci-deployer.yaml kubectl get rolebinding ci-deployer-binding -n payments -o wide Vérifiez que le sujet est correct : kubectl describe rolebinding ci-deployer-binding -n payments Recherchez une ligne similaire à : Subjects: Kind Name Namespace ---- ---- --------- ServiceAccount ci-deployer payments Si le sujet montre un namespace ou un type différent, la liaison n'accordera pas les permissions. Corrigez avant de continuer. ## Vérification et diagnostics Après avoir appliqué le rôle et la liaison, vous devez prouver que le compte de service possède réellement les permissions prévues et qu'un pod l'utilisant peut effectuer les actions autorisées. Ne supposez pas le succès à partir de la sortie de kubectl apply . ### Vérifier les permissions avec kubectl auth can-i Utilisez kubectl auth can-i avec --as pour simuler le compte de service. Par exemple, vérifiez si le compte CI/CD peut créer des déploiements dans payments : kubectl auth can-i create deployments --as=system:serviceaccount:payments:ci-deployer -n payments Résultat attendu si le rôle est correct : yes Vérifiez une action interdite, comme la suppression d'un secret : kubectl auth can-i delete secrets --as=system:serviceaccount:payments:ci-deployer -n payments Résultat attendu : no Si vous obtenez yes pour une action non intentionnelle, passez en revue les règles du rôle et les éventuels rôles de cluster liés à ce compte de service. ### Vérifier qu'un pod peut utiliser le jeton du compte de service Créez un pod temporaire qui utilise le compte de service et tente un appel à l'API Kubernetes. Enregistrez le fichier suivant sous pod-test-sa.yaml : apiVersion: v1 kind: Pod metadata: name: sa-token-test namespace: payments spec: serviceAccountName: ci-deployer containers: - name: kubectl image: bitnami/kubectl:latest command: ["sleep", "3600"] restartPolicy: Never Lancez le pod, exécutez une commande à l'intérieur et inspectez le jeton monté : kubectl apply -f pod-test-sa.yaml kubectl wait --for=condition=Ready pod/sa-token-test -n payments --timeout=60s kubectl exec -it sa-token-test -n payments -- sh # dans le conteneur cat /var/run/secrets/kubernetes.io/serviceaccount/token Le jeton doit être une longue chaîne JWT. Tentez un appel à l'API : kubectl exec -it sa-token-test -n payments -- sh -c 'kubectl auth can-i list deployments -n payments --token=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)' Sortie attendue : yes . Un no peut indiquer que le jeton du compte de service n'est pas projeté ou que le rôle ne possède pas la permission. ### Déboguer les problèmes courants - Le pod ne peut pas lister les déploiements mais kubectl auth can-i renvoie oui : Le compte de service du pod n'est peut-être pas correctement spécifié dans la spécification du pod. Vérifiez avec kubectl get pod sa-token-test -n payments -o jsonpath='{.spec.serviceAccountName}' pour confirmer qu'il correspond. - Jeton expiré ou vide : Depuis la v1.24, les comptes de service ne créent plus de secrets à longue durée de vie par défaut. Le jeton projeté est à courte durée de vie et automatiquement renouvelé. Pour le CI/CD, utilisez une spécification de pod qui demande un jeton avec une expiration plus longue via automountServiceAccountToken ou utilisez l'API TokenRequest. Vous pouvez aussi créer manuellement un secret de type kubernetes.io/service-account-token , mais préférez le jeton projeté. - Refus RBAC dans les journaux du cluster : Activez temporairement la journalisation d'audit pour voir pourquoi une requête a été refusée. Pour un cluster EKS, vous pouvez utiliser CloudTrail. Pour un cluster auto-géré, consultez les journaux d'audit de kube-apiserver . Une requête refusée typique montrera l'utilisateur comme system:serviceaccount:payments:ci-deployer et le verbe/ressource manquant.
Question rapide 2 sur 2 Selon la référence, lequel des éléments suivants est un cas d'utilisation suggéré pour les comptes de service ? - Accorder un accès inter-namespaces aux ressources - Stocker des identifiants de base de données pour les applications - Chiffrer le trafic réseau entre les pods - Fournir la résolution DNS pour les services
Le passage cite l'octroi d'un accès inter-namespaces, par exemple permettre à un Pod du namespace 'example' de lire les objets Lease dans 'kube-node-lease', comme cas d'utilisation pour les comptes de service.
## Modes de défaillance et récupération Même avec un YAML correct, l'automatisation CI/CD peut échouer en raison de l'absence du namespace, d'une mauvaise configuration de la liaison ou de problèmes de jetons. Cette section décrit les modes de défaillance courants, comment les détecter et les étapes exactes de récupération. ### Défaillance 1 : Le namespace n'existe pas Si le pipeline applique un manifeste avec namespace: payments mais que le namespace n'a jamais été créé, kubectl renvoie une erreur du type : Error from server (NotFound): namespaces "payments" not found Détection : Le job CI/CD échoue immédiatement à l'application. Dans un système GitOps comme Argo CD, le statut de synchronisation indique Unknown ou Missing pour le namespace. Récupération : Créez le namespace et réappliquez les manifestes : kubectl create namespace payments kubectl apply -f sa-ci-deployer.yaml -f role-ci-deployer.yaml -f rolebinding-ci-deployer.yaml Prévenez ce problème en ajoutant une étape de création du namespace au début du pipeline ou en utilisant un manifeste à l'échelle du cluster qui inclut le namespace. ### Défaillance 2 : La liaison de rôle pointe vers un autre compte de service Une erreur courante consiste à lier un rôle au mauvais sujet. Par exemple, le sujet de la liaison pourrait avoir name: default au lieu de ci-deployer . Le pod démarrera sans erreur mais tout appel API nécessitant des permissions échouera avec 403 Forbidden . Détection : Exécutez kubectl auth can-i pour le compte de service prévu (comme indiqué dans la section Vérification et diagnostics) et vérifiez le sujet de la liaison avec kubectl get rolebinding ci-deployer-binding -n payments -o yaml . Regardez le tableau subjects . Récupération : Corrigez le sujet dans le YAML de la RoleBinding et réappliquez : subjects: - kind: ServiceAccount name: ci-deployer # corrigé de default namespace: payments Puis réappliquez : kubectl apply -f rolebinding-ci-deployer.yaml Vérifiez à nouveau avec kubectl auth can-i . ### Défaillance 3 : Jeton secret hérité manquant après une mise à niveau du cluster Si vous avez effectué une mise à niveau de Kubernetes v1.23 vers v1.24 ou ultérieure, les comptes de service existants peuvent perdre leurs secrets créés automatiquement. Un pipeline qui référence un secret par nom pour un jeton de compte de service échouera à le trouver. Détection : Les journaux du pipeline affichent une erreur comme Secret "ci-deployer-token-abcde" not found . kubectl get serviceaccount ci-deployer -n payments -o yaml ne liste plus le secret sous secrets . Récupération : Utilisez le jeton projeté à la place. Si vous avez absolument besoin d'un jeton à longue durée de vie, créez un secret manuellement et liez-le au compte de service : # sa-token-secret.yaml apiVersion: v1 kind: Secret metadata: name: ci-deployer-token namespace: payments annotations: kubernetes.io/service-account.name: ci-deployer type: kubernetes.io/service-account-token Puis patchez le compte de service pour inclure le secret : kubectl apply -f sa-token-secret.yaml kubectl patch serviceaccount ci-deployer -n payments -p '{"secrets": [{"name": "ci-deployer-token"}]}' Cependant, cette approche comporte des risques de sécurité et est déconseillée. Préférez mettre à jour le système CI/CD pour s'authentifier via le jeton projeté ou utiliser un jeton à courte durée de vie obtenu à partir de l'API TokenRequest. ### Stratégie de retour en arrière Parce que vous avez enregistré les fichiers YAML de l'état initial au début, le retour en arrière est un simple kubectl apply de l'état précédent. Par exemple, pour annuler un changement de rôle : kubectl apply -f /tmp/sa-baseline/role-before.yaml Si le changement a été appliqué via un pipeline, utilisez la fonction de retour en arrière du pipeline ou un commit git de réversion. Réexécutez toujours l'étape de vérification après le retour en arrière pour confirmer que les permissions précédentes sont restaurées. ## Liste de contrôle des opérations Utilisez cette liste de contrôle avant, pendant et après tout changement de compte de service en CI/CD. Elle est conçue pour être collée dans un runbook ou un modèle de ticket et remplie avec des valeurs concrètes. ### Liste de contrôle avant changement kubectl get serviceaccount ci-deployer -n payments -o yaml > /tmp/sa-baseline/sa-before.yaml kubectl get role ci-deployer-role -n payments -o yaml > /tmp/sa-baseline/role-before.yaml kubectl get rolebinding ci-deployer-binding -n payments -o yaml > /tmp/sa-baseline/binding-before.yaml - [ ] Confirmer la version du cluster avec kubectl version --short et noter toute différence d'API. - [ ] Vérifier que le namespace cible existe : kubectl get namespace payments . - [ ] Lister les comptes de service et objets RBAC actuels dans le namespace : kubectl get sa,role,rolebinding -n payments . - [ ] Enregistrer le YAML de l'état initial pour les objets spécifiques que vous allez modifier : - [ ] Confirmer que le changement est limité à un seul namespace ou ensemble d'objets. - [ ] Noter la procédure de récupération : restaurer le YAML de l'état initial. ### Liste de contrôle d'exécution du changement - [ ] Appliquer le manifeste du compte de service : kubectl apply -f sa-ci-deployer.yaml - [ ] Vérifier que le compte de service est créé : kubectl get serviceaccount ci-deployer -n payments - [ ] Appliquer le manifeste du rôle : kubectl apply -f role-ci-deployer.yaml - [ ] Vérifier les règles du rôle : kubectl describe role ci-deployer-role -n payments - [ ] Appliquer la liaison de rôle : kubectl apply -f rolebinding-ci-deployer.yaml - [ ] Vérifier le sujet de la liaison : kubectl get rolebinding ci-deployer-binding -n payments -o yaml - [ ] Tester les permissions avec kubectl auth can-i pour au moins une action autorisée et une action refusée. - [ ] (Optionnel) Lancer un pod temporaire utilisant le compte de service pour tester l'accès basé sur le jeton. ### Liste de contrôle de vérification après changement - [ ] Confirmer que les résultats de kubectl auth can-i correspondent aux attentes pour toutes les actions clés. - [ ] Vérifier qu'aucune permission à l'échelle du cluster non intentionnelle n'a été accordée ( kubectl get clusterrolebinding -o yaml | grep ci-deployer ne doit rien renvoyer). - [ ] Mettre à jour la documentation avec le nouveau nom du compte de service, les permissions et un exemple d'utilisation. - [ ] Étiqueter le changement dans git pour l'auditabilité. - [ ] Si le changement fait partie d'un pipeline CI/CD, exécuter l'étape de vérification propre au pipeline (par exemple, un déploiement de test utilisant le compte de service). ### Exemple de liste de contrôle remplie pour une mise à niveau de pipeline de déploiement Voici un exemple de liste de contrôle complétée pour un changement spécifique : création d'un nouveau compte de service ci-deployer pour le pipeline de déploiement du backend des paiements.
ÉlémentVérificationSortie ou note
Version du clusterkubectl version --shortv1.28.1
Le namespace existekubectl get namespace paymentsActif
État initial enregistrécommit git 4f2a1cFichiers dans /tmp/sa-baseline
SA appliquékubectl apply -f sa-ci-deployer.yamlserviceaccount/ci-deployer created
Rôle appliquékubectl apply -f role-ci-deployer.yamlrole.rbac.authorization.k8s.io/ci-deployer-role created
Liaison appliquéekubectl apply -f rolebinding-ci-deployer.yamlrolebinding.rbac.authorization.k8s.io/ci-deployer-binding created
Action autoriséekubectl auth can-i create deployments --as=... -n paymentsyes
Action refuséekubectl auth can-i delete secrets --as=... -n paymentsno
Test de fumée du pipelineExécuter le job de déploiementDéploiement réussi
## Conclusion L'automatisation CI/CD des comptes de service Kubernetes n'a de valeur que si chaque étape est liée à une version, observable et réversible. Copier une commande sans vérifier les prérequis et la sortie attendue n'est pas une procédure d'exploitation ; c'est un pari. Commencez par une vérification à faible risque : choisissez un compte de service, enregistrez son état actuel avec les commandes de base, exécutez les vérifications documentées, comparez le résultat avec le signal attendu et passez en revue les dépendances telles que les rôles, les liaisons de rôles et les secrets. Un flux de travail technique fiable rend la défaillance visible, protège les valeurs sensibles, limite les changements à la ressource prévue et définit la vérification de récupération avant qu'un incident ne force la décision. Utilisez la liste de contrôle de ce guide comme un document vivant : ajustez-la à mesure que votre cluster évolue et que votre pipeline CI/CD mûrit. Votre prochaine étape consiste à tester ce processus dans un namespace de développement. Créez un compte de service de test, liez un rôle minimal, exécutez les commandes de vérification et cassez intentionnellement une liaison pour vous entraîner à la récupération. Une fois que la boucle vous semble naturelle, appliquez la même rigueur aux changements de production.