OpenID Connect

Vue d’ensemble d’OpenID Connect (OIDC)

          GitHub Actions Les flux de travail sont souvent conçus pour accéder à un fournisseur de cloud (par exemple AWS, Azure, GCP, HashiCorp Vault et d’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 flux de travail 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 en GitHub 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 de longue durée GitHub . 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 à GitHub Actions

Le diagramme suivant donne une vue d’ensemble de la façon dont GitHuble fournisseur OIDC s’intègre à vos flux de travail et à votre fournisseur de cloud :

Diagramme de la façon dont un fournisseur de cloud s’intègre à GitHub Actions via des jetons d’accès et des ID de rôle cloud de jeton web JSON.

Vous établissez une relation d’approbation OIDC dans le fournisseur de cloud, ce qui permet aux flux de travail spécifiques GitHub de demander des jetons d’accès cloud au nom d’un rôle cloud défini.
Chaque fois que votre travail s’exécute, GitHuble fournisseur OIDC 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.
Une étape ou une action dans le travail de flux de travail peut demander un jeton auprès du GitHubfournisseur OIDC, qui peut ensuite être présenté au fournisseur cloud comme preuve de l’identité du flux de travail.
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 tâche demande un jeton OIDC auprès du fournisseur OIDC de GitHub, qui répond avec un jeton web JSON (JWT) généré automatiquement, unique pour chaque tâche du flux de travail 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://HOSTNAME/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",
  "enterprise": "avocado-corp",
  "enterprise_id": "2",
  "ref_type": "branch",
  "job_workflow_ref": "octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main",
  "iss": "https://HOSTNAME/_services/token",
  "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 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 [AUTOTITLE](/actions/how-tos/security-for-github-actions/security-hardening-your-deployments).

Prise en charge d’OIDC pour Dependabot

          Dependabot peut utiliser OIDC pour s’authentifier auprès des registres privés, ce qui élimine la nécessité de stocker des informations d’identification de longue durée en tant que secrets de référentiel. Avec l’authentification basée sur OIDC, Dependabot les travaux de mise à jour peuvent obtenir dynamiquement des informations d’identification de courte durée auprès de votre fournisseur d’identité cloud.

          Dependabot prend en charge l’authentification OIDC pour tout type de registre qui utilise `username` et `password` authentification, lorsque le registre est hébergé sur AWS CodeArtifact, Azure DevOps Artifacts ou JFrog Artifactory.

Les avantages de l'authentification OIDC pour Dependabot sont les suivants :

        **Sécurité renforcée :** Élimine les informations d’identification statiques et de longue durée de vie de vos dépôts.

        **Gestion plus simple :** Permet un accès sécurisé et conforme aux stratégies aux registres privés.

        **Évitez la limitation du débit :** Les informations d’identification dynamiques vous permettent d’éviter d’atteindre les limites de débit associées aux jetons statiques.

Pour plus d’informations, consultez « Configuration de l’accès aux registres privés pour Dependabot ».

Étapes suivantes

Pour plus d’informations sur 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.

Dans cet article