---
title: "CI/CD : déployer sans distribuer de credentials"
description: "Les deux mécanismes d'authentification CI/CD de Kontainers : le ServiceAccount bs-namespace-member pour l'outillage in-cluster, et les kubeconfigs permanents pour les pipelines."
source_url:
  html: https://docs.blackswift.cloud/operer/ci-cd-avec-le-serviceaccount/
  md: https://docs.blackswift.cloud/operer/ci-cd-avec-le-serviceaccount.md
---

# CI/CD : déployer sans distribuer de credentials

> Les deux mécanismes d'authentification CI/CD de Kontainers : le ServiceAccount bs-namespace-member pour l'outillage in-cluster, et les kubeconfigs permanents pour les pipelines.

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](https://docs.blackswift.cloud/reference/permissions-et-rbac.md)).

Son usage prévu : **l'outillage qui a réellement besoin de l'API** — typiquement
le gestionnaire d'un [runner GitLab in-cluster](https://docs.blackswift.cloud/exemples/gitlab-runner.md), qui
crée et supervise les pods de jobs.

:::caution[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` :

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

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

En quelques secondes, deux Secrets apparaissent dans votre namespace :

```bash
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 :

```bash
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 :

```yaml
# .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 :
  ```bash
  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.