Tutoriel : Fédérer une identité de charge de travail Google Cloud avec Microsoft Entra ID

Un service qui s’exécute dans Google Cloud s’authentifie normalement pour Microsoft Entra ID avec un secret d’application de Microsoft Entra stocké afin qu’il puisse atteindre des ressources Azure. Vous devez protéger et faire pivoter ce secret, et le service fait face à une panne si le secret expire avant de le remplacer.

La fédération des identités de charge de travail supprime ce secret stocké. Vous configurez une application Microsoft Entra pour approuver le jeton d’ID que Google émet sur un compte de service Google Cloud, et votre service échange son jeton émis par Google pour un jeton d’accès Microsoft Entra au lieu de stocker des informations d’identification.

Dans ce tutoriel, vous identifiez un compte de service Google Cloud, le fédérer avec une application Microsoft Entra et échanger un jeton d’ID émis par Google pour un jeton d’accès Microsoft Entra que votre charge de travail utilise pour appeler une ressource Azure, telle que Stockage Blob Azure.

Le didacticiel comporte trois parties séquentielles qui créent un scénario terminé. Chaque partie dépend de la sortie de la partie avant celle-ci.

Dans ce tutoriel, vous allez :

  • Identifiez un compte de service Google Cloud et obtenez son ID unique.
  • Configurez une application Microsoft Entra pour approuver le jeton émis par Google.
  • Exchange un jeton d’ID Google pour un jeton d’accès Microsoft Entra et accéder à une ressource Azure.

Le diagramme suivant montre le flux de fédération d’identité de la charge de travail : une charge de travail obtient un jeton d’un fournisseur d’identité externe, l’échange avec le Plateforme d'identités Microsoft pour un jeton d’accès et utilise ce jeton d’accès pour atteindre une ressource Azure. Dans ce tutoriel, le fournisseur d’identité externe est Google Cloud et le jeton est un jeton d’ID émis par Google.

Diagramme du flux de fédération des identités de charge de travail entre une charge de travail externe, un fournisseur d’identité, le Plateforme d'identités Microsoft et Azure.

Prerequisites

  • Un locataire Microsoft Entra et un abonnement Azure. Si vous n’avez pas d’abonnement Azure, créez un compte gratuit avant de commencer.
  • Un projet Google Cloud et une charge de travail qui s’exécute sur un service Google Cloud qui peut obtenir un jeton d’ID pour un compte de service, tel que Le moteur d’application ou le moteur de calcul.
  • Accès à la console Google Cloud avec l’autorisation d’afficher les comptes de service dans IAM &Admin.
  • L’outil en ligne de commande Azure CLI (az) installé et configuré pour atteindre votre locataire. Vous pouvez également effectuer les étapes de Microsoft Entra dans le centre d’administration Microsoft Entra.
  • Autorisation d’ajouter des informations d’identification d’identité fédérée à une inscription d’application ou une identité managée. Pour ajouter des informations d’identification fédérées à une inscription d’application, votre compte doit être propriétaire de l’application ou contenir l’un des rôles Administrateur d’application, Développeur d’applications ou Administrateur d’application cloud , ou disposer de l’autorisation microsoft.directory/applications/credentials/update .

Partie 1 : Identifier un compte de service Google Cloud

Votre charge de travail Google Cloud a besoin d’une identité pour laquelle Google peut émettre des jetons. Les comptes de service Google Cloud fournissent cette identité. Utilisez le compte de service par défaut de votre projet Google Cloud ou créez un compte de service dédié pour votre charge de travail.

Google émet des jetons d’ID pour un compte de service où la sub revendication (objet) est l’ID unique du compte de service et la iss revendication (émetteur) est https://accounts.google.com. Vous utilisez les deux valeurs pour configurer l’approbation sur l’application Microsoft Entra dans la partie 2.

  1. Dans la console Google Cloud, accédez à IAM &Admin>Service Accounts.

  2. Sélectionnez le compte de service sous lequel votre charge de travail s’exécute.

  3. Dans les détails du compte de service, recherchez son ID unique et copiez la valeur. Cette valeur est la sub revendication dans les jetons que Google émet pour le compte de service.

Enregistrez l’ID unique en tant que <service-account-unique-id>. Vous l’utilisez comme sujet des informations d’identification d’identité fédérée dans la partie 2.

Partie 2 : Configurer une application Microsoft Entra pour approuver le jeton Google

Dans cette partie, vous ajoutez des informations d’identification d’identité fédérée à une application Microsoft Entra afin que Microsoft Entra ID approuve les jetons d’ID que Google émet pour votre compte de service. Les informations d’identification d’identité fédérée ont besoin de trois entrées :

  • subject: doit correspondre à la sub revendication dans le jeton émis par Google : l’ID unique du compte de service. <service-account-unique-id>
  • issuer: doit correspondre à la iss revendication. Pour Google Cloud, cette valeur est https://accounts.google.com. L’émetteur doit se conformer à la spécification de découverte OpenID Connect, car Microsoft Entra ID utilise l’URL de l’émetteur pour extraire les clés qui valident le jeton.
  • audiences: doit correspondre à la aud revendication. Utilisez la valeur api://AzureADTokenExchangeMicrosoft recommandée.

