OIDC GitHub Actions : authentification sans secrets

OIDC (OpenID Connect) permet à vos workflows de s'authentifier auprès des cloud providers (AWS, Azure, GCP) sans stocker de credentials statiques. Plus de secrets à gérer, plus de rotation à planifier.

Ce que vous allez apprendre

• Comprendre OIDC et pourquoi il remplace les secrets cloud statiques
• Lire le JWT émis par GitHub et ses claims (sub, repository, environment)
• Déclarer id-token: write et brancher l'action cloud officielle
• Restreindre la trust policy par dépôt, branche ou environnement
• Migrer un workflow existant des secrets vers OIDC

Pourquoi OIDC ?

Authentifier un workflow auprès d'un cloud impose historiquement de stocker une clé d'accès dans les secrets. OIDC supprime ce stockage : GitHub prouve l'identité du workflow, le cloud délivre un accès temporaire.

Problèmes des secrets statiques

Une clé d'accès AWS placée dans les secrets GitHub est un credential longue durée qui cumule les risques.

# ❌ Secrets statiques : risques multiples
- name: Configure AWS
  env:
    AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
    AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

Risque	Description
Exposition	Un workflow compromis exfiltre les credentials
Rotation	Obligation de changer régulièrement les clés
Scope	Difficile de limiter les permissions par workflow
Audit	Qui a utilisé ces credentials ? Impossible à tracer

Glissez pour voir

Avantages d'OIDC

OIDC remplace ce credential statique par un token éphémère, négocié à chaque exécution du workflow.

# ✅ OIDC : tokens éphémères, pas de secrets
- uses: aws-actions/configure-aws-credentials@d979d5b3a71173a29b74b5b88418bfda9437d885 # v6.1.1
  with:
    role-to-assume: arn:aws:iam::123456789012:role/github-actions
    aws-region: eu-west-1

Avantage	Description
Éphémère	Token valide quelques minutes seulement
Sans secret	Rien à stocker dans GitHub Secrets
Traçable	Chaque token identifie le workflow, le repo, la branche
Granulaire	Politiques différentes par repo/branche/environment

Glissez pour voir

Comment ça fonctionne

L'échange OIDC se déroule en cinq étapes, sans qu'aucun secret ne transite ni ne soit stocké :

1. Le workflow demande un token OIDC à GitHub
2. GitHub génère un JWT (JSON Web Token) signé
3. Le workflow présente ce JWT au cloud provider
4. Le provider vérifie la signature avec les clés publiques de GitHub
5. Le provider émet des credentials temporaires

Le JWT GitHub Actions

Le token OIDC contient des informations sur le workflow, autant de claims que le cloud provider peut vérifier :

{
  "iss": "https://token.actions.githubusercontent.com",
  "sub": "repo:owner/repo:ref:refs/heads/main",
  "aud": "https://github.com/owner",
  "ref": "refs/heads/main",
  "repository": "owner/repo",
  "repository_owner": "owner",
  "actor": "username",
  "workflow": "Deploy",
  "job_workflow_ref": "owner/repo/.github/workflows/deploy.yml@refs/heads/main",
  "environment": "production"
}

Ces claims permettent de créer des politiques granulaires :

• Autoriser uniquement le repo owner/repo
• Autoriser uniquement la branche main
• Autoriser uniquement l'environment production

Permissions requises

Pour utiliser OIDC, le workflow doit demander la permission id-token: write, sans elle, la demande de token échoue.

permissions:
  id-token: write   # Nécessaire pour OIDC
  contents: read    # Pour checkout

jobs:
  deploy:
    runs-on: ubuntu-24.04
    steps:
      - name: Récupérer le code
        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
        with:
          persist-credentials: false

      - name: Configurer les credentials AWS via OIDC
        uses: aws-actions/configure-aws-credentials@d979d5b3a71173a29b74b5b88418bfda9437d885 # v6.1.1
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-actions
          aws-region: eu-west-1

Configurer OIDC par cloud

La configuration côté cloud, créer le rôle ou l'identité fédérée, diffère selon le provider. Le guide OIDC pour AWS, Azure et GCP détaille chaque cas ; voici la vue d'ensemble.

Résumé par provider

Chaque cloud a son action officielle et son propre mécanisme de confiance.

Provider	Action officielle	Trust policy
AWS	aws-actions/configure-aws-credentials	IAM Role avec OIDC
Azure	azure/login	App Registration + Federated credentials
GCP	google-github-actions/auth	Workload Identity Federation

Glissez pour voir

Bonnes pratiques

