OIDC GitHub Actions : AWS, Azure, GCP

La configuration OIDC se fait à deux endroits : côté cloud provider, où l'on crée le lien de confiance, et côté workflow, qui demande le token. Ce guide détaille les deux pour AWS, Azure et GCP.

Ce que vous allez apprendre

• Créer le provider d'identité OIDC chez AWS, Azure et GCP
• Configurer le rôle ou l'identité fédérée qui fait confiance à GitHub
• Restreindre la trust policy au bon dépôt et à la bonne branche
• Écrire le workflow qui demande et utilise le token
• Choisir entre console, CLI et Terraform pour chaque étape

Si le fonctionnement d'OIDC ne vous est pas familier, commencez par OIDC : authentification sans secrets.

AWS

Sur AWS, OIDC repose sur un IAM OIDC Provider et un rôle IAM dont la trust policy fait confiance aux tokens GitHub. La mise en place tient en quatre étapes.

Étape 1 : Créer l'Identity Provider

Le provider d'identité déclare GitHub comme émetteur de confiance auprès d'IAM.

Console AWS

1. Allez dans IAM > Identity providers > Add provider
2. Sélectionnez OpenID Connect
3. Provider URL : https://token.actions.githubusercontent.com
4. Audience : sts.amazonaws.com
5. Cliquez Add provider

Terraform

resource "aws_iam_openid_connect_provider" "github" {
  url             = "https://token.actions.githubusercontent.com"
  client_id_list  = ["sts.amazonaws.com"]
  thumbprint_list = ["6938fd4d98bab03faadb97b34396831e3780aea1"]
}

AWS CLI

aws iam create-open-id-connect-provider \
  --url https://token.actions.githubusercontent.com \
  --client-id-list sts.amazonaws.com \
  --thumbprint-list 6938fd4d98bab03faadb97b34396831e3780aea1

Étape 2 : Créer le rôle IAM

Le rôle IAM porte les permissions accordées au workflow et accepte d'être assumé via Web Identity.

Console AWS

1. Allez dans IAM > Roles > Create role
2. Sélectionnez Web identity
3. Identity provider : token.actions.githubusercontent.com
4. Audience : sts.amazonaws.com
5. Ajoutez les permissions nécessaires
6. Nommez le rôle (ex: github-actions-deploy)

Terraform

data "aws_iam_policy_document" "github_actions_trust" {
  statement {
    actions = ["sts:AssumeRoleWithWebIdentity"]
    effect  = "Allow"

    principals {
      type        = "Federated"
      identifiers = [aws_iam_openid_connect_provider.github.arn]
    }

    condition {
      test     = "StringEquals"
      variable = "token.actions.githubusercontent.com:aud"
      values   = ["sts.amazonaws.com"]
    }

    condition {
      test     = "StringLike"
      variable = "token.actions.githubusercontent.com:sub"
      values   = ["repo:owner/repo:*"]
    }
  }
}

resource "aws_iam_role" "github_actions" {
  name               = "github-actions-deploy"
  assume_role_policy = data.aws_iam_policy_document.github_actions_trust.json
}

resource "aws_iam_role_policy_attachment" "s3_access" {
  role = aws_iam_role.github_actions.name
  # Exemple : restreignez le périmètre à une policy dédiée en production
  policy_arn = "arn:aws:iam::aws:policy/AmazonS3FullAccess"
}

Étape 3 : Configurer la trust policy

La trust policy restreint qui peut assumer le rôle. La condition sub est la plus importante : elle borne le dépôt, la branche ou l'environnement.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:owner/repo:ref:refs/heads/main"
        }
      }
    }
  ]
}

Patterns de restriction :

