Variables et secrets
Les variables CI/CD GitLab sont le mecanisme d'injection de configuration et de secrets dans les pipelines. Elles peuvent etre definies a plusieurs niveaux, masquees, protegees, et issues de sources externes (HashiCorp Vault, Azure Key Vault, AWS Secrets Manager).
Niveaux de definition
- Instance : variables disponibles dans tous les projets de l'instance (admin uniquement)
- Groupe : disponibles dans tous les projets du groupe et sous-groupes
- Projet : disponibles dans les pipelines du projet
- .gitlab-ci.yml : variables declarees dans le fichier, visibles dans le code
L'ordre de priorite (du plus fort au plus faible) : job > .gitlab-ci.yml global > projet > groupe > instance. Une variable de job ecrase une variable de groupe.
Types de variables
- Variable : valeur texte, injectee comme variable d'environnement
- File : contenu ecrit dans un fichier temporaire, la variable contient le chemin du fichier. Utile pour les cles SSH, les certificats, les fichiers kubeconfig.
Masquage et protection
Masquee : la valeur n'apparait pas dans les logs de job. Contrainte : la valeur doit respecter des regles de format (pas de saut de ligne, longueur minimum). Si le job imprime accidentellement la variable, GitLab la remplace par [MASKED].
Protegee : la variable n'est disponible que dans les pipelines declenches depuis des branches ou tags proteges. Empeche qu'un developpeur exfiltre les secrets via une branche feature.
Les deux attributs sont independants et cumulables. Un secret de production devrait etre a la fois masque et protege.
Secrets externes
GitLab supporte nativement l'integration avec HashiCorp Vault (JWT auth), Azure Key Vault et AWS Secrets Manager. Le job s'authentifie via JWT OIDC et recupere les secrets au moment de l'execution, sans que ceux-ci soient stockes dans GitLab :
job:
secrets:
DATABASE_PASSWORD:
vault: production/db/password@ops # path@engineCette approche est preferable pour les secrets hautement sensibles : pas de stockage dans GitLab, rotation transparente, audit centralise dans Vault.
Variables dotenv
Un job peut exporter des variables dynamiques vers les jobs suivants via un fichier .env declare comme artefact dotenv :
prepare:
script:
- echo "VERSION=1.2.3" > build.env
artifacts:
reports:
dotenv: build.env
deploy:
needs: [prepare]
script:
- echo "Deploying version $VERSION"