Une application Microsoft Entra prend en charge un nombre limité d’informations d’identification d’identité fédérée. Pour connaître la limite actuelle et d’autres restrictions, consultez Considérations et restrictions importantes pour les informations d’identification d’identité fédérée.

  1. Créez un fichier nommé credential.json avec le contenu suivant : Remplacez <service-account-unique-id> par l’ID unique que vous avez copié dans la partie 1.

    {
  "name": "AccessFromGoogle",
  "issuer": "https://accounts.google.com",
  "subject": "<service-account-unique-id>",
  "audiences": ["api://AzureADTokenExchange"],
  "description": "Federated credential for a Google Cloud workload"
}

  2. Ajoutez les informations d’identification d’identité fédérée à votre inscription d’application. Remplacez <your-app-id> par l’ID d’application (client) de votre application.

    az ad app federated-credential create --id <your-app-id> --parameters credential.json

Vous pouvez également ajouter les informations d’identification fédérées dans le centre d’administration Microsoft Entra. Accédez à inscriptions d'applications> les informationsd’identification> fédérées des certificats et des secrets> de votre application>, puis sélectionnez le scénario Autre émetteur. Fournissez https://accounts.google.com en tant qu’émetteur et l’ID unique du compte de service en tant que sujet. Pour obtenir les étapes détaillées, consultez Configurer une application pour approuver un fournisseur d’identité externe.

Pour configurer les informations d’identification sur une identité managée affectée par l’utilisateur au lieu d’une inscription d’application, utilisez la commande suivante. Vous avez besoin du rôle Propriétaire ou Contributeur sur l’identité managée. Pour obtenir les étapes détaillées, consultez Configurer une identité managée affectée par l’utilisateur pour approuver un fournisseur d’identité externe.

az identity federated-credential create \
    --name AccessFromGoogle \
    --identity-name <your-identity-name> \
    --resource-group <your-resource-group> \
    --issuer https://accounts.google.com \
    --subject <service-account-unique-id> \
    --audience api://AzureADTokenExchange

Accordez à votre application ou à votre identité managée l’accès aux ressources Azure que votre charge de travail appelle, telles qu’une attribution de rôle sur votre compte de stockage.

Partie 3 : Exchange un jeton Google pour un jeton d’accès Microsoft Entra

Dans cette partie, votre charge de travail obtient un jeton d’ID émis par Google pour son compte de service et l’échange pour un jeton d’accès Microsoft Entra, qu’il utilise pour appeler une ressource Azure.

Un service Google Cloud, tel que App Engine ou Compute Engine, demande un jeton d’ID pour son compte de service à partir du serveur de métadonnées Google. Google gère les clés de signature. Votre charge de travail n’a donc pas besoin de clés stockées.

  1. Demandez un jeton d’ID Google auprès du serveur de métadonnées. L’audience de la demande doit correspondre à l’audience que vous avez configurée sur les informations d’identification de l’identité fédérée. api://AzureADTokenExchange L’extrait de code Node.js suivant demande le jeton et le retourne sous forme de chaîne. Le concept est le même dans n’importe quelle langue.

    async function getGoogleIdToken() {
  const endpoint =
    "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=api://AzureADTokenExchange";
  const headers = { "Metadata-Flavor": "Google" };
  const response = await fetch(endpoint, { method: "GET", headers });
  return response.text();
}

  2. Exchange le jeton d’ID Google pour un jeton d’accès Microsoft Entra à l’aide ClientAssertionCredential du Kit de développement logiciel (SDK) Azure Identity. ClientAssertionCredential prend un rappel qui retourne l’assertion fédérée ( dans ce cas, le jeton d’ID Google). Fournissez votre ID de locataire Microsoft Entra en tant que tenantId et l'ID d'application (client) de l'inscription d'application en tant que clientId.

    import { ClientAssertionCredential } from "@azure/identity";

const credential = new ClientAssertionCredential(tenantId, clientId, getGoogleIdToken);

  3. Utilisez les informations d’identification avec n’importe quel client Kit de développement logiciel (SDK) Azure. Par exemple, pour appeler Stockage Blob Azure :

    const { BlobServiceClient } = require("@azure/storage-blob");

const blobClient = new BlobServiceClient(blobUrl, credential);

Lorsque le client a besoin d’un jeton, il appelle le rappel pour récupérer un nouveau jeton d’ID Google, échange le jeton Google avec Plateforme d'identités Microsoft pour un jeton d’accès et met en cache le jeton d’accès résultant. Étant donné que ClientAssertionCredential fournit l’assertion fédérée via un rappel, votre charge de travail ne stocke jamais de secret.

ClientAssertionCredentialest disponible dans les kits SDK d’identité Azure, notamment .NET, Java, JavaScript, Python et Go. Les bibliothèques MSAL prennent également en charge les assertions clientes si vous avez besoin d’un contrôle de niveau inférieur sur l’échange de jetons.

Votre charge de travail Google Cloud peut désormais accéder à Microsoft Entra ressources protégées sans secrets stockés.

Nettoyer les ressources

Si vous n’avez plus besoin des ressources que vous avez créées dans ce tutoriel, supprimez-les pour éviter les frais en cours :

  • Supprimez les informations d’identification de l’identité fédérée de votre inscription d’application :

    az ad app federated-credential delete \
    --id <your-app-id> \
    --federated-credential-id AccessFromGoogle

  • Si vous avez créé un compte de service Google Cloud dédié pour ce didacticiel, supprimez-le dans la console Google Cloud sous IAM etComptes de serviced’administration>.

  • Supprimez les attributions de rôles que vous avez ajoutées pour accorder à votre application ou à l’identité managée l’accès à Azure ressources.

Contenu connexe

  • Last updated on