Federated credentials : comment déployer un pipeline pour Azure sans secrets ni certificats

Traditionnellement, les DevOps utilisent des certificats ou des secrets pour authentifier leurs applications et services dans Microsoft Entra ID (source).

Depuis 2023, Microsoft Entra ID propose les federated credentials pour s’authentifier et accéder à Azure ou Microsoft Graph.

Cette nouvelle méthode repose sur le protocole OpenID Connect (OIDC).

Contrairement aux secrets et aux certificats, les federated credentials n’ont pas de date d’expiration. Il n’est donc pas nécessaire de les renouveler.

De plus, les federated credentials permettent d’établir une relation de confiance entre Microsoft Entra ID et un fournisseur d’identité externe (GitHub, Google, autres…) : il n’est donc pas possible d’usurper une identité (à l’inverse d’un secret qui aurait fuité).

Dans cet article, nous allons voir comment utiliser les federated credentials pour s’authentifier dans les usines logicielles Azure DevOps et GitHub.

Prérequis à la création d’un federated credential

Pour pouvoir créer un federated credential, il vous sera nécessaire d’avoir des droits suffisants pour créer et éditer une app registration dans Microsoft Entra ID.

Depuis le portail Azure, il faudra ouvrir l’app registration qu’on souhaite utiliser pour s’authentifier. Dans cet article, on utilisera comme exemple l’app registration nommée « demo-cellenza-blog ».

Cette app registration aura le droit RBAC Reader (ou Contributor si nécessaire) sur un abonnement Azure SUB1.

Nous aurons besoin de collecter les informations suivantes depuis le portail Azure :

1. Identifiant de l’app registration (Application ID) (aussi appelé Service principal ID)
2. Identifiant du Tenant (Tenant ID)
3. Identifiant de l’abonnement Sub1 (Subscription ID)

Ensuite, on pourra se rendre dans le menu « Certificates & Secrets » et sélectionner l’onglet « Federated credentials ». On pourra alors ajouter un nouvel identifiant.

Azure DevOps

Dans cette partie, nous allons voir comment créer un service connection authentifié sur Microsoft Entra ID avec federated credential.

Après s’être authentifié sur le portail Azure DevOps de votre organisation, il faudra sélectionner le projet souhaité.

Depuis la page du projet, on peut alors sélectionner les paramètres du projet.

Depuis la rubrique « Service connections », on peut créer un nouveau service connection.

On sélectionnera « Azure Resource Manager ».

On choisira ensuite Worload Identity federation (manual).

Remarque : Azure DevOps recommande d’utiliser le mode automatique pour créer un workload identity federation. L’avantage de ce choix par rapport au mode manuel est qu’il va générer automatiquement une app registration sur Microsoft Entra ID et inscrire les informations provenant d’Azure DevOps. Cependant, ce scénario n’est pas toujours envisageable si l’app registration existe déjà, ou si l’utilisateur n’a pas le droit en création sur les app registration par exemple.

Après avoir donné un nom à votre Service connection, un nouvel écran va apparaitre avec les informations nécessaires à renseigner sur Microsoft Entra ID.

Avant d’aller plus loin, il nous faut retourner sur Microsoft Entra ID pour saisir ces informations dans le nouveau credential créé.

On sélectionne d’abord “Other Issuer” comme scénario, puis on saisit les deux identifiants fournis par Azure DevOps.

On peut retourner sur Azure DevOps pour finaliser le service connection.

On pourra renseigner les informations d’authentification avec les données collectées dans les prérequis.

Enfin le bouton « Verify and Save » permet de terminer la création du service connection et vérifie la connexion avec l’abonnement Azure SUB1.

Le service connection peut désormais être utilisé dans les pipelines d’Azure DevOps.

Test du Service connection dans un pipeline

On va créer un pipeline permettant de tester ce Service connection.

On pourra ensuite l’exécuter en approuvant l’usage du Service connection.

Le pipeline a utilisé le federated credential pour se connecter à Azure avec succès.

Federated credentials avec GitHub

Dans cette partie, nous allons voir comment authentifier un GitHub Action sur Microsoft Entra ID avec les federated credentials.

Depuis GitHub , il faudra d’abord récupérer le nom de l’organisation, le nom du dépôt et le nom de la branche qui vont contenir le GitHub Action.

On peut ensuite retourner sur Microsoft Entra ID pour créer notre federated credential.

On sélectionne comme scénario : GitHub Actions deploying Azure resources.

Il nous reste à renseigner un nom pour le credential avant d’enregistrer.

On peut ensuite retourner sur GitHub pour terminer la mise en place de l’authentification.

A noter : Nous ne décrivons pas les autres Entity Type dans cet article, mais il est également possible de cibler des environnements. Le type Environment permet de cibler un environnement avec les protections associées (reviewers, wait timer) plutôt qu’une branche spécifique. Il nécessite néanmoins d’utiliser un dépôt Git public ou d’avoir une licence Pro, Team ou Enterprise.

Depuis la page « Settings » on va pouvoir sélectionner l’onglet « Secrets and variables » puis ajouter les identifiants qu’on a collectés dans les prérequis.

On peut désormais connecter nos GitHub Actions à Azure avec le federated credential.

Test de la connexion à Azure avec GitHub Action

On peut créer un GitHub action avec le fichier suivant : demo-blog-cellenza/.github/workflows/workflow.yml

Le pipeline a utilisé le federated credential pour se connecter à Azure avec succès.

L’essentiel à retenir sur les federated credentials

Nous avons vu dans cet article comment mettre en place l’authentification à Microsoft Entra ID en utilisant les federated credentials.

Cette solution peut être utilisée dans différentes usines logicielles comme Azure DevOps ou GitHub pour accéder et déployer des ressources dans Azure.

Il est également possible d’utiliser les federated credentials dans d’autres contextes tels que le déploiement d’un AKS.