OpenID Connect

OpenID Connect permet à vos workflows d’échanger des jetons de courte durée directement à partir de votre fournisseur de cloud.

Dans cet article

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.

  1. 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.
  2. 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.
  3. 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.
  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 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://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

          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).

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. Cela active les stratégies de contrôle d’accès en fonction des attributs (ABAC) dans votre fournisseur cloud, votre registre d’artefacts ou le gestionnaire de secrets pilotés par les métadonnées du référentiel plutôt que par des listes d’autorisation codées en dur.

Fonctionnement des revendications de propriété personnalisées

Le processus complet pour utiliser des propriétés personnalisées comme des revendications OIDC est le suivant :

  1.        **Définissez des propriétés personnalisées.** Une organisation ou un administrateur d’entreprise crée des propriétés personnalisées (par exemple, `business_unit`, ou `data_classification``environment_tier`) et affecte des valeurs aux référentiels. Pour plus d’informations, consultez « [AUTOTITLE](/organizations/managing-organization-settings/managing-custom-properties-for-repositories-in-your-organization) » et « [AUTOTITLE](/actions/reference/security/oidc#including-repository-custom-properties-in-oidc-tokens) ». 

  2.        **Activez les propriétés dans les jetons OIDC.** Une organisation ou un administrateur d’entreprise sélectionne les propriétés personnalisées qui doivent être incluses dans les jetons OIDC, à l’aide de l’interface utilisateur des paramètres ou de l’API REST.

  3.        **Les revendications apparaissent automatiquement.** Chaque flux de travail exécuté dans un référentiel dont la valeur est définie pour une propriété activée inclut cette valeur dans son jeton OIDC, préfixé par `repo_property_`. Aucune modification de configuration au niveau du flux de travail n’est requise.

  4.        **Mettez à jour les stratégies d’approbation cloud.** Vous mettez à jour les conditions d’approbation de votre fournisseur cloud pour évaluer les nouvelles `repo_property_*` revendications, ce qui permet des décisions d’accès affinées basées sur des attributs.

Étant donné que cela s’appuie sur le modèle d’informations d’identification OIDC existant de GitHub, aucun secret de longue durée n’est requis, et chaque jeton est délimité, auditable et renouvelé automatiquement à chaque exécution du flux de travail.

Prerequisites

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 `POST` demande au `/orgs/{org}/actions/oidc/customization/properties/repo` point de terminaison pour ajouter une propriété personnalisée aux revendications de jeton OIDC pour votre organisation. Pour obtenir des paramètres de requête et des détails complets, consultez la documentation de l’API REST pour la gestion des propriétés personnalisées OIDC : [AUTOTITLE](/rest/actions/oidc).

Exemple de jeton OIDC avec des propriétés personnalisées

L’exemple suivant montre un jeton OIDC qui inclut deux propriétés personnalisées : une propriété business_unit à sélection unique et une propriété workspace_idde chaîne. Chaque propriété personnalisée apparaît dans le jeton avec le repo_property_ préfixe.

{
  "sub": "repo:my-org/my-repo:ref:refs/heads/main",
  "aud": "https://github.com/my-org",
  "repository": "my-org/my-repo",
  "repository_owner": "my-org",
  "ref": "refs/heads/main",
  "repo_property_business_unit": "payments",
  "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 sur le format de revendication, les types de propriétés pris en charge et les limites, consultez Informations de référence sur OpenID Connect.

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.