Exercice 01 : Gérer les variables secrètes et protégées

🎯 Objectifs

À la fin de cet exercice, vous serez capable de :

✅ Créer des variables CI/CD dans Settings → CI/CD → Variables
✅ Distinguer masked (caché dans les logs) et protected (restreint aux branches protégées)
✅ Utiliser $CI_JOB_TOKEN pour appeler l'API GitLab depuis un job
✅ Injecter des secrets sans les écrire dans .gitlab-ci.yml

Durée estimée : 20 minutes

Difficulté : ⭐⭐⭐⭐☆ (Avancé)

Prérequis :

Modules GitLab CI Débutant et Intermédiaire complétés
Accès aux Settings du projet GitLab

📖 Contexte

Ne jamais écrire de secrets (tokens, mots de passe, clés API) directement dans .gitlab-ci.yml. GitLab fournit un gestionnaire de variables CI/CD dans les Settings du projet. Ces variables sont injectées dans les jobs au runtime, sans apparaître dans le code source ni dans les logs (si masked: true).

📋 Énoncé

Configurez des variables secrètes dans GitLab Settings pour simuler une connexion à un service externe. Créez des jobs qui utilisent ces variables de façon sécurisée, en vérifiant que les valeurs ne s'affichent pas dans les logs.

🧭 Déroulement de l'exercice

Tâche 1 : Créer une variable masked dans Settings

Dans GitLab → Settings → CI/CD → Variables, créez une variable API_SECRET_TOKEN avec une valeur de test (ex: s3cr3t-t0k3n-12345). Activez l'option Masked pour qu'elle soit censurée dans les logs.

Indice : Une variable masked doit respecter des contraintes : au moins 8 caractères, uniquement des caractères imprimables ASCII, pas d'espaces. Si la valeur ne respecte pas ces contraintes, l'option Masked sera grisée.

Vérification : La variable apparaît dans la liste avec le symbole du masque. Sa valeur est affichée comme [masked] dans l'interface.

Tâche 2 : Créer une variable protected

