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 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",
  "repo_property_workspace_id": "ws-abc123",
  "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

Les flux de travail GitHub Actions 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.

Utilisation des propriétés personnalisées du référentiel en tant que revendications OIDC

Les administrateurs de l’organisation et de l’entreprise peuvent inclure des propriétés personnalisées de dépôt en tant que revendications dans des jetons OIDC. Une fois ajouté, chaque référentiel de l’organisation ou de l’entreprise qui a une valeur définie pour cette propriété personnalisée l’inclut automatiquement dans ses jetons OIDC, préfixés par repo_property_.

Cela vous permet de créer des stratégies d’accès granulaires qui se lient directement à vos métadonnées de référentiel, ce qui réduit la dérive de configuration et élimine la nécessité de dupliquer les informations de gouvernance sur plusieurs systèmes.

Prerequisites

• Les propriétés personnalisées doivent déjà être définies au niveau de l’organisation ou de l’entreprise.
• Vous devez être administrateur d’organisation ou administrateur d’entreprise.

Ajout d'une propriété personnalisée aux affirmations de jeton OIDC

Pour inclure une propriété personnalisée dans des jetons OIDC, utilisez l’API REST ou l’interface utilisateur des paramètres pour votre organisation ou entreprise.

          **Utilisation de l’interface utilisateur des paramètres :** Accédez à la page des paramètres OIDC Actions de votre organisation ou entreprise pour afficher et gérer les propriétés personnalisées incluses dans les jetons OIDC.

•         **Utilisation de l’API REST :** Envoyez une demande pour ajouter une `POST` propriété personnalisée aux revendications de jeton OIDC pour votre organisation :
  

Exemple de jeton OIDC avec une propriété personnalisée

L’exemple suivant montre un jeton OIDC qui inclut la workspace_id propriété personnalisée :

{
  "sub": "repo:my-org/my-repo:ref:refs/heads/main",
  "aud": "https://github.com/my-org",
  "repository": "my-org/my-repo",
  "repo_property_workspace_id": "ws-abc123"
}

Vous pouvez utiliser les revendications dans les repo_property_* conditions d’approbation de votre fournisseur cloud pour créer des stratégies de contrôle d’accès flexibles basées sur des attributs. Pour plus d’informations, consultez « Informations de référence sur OpenID Connect ».

Prise en charge de 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, les travaux de mise à jour de Dependabot peuvent obtenir dynamiquement des identifiants à durée limité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 l’authentification password, 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.