Créer une identité de charge de travail pour un workflow GitHub Actions

Effectué

Maintenant que vous comprenez le concept d’une identité de charge de travail, vous pouvez vous demander comment en créer un et le lier à un workflow de déploiement GitHub Actions. Cette unité explique les étapes à effectuer pour y parvenir.

Créer un proxy d’application Microsoft Entra

Dans l’unité précédente, vous avez appris que les identités de charge de travail nécessitent la création d’une inscription d’application dans Microsoft Entra ID.

Remarque

La création et la modification des inscriptions d’applications nécessitent des autorisations dans Microsoft Entra ID. Dans certaines organisations, vous avez peut-être besoin d’un administrateur pour effectuer ces étapes.

Lorsque vous créez une inscription d’application, vous devez spécifier un nom complet. Le nom complet est un nom lisible par l’homme qui décrit l’inscription d’application.

Conseil

Utilisez un nom complet clair et descriptif pour votre inscription d’application. Il est important d’aider votre équipe à comprendre ce qu’est une inscription d’application, de sorte que personne ne le supprime accidentellement ou ne modifie ses autorisations.

Voici un exemple de commande Azure CLI pour créer une application Microsoft Entra :

az ad app create --display-name $applicationRegistrationName

Voici un exemple de commande Azure PowerShell pour créer une nouvelle application Microsoft Entra :

New-AzADApplication -DisplayName $applicationRegistrationName

La sortie de la commande précédente comprend des informations importantes, notamment :

• ID d’application : l’inscription d’application possède un identificateur unique, souvent appelé ID d’application ou parfois ID client. Vous utilisez cet identificateur quand votre workflow doit se connecter à Azure.
• ID d’objet : L’inscription d’application a un ID d’objet, qui est un identificateur unique attribué par Microsoft Entra ID. Vous verrez un exemple d’utilisation d’un ID d’objet plus loin dans ce module.

Quand vous créez une inscription d’application, vous ne définissez en général que le nom complet. Azure attribue automatiquement les autres noms et identificateurs.

Attention

Un nom d’affichage n’est pas unique. Plusieurs inscriptions d’application peuvent partager le même nom complet. Soyez prudent quand vous octroyez des autorisations à une inscription d’application en l’identifiant par son nom complet. Vous pouvez accidentellement accorder des autorisations à des inscriptions d’application incorrectes. Il est recommandé d’utiliser l’un des identificateurs uniques à la place.

Informations d’identification fédérées

Quand une identité doit communiquer avec Azure, elle se connecte à Microsoft Entra ID. Par lui-même, une inscription d’application n’autorise pas un workflow ni une application à se connecter à Azure. Vous devez d’abord attribuer des informations d’identification. Les informations d’identification fédérées sont un type d’informations d’identification d’application. Contrairement à la plupart des informations d’identification, les informations d’identification fédérées ne vous obligent pas à gérer des secrets tels que des mots de passe ou des clés.

Lorsque vous créez des informations d’identification fédérées pour un workflow de déploiement, vous indiquez efficacement à Microsoft Entra ID et à GitHub de se faire confiance. Cette confiance est appelée une fédération.

Ensuite, quand votre workflow tente de se connecter, GitHub fournit des informations sur l’exécution du workflow afin que Microsoft Entra ID puisse décider s’il faut autoriser la tentative de connexion. Les informations fournies par GitHub à Microsoft Entra ID pendant chaque tentative de connexion peuvent inclure les champs suivants :

• Nom d’utilisateur ou d’organisation GitHub.
• Nom du dépôt GitHub.
• Branche de votre référentiel sur laquelle le workflow est actuellement en cours d’exécution.
• Environnement cible de votre travail de workflow. Vous en apprendrez davantage sur les environnements dans un prochain module.
• Si la création d’une demande de tirage (pull request) a déclenché le workflow.

Vous pouvez configurer Microsoft Entra ID pour autoriser ou refuser une tentative de connexion à partir de GitHub en fonction des valeurs des propriétés répertoriées précédemment. Par exemple, vous pouvez appliquer les stratégies suivantes :

• Autorisez uniquement les tentatives de connexion lorsqu’un workflow s’exécute à partir d’un référentiel GitHub spécifique au sein de mon organisation.
• Autoriser uniquement les tentatives de connexion lorsqu’un workflow s’exécute à partir d’un dépôt GitHub spécifique au sein de mon organisation et que le nom de la branche est main.

Voici une illustration de la façon dont un workflow de déploiement peut se connecter à l’aide d’une identité de charge de travail et d’informations d’identification fédérées :

