Secrets et configuration GitHub Actions

Ce guide est fondamental

La gestion des secrets est l’un des aspects les plus critiques de la sécurité CI/CD. Ce que vous apprenez ici s’applique à tous les systèmes d’intégration continue, pas seulement GitHub Actions.

Imaginez que vous publiez votre application sur Docker Hub. Votre workflow a besoin de se connecter avec un mot de passe. Où le mettez-vous ?

Vos workflows ont souvent besoin d’informations sensibles :

• Un token pour déployer
• Un mot de passe de base de données
• Une clé API pour un service externe
• Des identifiants cloud (AWS, GCP, Azure)

Ces informations ne doivent jamais être dans votre code. C’est la règle n°1 de la sécurité GitHub Actions.

Pourquoi ne pas mettre les secrets dans le code ?

L’erreur classique du débutant

# ❌ JAMAIS FAIRE ÇA — même "pour tester vite fait"
- run: docker login -u admin -p "MonMotDePasse123"

Ce qui se passe vraiment

Vous vous dites peut-être : « C’est juste mon repo perso, personne ne regarde. » Voici la réalité :

Ce que vous pensez	Ce qui se passe vraiment
« Mon repo est privé »	Les collaborateurs et les outils CI voient tout
« Je supprimerai après »	Le mot de passe reste dans l’historique Git pour toujours
« Personne ne cherche ça »	Des bots scannent GitHub 24h/24 et trouvent les secrets en quelques minutes
« Je peux faire un fork privé »	Si quelqu’un fork votre repo, il a votre mot de passe

Analogie : la clé sous le paillasson

Mettre un secret dans le code, c’est comme cacher sa clé de maison sous le paillasson. Tout le monde sait où chercher.

Des attaques réelles

En 2023, des chercheurs en sécurité ont trouvé plus de 12 000 clés AWS valides exposées sur GitHub. La plupart appartenaient à des développeurs qui ont fait l’erreur « juste pour tester ».

Pour en savoir plus sur la détection de secrets, consultez les guides sur Gitleaks et TruffleHog.

La solution : les secrets GitHub

Qu’est-ce qu’un secret GitHub ?

Un secret GitHub, c’est une variable spéciale stockée dans un coffre-fort chiffré. Pensez-y comme un gestionnaire de mots de passe intégré à GitHub, spécialement conçu pour vos workflows.

Comment ça protège vos données ?

GitHub applique plusieurs couches de protection :

Protection	Ce que ça fait
Chiffrement au repos	Les secrets sont chiffrés avec une clé unique par dépôt
Masquage automatique	Si un secret apparaît dans les logs, il est remplacé par ***
Isolation	Un workflow ne peut pas lire les secrets d’un autre dépôt
Audit	GitHub journalise qui accède aux secrets et quand

Le flux : du coffre-fort au workflow

Voici ce qui se passe quand votre workflow utilise un secret :

1. Vous créez le secret dans Settings → Secrets and variables → Actions

2. GitHub le chiffre et le stocke dans son coffre-fort

3. Votre workflow démarre et demande le secret

4. GitHub déchiffre et injecte la valeur dans la variable d’environnement

5. Votre script l’utilise sans jamais voir la valeur en clair dans les logs

Exemple concret

# Votre workflow
- run: docker login -p ${{ secrets.DOCKER_TOKEN }}

# Ce qui apparaît dans les logs GitHub
docker login -p ***

Même si votre script fait un echo du secret par erreur, GitHub le masque.

Comment créer un secret

1. Allez sur votre repository GitHub

2. Cliquez sur Settings (onglet en haut, visible uniquement si vous avez les droits admin)

3. Dans le menu à gauche : Secrets and variables → Actions

4. Cliquez sur New repository secret

5. Remplissez les champs :

   • Name : le nom de votre secret (ex: DOCKER_TOKEN)
   • Secret : la valeur (le mot de passe, la clé API…)

6. Cliquez sur Add secret

Vous ne reverrez jamais la valeur

Une fois le secret créé, GitHub ne vous montrera plus jamais sa valeur. Vous pouvez seulement le mettre à jour ou le supprimer. Si vous perdez la valeur originale, vous devrez en générer une nouvelle.

Comment utiliser un secret

Dans votre workflow, utilisez la syntaxe ${{ secrets.NOM_DU_SECRET }} :

jobs:
  deploy:
    runs-on: ubuntu-24.04
    steps:
      - name: Se connecter à Docker Hub
        run: |
          echo "${{ secrets.DOCKER_TOKEN }}" | docker login -u ${{ secrets.DOCKER_USER }} --password-stdin

Les pièges à éviter

Ne jamais faire echo d'un secret

# ❌ DANGEREUX - le secret pourrait apparaître dans les logs
- run: echo "Mon token est ${{ secrets.TOKEN }}"