OIDC supprime les secrets, mais la sécurité réelle dépend de la trust policy côté cloud. Quatre réflexes la verrouillent.

1. Restreindre par branche et environment

La condition sub de la trust policy limite quel dépôt, branche ou environnement peut assumer le rôle.

{
  "Condition": {
    "StringEquals": {
      "token.actions.githubusercontent.com:sub": "repo:owner/repo:environment:production"
    }
  }
}

2. Utiliser les environments GitHub

Déclarer un environment GitHub ajoute le claim correspondant au JWT, et permet d'exiger une approbation manuelle avant le déploiement.

jobs:
  deploy:
    environment: production  # Le claim 'environment' sera dans le JWT
    runs-on: ubuntu-24.04
    permissions:
      id-token: write
    steps:
      - name: Configurer les credentials AWS via OIDC
        uses: aws-actions/configure-aws-credentials@d979d5b3a71173a29b74b5b88418bfda9437d885 # v6.1.1
        with:
          role-to-assume: ${{ vars.AWS_ROLE_ARN }}

3. Permissions minimales sur le rôle cloud

Le rôle assumé applique le moindre privilège : uniquement les actions cloud strictement nécessaires.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject"
      ],
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

4. Auditer les utilisations

Chaque assume-role est journalisé côté cloud provider :

• AWS : CloudTrail
• Azure : Activity Log
• GCP : Cloud Audit Logs

Cas d'usage

Deux scénarios fréquents illustrent OIDC de bout en bout : publier un site statique sur S3 et pousser une image Docker vers ECR.

Déploiement S3

Synchroniser un dossier dist/ vers un bucket S3, sans aucune clé AWS stockée.

jobs:
  deploy:
    runs-on: ubuntu-24.04
    permissions:
      id-token: write
      contents: read
    steps:
      - name: Récupérer le code
        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
        with:
          persist-credentials: false

      - name: Configurer les credentials AWS via OIDC
        uses: aws-actions/configure-aws-credentials@d979d5b3a71173a29b74b5b88418bfda9437d885 # v6.1.1
        with:
          role-to-assume: arn:aws:iam::123456789012:role/deploy-s3
          aws-region: eu-west-1

      - name: Synchroniser le site vers S3
        run: aws s3 sync ./dist s3://my-website-bucket

Push image vers ECR

Construire une image Docker et la pousser vers Amazon ECR, l'authentification au registre passe elle aussi par OIDC.

jobs:
  push:
    runs-on: ubuntu-24.04
    permissions:
      id-token: write
      contents: read
    steps:
      - name: Récupérer le code
        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
        with:
          persist-credentials: false

      - name: Configurer les credentials AWS via OIDC
        uses: aws-actions/configure-aws-credentials@d979d5b3a71173a29b74b5b88418bfda9437d885 # v6.1.1
        with:
          role-to-assume: arn:aws:iam::123456789012:role/push-ecr
          aws-region: eu-west-1

      - name: Se connecter à Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@fa648b43de3d4d023bcb3f89ed6940096949c419 # v2.1.5

      - name: Builder et pousser l'image
        env:
          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
        run: |
          docker build -t "$ECR_REGISTRY/app:$GITHUB_SHA" .
          docker push "$ECR_REGISTRY/app:$GITHUB_SHA"

Migration depuis les secrets

Basculer un workflow existant vers OIDC se fait en cinq étapes, sans interruption de service :

1. Créer le rôle cloud avec une trust policy OIDC
2. Ajouter permissions: id-token: write au workflow
3. Remplacer les secrets par l'action OIDC
4. Tester sur une branche dédiée
5. Supprimer les anciens secrets statiques

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• OIDC remplace les credentials cloud statiques par des tokens éphémères négociés à chaque exécution.
• Le workflow doit déclarer la permission id-token: write pour demander un token OIDC.
• GitHub émet un JWT signé dont les claims (repository, ref, environment) pilotent la trust policy côté cloud.
• La sécurité réelle se joue dans la trust policy : restreignez par dépôt, branche ou environnement.
• Le rôle cloud assumé applique le moindre privilège, uniquement les actions strictement nécessaires.

Prochaines étapes

OIDC pour AWS, Azure et GCP Configurer le rôle ou l'identité fédérée chez chaque provider

Permissions GITHUB_TOKEN Le rôle de id-token: write parmi les permissions du workflow

Variables et secrets Gérer les secrets restants une fois OIDC en place

Sécuriser GitHub Actions Le guide complet de durcissement des workflows

Pour la référence complète, consultez la documentation officielle sur OIDC.

×

📖 Voir la documentation →