OpenID Connect

Vue d’ensemble d’OpenID Connect (OIDC)

Les workflows GitHub Actions sont souvent conçus pour accéder à un fournisseur de cloud (tel qu’AWS, Azure, GCP, HashiCorp Vault, et autres) afin de déployer des logiciels ou d’utiliser les services du cloud. Avant que le workflow puisse accéder à ces ressources, il fournit des informations d’identification, telles qu’un mot de passe ou un jeton, au fournisseur de cloud. Ces informations d’identification sont généralement stockées en tant que secret dans GitHub, et le workflow présente ce secret au fournisseur de cloud chaque fois qu’il s’exécute.

Toutefois, l’utilisation de secrets codés en dur vous oblige à créer des informations d’identification dans le fournisseur de cloud, puis à les dupliquer dans GitHub en tant que secret.

Une fois que vous avez établi une connexion d’approbation avec un fournisseur de cloud prenant en charge OIDC, vous pouvez configurer votre flux de travail pour demander un jeton d’accès de courte durée directement auprès du fournisseur de cloud.

Avantages de l’utilisation d’OIDC

En mettant à jour vos workflows pour utiliser les jetons OIDC, vous pouvez adopter les bonnes pratiques de sécurité suivantes :

• Aucun secret cloud : vous n’aurez pas besoin de dupliquer vos informations d’identification cloud en tant que secrets GitHub à long terme. Au lieu de cela, vous pouvez configurer l’approbation OIDC sur votre fournisseur de cloud, puis mettre à jour vos workflows pour demander un jeton d’accès à court terme à partir du fournisseur de cloud via OIDC.
• Gestion de l’authentification et de l’autorisation : vous avez un contrôle plus précis sur la façon dont les workflows peuvent utiliser les informations d’identification, à l’aide des outils d’authentification (authN) et d’autorisation (authZ) de votre fournisseur de cloud pour contrôler l’accès aux ressources cloud.
• Rotation des informations d’identification : avec OIDC, votre fournisseur de cloud émet un jeton d’accès à court terme qui n’est valide que pour un seul travail, puis expire automatiquement.

Comment l'OIDC s'intègre avec GitHub Actions

Le diagramme suivant fournit une vue d’ensemble de la façon dont le fournisseur OIDC de GitHub s’intègre à vos workflows et à votre fournisseur de cloud :

1. Vous établissez une relation de confiance OIDC avec le fournisseur de cloud, ce qui permet à des flux de travail GitHub spécifiques de demander des jetons d'accès au cloud pour le compte d'un rôle défini dans le cloud.
2. Chaque fois que votre travail s’exécute, le fournisseur OIDC de GitHub génère automatiquement un jeton OIDC. Ce jeton contient plusieurs revendications pour établir une identité vérifiable à la sécurité renforcée sur le workflow spécifique qui tente de s’authentifier.
3. Une étape ou une action du travail de flux de travail peut demander un jeton au fournisseur OIDC de GitHub, qui peut ensuite être présenté au fournisseur cloud comme preuve de l’identité du flux de travail’.
4. Une fois que le fournisseur de cloud valide correctement les revendications présentées dans le jeton, il fournit ensuite un jeton d’accès cloud à court terme qui est disponible uniquement pour la durée du travail.

Présentation du jeton OIDC

Chaque travail demande un jeton OIDC à partir du fournisseur OIDC de GitHub, qui répond avec un jeton JSON Web Token (JWT) généré automatiquement, unique pour chaque travail de workflow où il est généré. Lorsque le travail s’exécute, le jeton OIDC est présenté au fournisseur de cloud. Pour valider le jeton, le fournisseur de cloud vérifie si la revendication de sujet et les autres revendications du jeton OIDC correspondent aux conditions préconfigurées dans la définition d’approbation OIDC du rôle cloud.

L’exemple de jeton OIDC suivant utilise un sujet (sub) qui référence un environnement de travail nommé prod dans le dépôt octo-org/octo-repo.

{
  "typ": "JWT",
  "alg": "RS256",
  "x5t": "example-thumbprint",
  "kid": "example-key-id"
}
{
  "jti": "example-id",
  "sub": "repo:octo-org/octo-repo:environment:prod",
  "environment": "prod",
  "aud": "https://github.com/octo-org",
  "ref": "refs/heads/main",
  "sha": "example-sha",
  "repository": "octo-org/octo-repo",
  "repository_owner": "octo-org",
  "actor_id": "12",
  "repository_visibility": "private",
  "repository_id": "74",
  "repository_owner_id": "65",
  "run_id": "example-run-id",
  "run_number": "10",
  "run_attempt": "2",
  "runner_environment": "github-hosted",
  "actor": "octocat",
  "workflow": "example-workflow",
  "head_ref": "",
  "base_ref": "",
  "event_name": "workflow_dispatch",
  "ref_type": "branch",
  "job_workflow_ref": "octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main",
  "iss": "https://token.actions.githubusercontent.com",
  "nbf": 1632492967,
  "exp": 1632493867,
  "iat": 1632493567
}

Authentification d’actions personnalisées à l'aide de l'OIDC

Les actions personnalisées utilisent la méthode getIDToken() de la boîte à outils Actions ou d’une commande curl pour s’authentifier à l'aide de l'OIDC.

Pour plus d’informations, consultez « Informations de référence sur OpenID Connect ».

Mise à jour de vos workflows pour OIDC

GitHub Actions les flux de travail peuvent utiliser des jetons OIDC au lieu de secrets pour s'authentifier auprès des fournisseurs de services de cloud. De nombreux fournisseurs de services cloud populaires proposent des actions de connexion officielles qui simplifient le processus d'utilisation de l'OIDC dans vos flux de travail. Pour plus d’informations sur la mise à jour de vos flux de travail avec des fournisseurs de cloud spécifiques, consultez Renforcement de la sécurité de vos déploiements.

Étapes suivantes

Pour plus d’informations à propos de la configuration de l’OIDC, consultez Renforcement de la sécurité de vos déploiements.

Pour obtenir des informations de référence à propos de l'OIDC, consultez Informations de référence sur OpenID Connect.