# ✅ CORRECT - utiliser le secret directement
- run: docker login -p ${{ secrets.TOKEN }}

Le masquage n'est pas parfait

GitHub masque les secrets tels quels, mais pas leurs dérivés. Si votre secret est password123 et que votre script affiche password123!, le ! apparaîtra en clair.

Pire : si vous encodez un secret en base64, GitHub ne le reconnaîtra pas et l’affichera en clair dans les logs.

# ❌ Le secret encodé apparaît en clair !
- run: echo ${{ secrets.TOKEN }} | base64

Secrets et forks : une question de sécurité

Par défaut, les secrets ne sont pas disponibles dans les workflows déclenchés par des forks. C’est une protection importante !

Pourquoi ? Imaginez qu’un attaquant fork votre repo et modifie le workflow pour afficher tous les secrets. S’ils étaient disponibles, il les verrait.

Contexte	Secrets disponibles ?
Push sur votre branche	Oui
PR depuis une branche du repo	Oui
PR depuis un fork	Non (par défaut)
Workflow manuel déclenché par un collaborateur	Oui

Pour en savoir plus sur la sécurité des PRs, consultez Sécurité : les bases.

Secrets vs Variables : quelle différence ?

GitHub propose deux mécanismes de configuration. Choisir le bon est important pour la sécurité.

Le tableau de décision

Question	Secret	Variable
Est-ce confidentiel ?	Oui (mots de passe, tokens, clés)	Non (versions, URLs publiques)
Visible dans les logs ?	Non (masqué ***)	Oui (en clair)
Modifiable sans redéployer ?	Oui	Oui
Peut-on voir la valeur actuelle ?	Non (jamais)	Oui

Exemples concrets

Valeur	Type	Pourquoi
Token Docker Hub	Secret	Permet de publier des images
Mot de passe BDD	Secret	Accès aux données
Clé API Stripe	Secret	Accès au paiement
Version de Node	Variable	Pas sensible, utile de voir dans les logs
URL de staging	Variable	Publique de toute façon
Nom du cluster K8s	Variable	Information technique, pas un secret

La règle simple

Si quelqu’un qui voit cette valeur peut causer des dommages (accéder à des services, voler des données, dépenser de l’argent), c’est un secret. Sinon, c’est une variable.

Créer et utiliser une variable

Même endroit que les secrets, mais onglet Variables :

Repository → Settings → Secrets and variables → Actions → Variables

jobs:
  build:
    runs-on: ubuntu-24.04
    steps:
      - name: Afficher la configuration
        run: |
          echo "Node version: ${{ vars.NODE_VERSION }}"
          echo "Environment: ${{ vars.ENVIRONMENT }}"

Les 3 niveaux de configuration

Vous pouvez définir secrets et variables à trois niveaux. C’est comme des variables d’environnement qui se superposent : le plus spécifique gagne.

Vue d’ensemble

Niveau	Portée	Cas d’usage
Organisation	Tous les repos de l’org	Token Docker Hub partagé par l’équipe
Repository	Un seul repo	Clé de déploiement spécifique au projet
Environment	Un environnement du repo	Credentials de la base de prod vs staging

Priorité de résolution

Si un secret existe à plusieurs niveaux, GitHub utilise le plus spécifique :

Environment > Repository > Organization

Exemple : si DATABASE_URL existe au niveau organisation et au niveau environnement, c’est la valeur de l’environnement qui sera utilisée.

Les environments : sécurité par isolation

Les environments (environnements) sont un mécanisme puissant pour isoler vos secrets par contexte de déploiement.

Pourquoi c’est important pour la sécurité ?

• Les secrets de production ne sont jamais exposés au code de développement
• Vous pouvez exiger une approbation manuelle avant d’accéder aux secrets de prod
• Un workflow compromis en staging ne peut pas accéder à la prod

Exemple : même nom, valeurs différentes

jobs:
  deploy-staging:
    runs-on: ubuntu-24.04
    environment: staging  # Utilise les secrets de "staging"
    steps:
      - run: deploy --url ${{ secrets.DATABASE_URL }}
      # → DATABASE_URL = postgres://staging.db.example.com

  deploy-prod:
    runs-on: ubuntu-24.04
    environment: production  # Utilise les secrets de "production"
    steps:
      - run: deploy --url ${{ secrets.DATABASE_URL }}
      # → DATABASE_URL = postgres://prod.db.example.com

Même nom de secret (DATABASE_URL), mais valeurs différentes selon l’environnement.

Protection des environments

Pour les environnements sensibles (production), ajoutez des protections :

Protection	Ce que ça fait
Required reviewers	Un humain doit approuver le déploiement
Wait timer	Délai obligatoire avant déploiement (ex: 30 min)
Deployment branches	Seules certaines branches peuvent déployer

