CI/CD : déployer sans distribuer de credentials

Le point douloureux de tout pipeline de déploiement Kubernetes : comment la CI s’authentifie-t-elle ? Les kubeconfigs personnels expirent et engagent votre identité ; les tokens bricolés traînent dans des variables. Kontainers fournit deux mécanismes propres, chacun pour un usage précis :

Besoin	Mécanisme	Credential à gérer
Faire tourner un outil in-cluster qui pilote le namespace (runner GitLab, opérateur maison…)	ServiceAccount bs-namespace-member	aucun
Déployer depuis un pipeline (jobs CI — que la CI soit in-cluster ou externe)	Kubeconfig permanent	un secret CI, non expirant

Le ServiceAccount bs-namespace-member

Chaque namespace contient ce ServiceAccount pré-provisionné. Un pod qui tourne avec (serviceAccountName: bs-namespace-member) est automatiquement authentifié auprès du cluster, avec des droits couvrant la gestion du namespace (le détail, colonne SA).

Son usage prévu : l’outillage qui a réellement besoin de l’API — typiquement le gestionnaire d’un runner GitLab in-cluster, qui crée et supervise les pods de jobs.

Moindre privilège : ne montez pas ce SA dans les pods de jobs

Un job de build ou de test n’a pas besoin de parler à l’API Kubernetes — ne lui donnez pas ce pouvoir. Laissez les pods de jobs sous le ServiceAccount default du namespace (aucun droit API) : seul l’outil qui orchestre — le runner — porte bs-namespace-member. Vos jobs de déploiement, eux, s’authentifient explicitement avec un kubeconfig permanent (ci-dessous) : le droit est donné au pipeline qui en a besoin, pas à tous les jobs du projet.

Le kubeconfig permanent

Testé sur la plateforme. Pour vos pipelines de déploiement, créez un BlackSwiftPermanentKubeconfig :

apiVersion: blackswift.cloud/v1alpha1
kind: BlackSwiftPermanentKubeconfig
metadata:
  name: cicd

kubectl apply -f permanent-kubeconfig.yaml -n <namespace>

En quelques secondes, deux Secrets apparaissent dans votre namespace :

kubectl get secrets -n <namespace> | grep bspkcfg
# bspkcfg-cicd-kubeconfig   Opaque                                1
# bspkcfg-cicd-token        kubernetes.io/service-account-token   3

Récupérez le kubeconfig :

kubectl get secret bspkcfg-cicd-kubeconfig -n <namespace> \
  -o jsonpath='{.data.kubeconfig}' | base64 -d > ci-kubeconfig.yaml

Ce kubeconfig :

• porte les droits du ServiceAccount bs-namespace-member de votre namespace, sans jamais expirer — contrairement au kubeconfig téléchargé depuis Rancher ;
• parle directement à l’API du cluster (api.k-bdkbsh.blackswift.cloud) — il fonctionne même pendant une maintenance de la console Rancher ;
• fonctionne depuis n’importe où : jobs d’un runner in-cluster, gitlab.com, GitHub Actions, votre poste.

L’utiliser dans un pipeline

Stockez le contenu du fichier dans une variable CI masquée et protégée (GitLab : Settings › CI/CD › Variables, type File), puis :

.gitlab-ci.yml

deploy:
  stage: deploy
  image: bitnami/kubectl:latest
  script:
    - export KUBECONFIG=$KUBE_CONFIG_FILE     # variable CI de type File
    - kubectl set image deploy/mon-app app=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
    - kubectl rollout status deploy/mon-app --timeout=120s
  rules:
    - if: $CI_COMMIT_TAG

Seul ce job de déploiement reçoit la variable — vos jobs de build et de test n’ont aucun accès au cluster.

Cycle de vie et bonnes pratiques

• Un kubeconfig par usage (cicd, monitoring-externe…) : les CR sont multiples et nominatives, la colonne LAST USED de kubectl get blackswiftpermanentkubeconfigs vous dit lesquels servent encore ;
• Révocation immédiate : supprimez la CR, les Secrets (et le token) partent avec elle :

  kubectl delete blackswiftpermanentkubeconfig cicd -n <namespace>

• Périmètre : le kubeconfig n’agit que dans son namespace. Pour déployer sur dev et prod depuis un même pipeline, créez-en un par namespace — deux variables CI, deux périmètres étanches ;
• Ne le commitez jamais : c’est un credential non expirant. Variable CI protégée uniquement.