Les étapes impliquées dans le processus de connexion sont les suivantes :

1. Lorsque votre workflow doit communiquer avec Azure, GitHub contacte en toute sécurité Microsoft Entra ID pour demander un jeton d’accès. GitHub fournit des informations sur l’organisation GitHub (my-github-user), le dépôt (my-repo) et la branche sur laquelle le workflow s’exécute (main). Il inclut également votre ID de locataire dans Microsoft Entra ID, l’ID d’application de l’inscription d’application de l’identité du workflow et l’ID d’abonnement Azure sur lequel votre workflow souhaite être déployé.

2. Microsoft Entra ID valide l’ID d’application et vérifie si des informations d’identification fédérées existent dans l’application pour l’organisation GitHub, le référentiel et la branche.

3. Une fois que Microsoft Entra ID détermine que la requête est valide, elle émet un jeton d’accès. Votre workflow utilise le jeton d’accès lorsqu’il communique avec Azure Resource Manager.

Créer des informations d’identification fédérées

Quand vous utilisez Azure CLI, vous définissez des informations d’identification fédérées en créant un fichier JSON ou une variable. Par exemple, regardez le fichier JSON suivant :

{
  "name": "MyFederatedCredential",
  "issuer": "https://token.actions.githubusercontent.com",
  "subject": "repo:my-github-user/my-repo:ref:refs/heads/main",
  "audiences": [
    "api://AzureADTokenExchange"
  ]
}

Dans ce fichier, la propriété subject spécifie que les informations d’identification fédérées doivent être valides uniquement quand un workflow s’exécute dans les situations suivantes :

Champ	Valeur
Nom de l’organisation Github	my-github-user
Nom du référentiel GitHub	my-repo
Nom de la branche	main

Après avoir créé une stratégie dans JSON et l’avoir enregistrée dans un fichier nommé policy.json, vous pouvez utiliser Azure CLI pour créer les informations d’identification fédérées :

az ad app federated-credential create \
  --id $applicationRegistrationObjectId \
  --parameters @policy.json

Lorsque vous utilisez Azure PowerShell, vous définissez des informations d’identification fédérées en créant une chaîne similaire à ce qui suit :

$policy = "repo:my-github-user/my-repo:ref:refs/heads/main"

La chaîne précédente spécifie que les informations d’identification fédérées doivent être valides uniquement quand un workflow s’exécute dans les situations suivantes :

Champ	Valeur
Nom de l’organisation Github	my-github-user
Nom du référentiel GitHub	my-repo
Nom de la branche	main

Une fois que vous avez créé une chaîne de stratégie, vous pouvez utiliser Azure PowerShell pour créer les informations d’identification fédérées :

New-AzADAppFederatedCredential `
  -Name 'MyFederatedCredential' `
  -ApplicationObjectId $applicationRegistrationObjectId `
  -Issuer 'https://token.actions.githubusercontent.com' `
  -Audience 'api://AzureADTokenExchange' `
  -Subject $policy

Gérer le cycle de vie de votre identité de charge de travail

Il est important de prendre en compte le cycle de vie complet de chaque identité de charge de travail que vous créez. Lorsque vous générez une identité de charge de travail pour un workflow de déploiement, que se passe-t-il si le workflow est finalement supprimé ou n’est plus utilisé ?

Les identités de charge de travail et les informations d’identification fédérées ne sont pas supprimées automatiquement. Vous devez donc auditer et supprimer les anciennes. Même si les identités de charge de travail de votre workflow de déploiement n’ont pas d’informations d’identification secrètes qui peuvent être réutilisées, il est toujours préférable de les supprimer lorsqu’elles ne sont plus nécessaires. De cette façon, il n’y a aucune chance que quelqu’un puisse créer un autre dépôt GitHub portant le même nom et obtenir un accès imprévu à votre environnement Azure.

Il est recommandé de documenter vos identités de charge de travail dans un emplacement accessible facilement par vous et votre équipe. Incluez les informations suivantes pour chaque identité de charge de travail :

• Informations d’identification de clé, comme le nom et l’ID d’application
• Son but
• Le créateur, le responsable de sa gestion et celui qui détient les réponses en cas de problème
• Les autorisations nécessaires ainsi qu’une justification claire de la raison pour laquelle elles sont nécessaires
• Sa durée de vie attendue

Vous devez régulièrement auditer vos identités de charge de travail pour vous assurer qu’ils sont toujours en cours d’utilisation et que les autorisations attribuées sont toujours correctes.