Pour configurer : Repository → Settings → Environments → protection rules.

Bonnes pratiques de sécurité

1. Nommez clairement vos secrets

Un bon nom permet de comprendre ce que c’est et à quoi ça sert sans ouvrir la documentation.

Bon nom	Mauvais nom	Pourquoi
DOCKER_HUB_TOKEN	TOKEN	On sait que c’est pour Docker Hub
AWS_ACCESS_KEY_ID	KEY	Convention AWS reconnue
PROD_DATABASE_PASSWORD	PWD	On sait que c’est pour la prod
STAGING_API_KEY	SECRET	On sait l’environnement et le service

2. Documentez vos secrets

Dans votre README ou CONTRIBUTING, listez les secrets nécessaires sans révéler leur valeur :

## Secrets requis

| Secret | Description | Où le trouver |
|--------|-------------|---------------|
| DOCKER_TOKEN | Token Docker Hub | hub.docker.com → Account Settings → Security |
| NPM_TOKEN | Token npm automation | npmjs.com → Access Tokens → Generate |
| AWS_ACCESS_KEY_ID | Clé IAM (deployer) | Console AWS → IAM → Users → Security credentials |

3. Appliquez le principe de moindre privilège

Chaque token doit avoir uniquement les permissions nécessaires. Si un token est compromis, les dégâts doivent être limités.

Service	Permission minimale	Pas ça
Docker Hub	Read, Write (pas Delete)	Admin
npm	Automation (publish only)	Publish + manage packages
GitHub PAT	repo scope uniquement	Toutes les permissions
AWS	Policy IAM restreinte	AdministratorAccess

Voir le guide complet sur le principe de moindre privilège.

4. Renouvelez régulièrement vos secrets

Les tokens ont souvent une durée de vie limitée, et c’est une bonne chose. Planifiez leur renouvellement :

• Tokens courts (90 jours) : plus sécurisés mais plus de maintenance
• Tokens longs (1 an) : moins de maintenance mais plus risqués si compromis

Alternative moderne : OIDC

Pour AWS, GCP et Azure, vous pouvez utiliser OIDC (OpenID Connect) à la place des clés statiques. GitHub génère un token temporaire à chaque exécution, pas de secret à stocker ni à renouveler.

5. Auditez l’accès à vos secrets

Qui a accès à vos secrets ? Révisez régulièrement :

• Les collaborateurs du repo (Settings → Collaborators)
• Les équipes avec accès (pour les organisations)
• Les GitHub Apps installées (Settings → GitHub Apps)

Erreurs courantes et dépannage

”Secret not found”

Votre workflow échoue avec une erreur indiquant que le secret n’existe pas ?

Causes possibles :

• Le nom est mal orthographié (attention aux majuscules/minuscules)
• Le secret est défini pour un autre environment
• Vous êtes dans un workflow déclenché par un fork (secrets non disponibles)
• Le secret est au niveau organisation mais le repo n’y a pas accès

Le secret apparaît en clair dans les logs

Si vous voyez votre secret en clair :

1. Révoquez immédiatement le token/mot de passe compromis
2. Vérifiez si vous avez encodé ou transformé le secret (base64, JSON…)
3. Créez un nouveau secret avec une nouvelle valeur

”Resource not accessible by integration”

Cette erreur signifie que le GITHUB_TOKEN n’a pas les permissions nécessaires. Ce n’est pas un problème de secrets, mais de permissions.

Ce qu’il faut retenir

Question	Réponse
Où stocker les mots de passe ?	Dans les Secrets GitHub
Où stocker la config publique ?	Dans les Variables GitHub
Comment y accéder ?	${{ secrets.NOM }} ou ${{ vars.NOM }}
Où les créer ?	Settings → Secrets and variables → Actions
Comment isoler par environnement ?	Utiliser les Environments
Comment sécuriser la prod ?	Required reviewers + wait timer

Contrôle des connaissances

Testez vos connaissances sur la gestion des secrets et la configuration.

Pourquoi ce contrôle ?

Cet contrôle va vous permettre de valider vos connaissances sur le sujet abordé dans le guide. Il comporte des QCM, des questions vrai/faux et des réponses ouvertes à un mot.

🕒 Le chronomètre commence dès que vous cliquez sur Démarrer le test. Vous devrez terminer l’examen avant la fin du temps imparti.

🎯 Pour réussir, vous devez obtenir au moins 70% de bonnes réponses.

💡 Je ne fournis pas directement les réponses aux questions. Cependant, si certaines sont complexes, des pistes d’explication pourront être proposées dans le guide ou après l’examen.

Bonne chance ! 🚀

Démarrer le test

Temps restant :

La suite

Vous avez maintenant les bases pour commencer à écrire vos premiers workflows. Ah non, on rajoute une petite couche avec la marketplace.