Pattern	Autorise
repo:owner/repo:*	Toutes les branches/PRs
repo:owner/repo:ref:refs/heads/main	Branche main uniquement
repo:owner/repo:environment:production	Environment production
repo:owner/*:*	Tous les repos de l'org

Glissez pour voir

Étape 4 : Workflow GitHub

Côté GitHub, le workflow demande le token avec id-token: write et le présente à AWS via l'action officielle.

name: Deploy to AWS

on:
  push:
    branches: [main]

permissions:
  id-token: write
  contents: read

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-deploy
          aws-region: eu-west-1

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

Azure

Sur Azure, OIDC passe par une App Registration et des federated credentials qui lient un sujet GitHub précis à l'application.

Étape 1 : Créer l'App Registration

L'App Registration est l'identité applicative qu'assumera le workflow.

Portal Azure

1. Allez dans Azure Active Directory > App registrations > New registration
2. Nom : github-actions
3. Cliquez Register
4. Notez l'Application (client) ID et le Directory (tenant) ID

Azure CLI

az ad app create --display-name github-actions
# Notez l'appId retourné

Étape 2 : Ajouter les Federated credentials

Les federated credentials déclarent quel sujet GitHub (dépôt, branche, environnement) peut s'authentifier comme cette application.

Portal Azure

1. Dans l'App Registration, allez dans Certificates & secrets
2. Onglet Federated credentials > Add credential
3. Scenario : GitHub Actions deploying Azure resources
4. Organization : votre org GitHub
5. Repository : votre repo
6. Entity type : Branch, Environment, ou Tag
7. Based on selection : main (ou le nom de l'environnement)

Azure CLI

# Créer la federated credential
az ad app federated-credential create \
  --id <APP_ID> \
  --parameters '{
    "name": "github-main",
    "issuer": "https://token.actions.githubusercontent.com",
    "subject": "repo:owner/repo:ref:refs/heads/main",
    "audiences": ["api://AzureADTokenExchange"]
  }'

Étape 3 : Assigner les permissions

L'application a besoin d'un service principal et d'un rôle Azure au périmètre le plus restreint possible.

# Créer un service principal
az ad sp create --id <APP_ID>

# Assigner un rôle (exemple : Contributor sur un resource group)
az role assignment create \
  --assignee <APP_ID> \
  --role Contributor \
  --scope /subscriptions/<SUB_ID>/resourceGroups/<RG_NAME>

Étape 4 : Workflow GitHub

Le workflow s'authentifie avec azure/login, en passant les identifiants de l'application — aucun secret, uniquement des vars.

name: Deploy to Azure

on:
  push:
    branches: [main]

permissions:
  id-token: write
  contents: read

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: Se connecter à Azure via OIDC
        uses: azure/login@532459ea530d8321f2fb9bb10d1e0bcf23869a43 # v3.0.0
        with:
          client-id: ${{ vars.AZURE_CLIENT_ID }}
          tenant-id: ${{ vars.AZURE_TENANT_ID }}
          subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}

      - name: Déployer la web app
        run: az webapp deploy --resource-group my-rg --name my-app --src-path ./dist

GCP

Sur GCP, OIDC s'appuie sur la Workload Identity Federation : un pool, un provider OIDC, et un service account que le workflow impersonne.

Étape 1 : Créer le Workload Identity Pool

Le pool regroupe les identités externes autorisées à accéder au projet GCP.

Console GCP

1. Allez dans IAM & Admin > Workload Identity Federation
2. Cliquez Create Pool
3. Nom : github-pool
4. Cliquez Continue

gcloud

gcloud iam workload-identity-pools create github-pool \
  --location="global" \
  --description="GitHub Actions pool" \
  --display-name="GitHub Pool"

Étape 2 : Ajouter le Provider

Le provider OIDC relie le pool à l'émetteur GitHub et mappe les claims du JWT vers des attributs GCP.

Console GCP

1. Dans le pool, cliquez Add Provider
2. Sélectionnez OpenID Connect (OIDC)
3. Provider name : github-provider
4. Issuer URL : https://token.actions.githubusercontent.com
5. Audiences : Default audience
6. Attribute mapping :
   • google.subject = assertion.sub
   • attribute.repository = assertion.repository
   • attribute.actor = assertion.actor

gcloud

gcloud iam workload-identity-pools providers create-oidc github-provider \
  --location="global" \
  --workload-identity-pool="github-pool" \
  --issuer-uri="https://token.actions.githubusercontent.com" \
  --attribute-mapping="google.subject=assertion.sub,attribute.repository=assertion.repository,attribute.actor=assertion.actor"

Étape 3 : Autoriser le service account

Le service account porte les permissions GCP ; le pool est autorisé à l'impersonner uniquement pour le dépôt visé.

# Créer un service account
gcloud iam service-accounts create github-actions \
  --display-name="GitHub Actions"

# Autoriser le workload identity à impersonate le service account
gcloud iam service-accounts add-iam-policy-binding \
  github-actions@PROJECT_ID.iam.gserviceaccount.com \
  --role="roles/iam.workloadIdentityUser" \
  --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/github-pool/attribute.repository/owner/repo"

# Donner les permissions nécessaires au service account
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:github-actions@PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/storage.admin"

Étape 4 : Workflow GitHub

Le workflow récupère un token, s'authentifie auprès de GCP, puis installe la CLI gcloud pour les commandes de déploiement.

name: Deploy to GCP

on:
  push:
    branches: [main]

permissions:
  id-token: write
  contents: read

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: S'authentifier auprès de GCP via OIDC
        uses: google-github-actions/auth@7c6bc770dae815cd3e89ee6cdf493a5fab2cc093 # v3
        with:
          workload_identity_provider: projects/123456789/locations/global/workloadIdentityPools/github-pool/providers/github-provider
          service_account: github-actions@project-id.iam.gserviceaccount.com

      - name: Installer la CLI gcloud
        uses: google-github-actions/setup-gcloud@aa5489c8933f4cc7a4f7d45035b3b1440c9c10db # v3.0.1

      - name: Synchroniser vers Cloud Storage
        run: gsutil rsync -r ./dist gs://my-bucket

Résumé des configurations

Les trois clouds suivent la même logique — un provider d'identité, un lien de confiance, une action officielle — avec une terminologie propre à chacun.

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

Glissez pour voir

À retenir

• OIDC se configure en deux endroits : un lien de confiance côté cloud, une demande de token côté workflow.
• AWS : un IAM OIDC Provider plus un rôle IAM assumable via sts:AssumeRoleWithWebIdentity.
• Azure : une App Registration et des federated credentials liées à un sujet GitHub précis.
• GCP : un Workload Identity Pool, un provider OIDC et un service account impersonné.
• Dans les trois cas, la trust policy (condition sub) restreint le dépôt, la branche ou l'environnement autorisé.

Prochaines étapes

OIDC : authentification sans secrets Les principes d'OpenID Connect et le JWT GitHub Actions

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

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

Attaques supply chain Pourquoi OIDC limite la propagation après compromission

Documentation officielle par provider : AWS, Azure et GCP.

×

📖 Voir la documentation →