Créez une variable PROD_DATABASE_URL avec une valeur simulée (postgres://prod-host:5432/proddb). Activez Protected pour qu'elle soit uniquement disponible sur les branches protégées (ex: main).

Indice : Une variable protected n'est injectée que dans les jobs qui tournent sur des branches ou tags protégés. Sur une branche feature/test, cette variable sera vide. C'est la façon standard de protéger les accès production.

Vérification : Sur une branche feature/test, echo $PROD_DATABASE_URL retourne une chaîne vide.

Tâche 3 : Utiliser les variables dans un job

Créez un job deploy-check qui utilise $API_SECRET_TOKEN dans sa logique (ex: curl -H "Authorization: Bearer $API_SECRET_TOKEN" https://httpbin.org/bearer). Vérifiez que la valeur du token n'apparaît pas en clair dans les logs.

Indice : GitLab remplace automatiquement la valeur d'une variable masked par [masked] dans les logs du job. Même si votre script fait echo $API_SECRET_TOKEN, les logs afficheront [masked].

Vérification : Les logs du job affichent [masked] là où la valeur du token devrait apparaître.

Tâche 4 : Utiliser $CI_JOB_TOKEN

GitLab injecte automatiquement $CI_JOB_TOKEN dans chaque job : c'est un token temporaire qui permet d'appeler l'API GitLab. Utilisez-le pour afficher les informations du projet courant via l'API REST GitLab.

Indice :
`bash
curl --header "JOB-TOKEN: $CI_JOB_TOKEN" \
"https://gitlab.com/api/v4/projects/$CI_PROJECT_ID"
`
$CI_JOB_TOKEN est automatiquement révoqué à la fin du job. Il ne donne accès qu'au projet courant par défaut.

Vérification : L'API retourne un JSON avec le nom et l'ID du projet GitLab.

Tâche 5 : Différence entre masked et protected

Créez un tableau comparatif dans un job explain-variables qui affiche via echo une explication de la différence, et teste les deux types de variables dans le même script.

Indice : Résumé :
- masked : valeur cachée dans les logs (sécurité des logs), disponible sur toutes les branches
- protected : disponible uniquement sur branches/tags protégés (sécurité d'accès), valeur visible dans les logs si non masked
- Combiner masked + protected : le cas le plus sécurisé pour les secrets de production

Vérification : Le job documente les deux comportements et la recommandation de les combiner.

🗂️ Mini-Projet : Pipeline avec gestion des secrets

Checkpoints de validation :

API_SECRET_TOKEN est créée dans Settings avec Masked activé
PROD_DATABASE_URL est protected et indisponible sur les branches non protégées
Les logs de deploy-check affichent [masked] pour le token
$CI_JOB_TOKEN retourne une réponse valide de l'API GitLab
Aucun secret n'est écrit en clair dans .gitlab-ci.yml

Exercice 01 : Gérer les variables secrètes et protégées

🎯 Objectifs

À la fin de cet exercice, vous serez capable de :

✅ Créer des variables CI/CD dans Settings → CI/CD → Variables
✅ Distinguer masked (caché dans les logs) et protected (restreint aux branches protégées)
✅ Utiliser $CI_JOB_TOKEN pour appeler l'API GitLab depuis un job
✅ Injecter des secrets sans les écrire dans .gitlab-ci.yml

Durée estimée : 20 minutes

Difficulté : ⭐⭐⭐⭐☆ (Avancé)

Prérequis :

Modules GitLab CI Débutant et Intermédiaire complétés
Accès aux Settings du projet GitLab

📖 Contexte

📋 Énoncé

🧭 Déroulement de l'exercice

Tâche 1 : Créer une variable masked dans Settings

Indice : Une variable masked doit respecter des contraintes : au moins 8 caractères, uniquement des caractères imprimables ASCII, pas d'espaces. Si la valeur ne respecte pas ces contraintes, l'option Masked sera grisée.

Vérification : La variable apparaît dans la liste avec le symbole du masque. Sa valeur est affichée comme [masked] dans l'interface.

Tâche 2 : Créer une variable protected

Indice : Une variable protected n'est injectée que dans les jobs qui tournent sur des branches ou tags protégés. Sur une branche feature/test, cette variable sera vide. C'est la façon standard de protéger les accès production.

Vérification : Sur une branche feature/test, echo $PROD_DATABASE_URL retourne une chaîne vide.

Tâche 3 : Utiliser les variables dans un job

Indice : GitLab remplace automatiquement la valeur d'une variable masked par [masked] dans les logs du job. Même si votre script fait echo $API_SECRET_TOKEN, les logs afficheront [masked].

Vérification : Les logs du job affichent [masked] là où la valeur du token devrait apparaître.

Tâche 4 : Utiliser $CI_JOB_TOKEN

Indice :
`bash
curl --header "JOB-TOKEN: $CI_JOB_TOKEN" \
"https://gitlab.com/api/v4/projects/$CI_PROJECT_ID"
`
$CI_JOB_TOKEN est automatiquement révoqué à la fin du job. Il ne donne accès qu'au projet courant par défaut.

Vérification : L'API retourne un JSON avec le nom et l'ID du projet GitLab.

Tâche 5 : Différence entre masked et protected

Créez un tableau comparatif dans un job explain-variables qui affiche via echo une explication de la différence, et teste les deux types de variables dans le même script.

Indice : Résumé :
- masked : valeur cachée dans les logs (sécurité des logs), disponible sur toutes les branches
- protected : disponible uniquement sur branches/tags protégés (sécurité d'accès), valeur visible dans les logs si non masked
- Combiner masked + protected : le cas le plus sécurisé pour les secrets de production

Vérification : Le job documente les deux comportements et la recommandation de les combiner.

🗂️ Mini-Projet : Pipeline avec gestion des secrets

Checkpoints de validation :

API_SECRET_TOKEN est créée dans Settings avec Masked activé
PROD_DATABASE_URL est protected et indisponible sur les branches non protégées
Les logs de deploy-check affichent [masked] pour le token
$CI_JOB_TOKEN retourne une réponse valide de l'API GitLab
Aucun secret n'est écrit en clair dans .gitlab-ci.yml