Autoriser les clients à accéder à leurs ressources Google Cloud à partir de votre produit ou service

Cet article décrit les exigences et les bonnes pratiques que vous pouvez suivre pour permettre aux clients d'utiliser votre produit afin d'accéder à leurs ressources dans Google Cloud sans utiliser des clés de compte de service.

Si vous proposez un produit ou gérez un service permettant aux clients d'analyser ou de gérer des données ou des ressources, vos clients pourraient souhaiter accéder à des données ou à d'autres ressources dans leur environnement Google Cloud. Voici des exemples de ces produits et services :

  • Produits d'analyse de données : vos clients peuvent vouloir utiliser ces produits pour analyser leurs données dans BigQuery.
  • Produits et services CI/CD : vos clients peuvent utiliser ces services pour déployer une infrastructure et des applications sur leurs projets Google Cloud.
  • Automatisation des processus par la robotique (RPA) : vos clients peuvent utiliser la RPA pour les workflows tels que la création de projets, la gestion des accès ou l'automatisation des tâches d'administration dans Google Cloud.

Pour authentifier des produits sur site ou SaaS (Software as a Service) auprès de Google Cloud, les clients s'appuient traditionnellement sur des clés de compte de service, mais ces clés peuvent être difficiles à gérer et stocker en toute sécurité.

En tant que fournisseur d'un produit sur site ou SaaS, vous pouvez aider vos clients à protéger leurs ressources Google Cloud en leur permettant d'utiliser la fédération d'identité de charge de travail pour accéder à leurs ressources Google Cloud. Terraform Cloud, GitHub et GitLab sont des exemples de services qui permettent déjà à leurs clients d'utiliser la fédération d'identité de charge de travail

Cet article explique comment étendre votre produit pour assurer la compatibilité avec la fédération d'identité de charge de travail et décrit les bonnes pratiques que vous pouvez adopter. Dans cet article, nous partons du principe que vous connaissez la fédération d'identité de charge de travail et OpenID Connect.

Architecture

L'objectif de la fédération d'identité de charge de travail est de supprimer les clés de compte de service, en permettant à vos clients de fédérer votre produit ou service avec leur environnement Google Cloud. Vos clients peuvent ensuite accéder à leurs ressources Google Cloud à l'aide d'une identité déclarée par votre produit ou service.

Pour permettre à vos clients d'utiliser la fédération d'identité de charge de travail, votre produit ou service doit mettre en œuvre un sous-ensemble d'OpenID Connect. En particulier, vous devez autoriser les charges de travail à obtenir un jeton d'ID répondant aux critères suivants :

  • Le jeton identifie la charge de travail au sein de votre produit ou de votre plate-forme.
  • Le jeton identifie l'instance, le locataire ou l'installation de votre produit ou plate-forme.
  • Le jeton contient une signature cryptographique que la fédération d'identité de charge de travail peut utiliser pour vérifier l'authenticité du jeton.

Conditions requises

Pour assurer la compatibilité avec la fédération d'identité de charge de travail, vous devez vous assurer que votre produit ou service répond aux exigences suivantes :

  1. Les charges de travail ont accès à un jeton d'ID valide.

    À tout moment pendant son cycle de vie, une charge de travail doit avoir accès à un jeton d'ID qui valide l'identité de la charge de travail et respecte les exigences définies par OpenID Connect 1.0.

    Étant donné que les jetons d'identification ont une durée de vie limitée, vous devez vous assurer qu'un jeton d'ID survit à sa charge de travail, ou que les charges de travail peuvent obtenir périodiquement de nouveaux jetons d'ID.

  2. Les jetons d'ID identifient la charge de travail de manière unique.

    Le jeton d'ID doit contenir une ou plusieurs revendications qui identifient de manière unique la charge de travail. L'identifiant de la charge de travail doit être immuable.

    Pour les produits ou services compatibles avec architecture mutualisée, le jeton doit également contenir une ou plusieurs revendications identifiant de manière unique le locataire. L'identifiant de locataire doit également être immuable.

  3. Les jetons d'ID sont signés, mais ne sont pas chiffrés.

  4. Les métadonnées du fournisseur OpenID sont accessibles au public et peuvent être découvertes à partir de jetons d'ID.

    Vous devez fournir un document de configuration de fournisseur OpenID sur un point de terminaison accessible publiquement et qui peut être découvert à l'aide du protocole de découverte d'émetteur OpenID. Par exemple, si les jetons d'ID contiennent une revendication iss avec la valeur https://service.example.com/v1/, vous devez fournir un document de configuration de fournisseur OpenID sur https://service.example.com/v1/.well-known/openid-configuration, et le point de terminaison doit être accessible publiquement sur Internet à partir de n'importe quelle adresse IP.

  5. Les clés de signature sont accessibles au public et peuvent être découvertes à partir des métadonnées du fournisseur OpenID.

    Vous devez fournir un document de jeu de clés Web JSON (JWKS) sur un point de terminaison accessible au public qui peut être découvert à partir du champ jwks_uri des métadonnées du fournisseur OpenID.

Bonnes pratiques

Lorsque vous étendez votre produit ou service pour assurer la compatibilité avec la fédération d'identité de charge de travail, tenez compte des bonnes pratiques suivantes.

Bonnes pratiques :

Distinguer les jetons d'identité et les jetons d'accès.
Exposer les jetons d'ID d'une manière compatible avec les bibliothèques clientes.
Utiliser des URL d'émetteur spécifiques au locataire.
Autoriser les utilisateurs à spécifier l'audience du jeton d'ID.
Utiliser des identifiants immuables et non réutilisables dans les revendications des jetons d'ID.
Inclure des informations de contexte dans les jetons d'ID.
Limiter la durée de vie du jeton d'ID à 30-60 minutes.

Distinguer les jetons d'identité et les jetons d'accès

Dans le contexte de la fédération d'identité de charge de travail, le jeton d'ID a pour but de valider l'identité de la charge de travail : le jeton doit contenir suffisamment d'informations pour que la fédération d'identité de charge de travail puisse identifier et distinguer la charge de travail spécifique des autres charges de travail.

Contrairement aux jetons d'ID, les jetons d'accès ont généralement une fonction différente : ils sont utilisés pour prendre des décisions d'accès et peuvent contenir des informations sur les autorisations d'une charge de travail ou sur les API auxquelles elle est autorisée à accéder.

Si votre produit ou service utilise actuellement des jetons d'accès pour permettre aux charges de travail d'appeler l'API de votre produit, ces jetons d'accès peuvent ne pas être adaptés à la fédération d'identité de charge de travail. Au lieu de redéfinir les jetons d'accès en tant que jetons d'identification, envisagez d'introduire un deuxième type de jeton correspondant à la définition d'un jeton d'ID et laissez les charges de travail utiliser ce jeton d'ID pour la fédération d'identité de charge de travail.

Exposer les jetons d'ID d'une manière compatible avec les bibliothèques clientes

Les bibliothèques clientes Google Cloud peuvent obtenir automatiquement des jetons d'identification à partir de plusieurs sources, dont les suivantes :

  • Un point de terminaison HTTP (identifiants provenant d'une URL)
  • Un fichier local (identifiants basés sur un fichier)

Pour obtenir des jetons d'identification auprès d'autres sources, vos clients peuvent avoir besoin de modifier leur code, ou de déployer des outils ou des bibliothèques supplémentaires. En exposant des jetons d'ID d'une manière compatible avec les bibliothèques clientes, vous pouvez éviter une telle complexité supplémentaire et faciliter l'adoption de la fédération d'identité de charge de travail par vos clients.

Utiliser des URL d'émetteur spécifiques au locataire

Les revendications intégrées dans le jeton d'ID d'une charge de travail peuvent être uniques dans une instance spécifique de votre produit ou service, mais elles peuvent ne pas être uniques sur plusieurs instances de votre produit ou service. Par exemple, deux de vos clients peuvent utiliser votre produit ou service pour déployer une charge de travail et leur attribuer par inadvertance le même nom et le même ID.

La fédération Workload Identity tente de compenser ce manque d'unicité possible en vérifiant l'URL d'émetteur (iss) des jetons d'ID et en n'autorisant que les jetons d'un seul émetteur par pool d'identités de charge de travail.

Si votre produit ou service est compatible avec l'architecture mutualisée, plusieurs de vos clients peuvent partager une même instance de votre produit ou service, et les jetons d'ID de leurs charges de travail peuvent utiliser la même URL d'émetteur. L'utilisation d'une même URL d'émetteur sur plusieurs locataires peut exposer vos clients à des attaques de spoofing. Par exemple, un acteur malintentionné peut créer une charge de travail dans son propre locataire, lui attribuer le même ID ou le même nom qu'une charge de travail dans le locataire de la victime, et utiliser le jeton d'ID de sa charge de travail pour simuler l'identité d'une charge de travail de la victime.

Pour protéger vos clients contre les attaques de spoofing, évitez d'utiliser les mêmes URL d'émetteur sur plusieurs locataires et intégrez un ID de locataire unique dans l'URL d'émetteur, par exemple https://saas.example.com/tenant-123/.

Autoriser les utilisateurs à spécifier l'audience du jeton d'ID

Certaines des charges de travail de votre client peuvent avoir besoin d'accéder à Google Cloud et à d'autres services tiers. Lorsque les clients décident de fédérer votre produit ou service avec plusieurs parties de confiance, ils peuvent se trouver dans une situation où le jeton d'ID d'une charge de travail est utilisé par inadvertance ou de manière malveillante pour la mauvaise partie de confiance. Par exemple, un acteur malintentionné peut inciter une charge de travail à révéler un jeton d'ID destiné à un service tiers, puis l'utiliser pour la fédération d'identité de charge de travail.

Pour éviter que vos clients ne soient victimes de telles attaques de type "confused deputy", évitez d'utiliser une audience statique (revendication aud) dans les jetons d'ID. Au lieu de cela, laissez les charges de travail spécifier une audience lorsqu'elles obtiennent un jeton d'ID et, éventuellement, gérer une liste d'autorisation pour les audiences que les charges de travail peuvent interroger.

Par défaut, la fédération d'identité de charge de travail s'attend à ce que l'audience d'un jeton d'ID corresponde à l'URL https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID. Assurez-vous que les charges de travail peuvent utiliser une URL en tant qu'audience pour les jetons d'ID, et que les audiences peuvent comporter jusqu'à 180 caractères.

Utiliser des identifiants immuables et non réutilisables dans les revendications des jetons d'ID

Lorsque les clients souhaitent autoriser l'une de leurs charges de travail à accéder aux ressources Google Cloud, ils doivent créer une liaison IAM faisant référence à l'identité de la charge de travail par sujet, groupe ou attribut personnalisé. Le sujet, le groupe et les attributs personnalisés de la charge de travail sont dérivés des revendications du jeton d'ID de la charge de travail.

Si un client crée une liaison IAM faisant référence à une revendication modifiable, sa charge de travail peut accidentellement perdre l'accès lorsque la valeur de la revendication change. Par exemple, un client peut créer une liaison IAM faisant référence au nom de sa charge de travail. Si le client renomme ensuite la charge de travail, il est possible que la liaison IAM ne s'applique plus.

Pire encore, des acteurs malintentionnés peuvent tenter d'obtenir un accès non autorisé à d'autres ressources en renommant délibérément des charges de travail ou en modifiant l'environnement d'une charge de travail pour simuler l'identité d'une autre charge de travail.

Pour aider les clients à éviter ces problèmes de spoofing, assurez-vous que les jetons d'ID contiennent des identifiants immuables et non réutilisables.

Inclure des informations de contexte dans les jetons d'ID

Plutôt que d'accorder aux charges de travail un accès inconditionnel aux ressources Google Cloud, les clients peuvent souhaiter limiter l'accès de sorte qu'une charge de travail ne puisse obtenir des identifiants Google que lorsque certains critères supplémentaires sont remplis.

Pour permettre aux clients de configurer de telles restrictions, incluez dans le jeton d'ID des revendications supplémentaires contenant des informations contextuelles. Voici quelques exemples d'informations contextuelles :

  • Informations sur l'utilisateur qui possède ou a démarré la charge de travail
  • Motif et mode de démarrage de la charge de travail
  • Requête en cours de traitement par la charge de travail

Les clients peuvent utiliser ces revendications pour configurer des conditions d'attribut, ou les utiliser dans des identifiants de comptes principaux.

Limiter la durée de vie du jeton d'ID à 60 minutes

Les jetons d'ID ont une durée de vie limitée déterminée par la revendication exp. Lorsqu'une charge de travail utilise un jeton d'ID pour effectuer un échange de jetons, la fédération d'identité de charge de travail valide la revendication exp du jeton d'ID et émet un jeton STS valide tant que le jeton d'entrée est valide, mais au maximum pendant une heure.

L'utilisation de jetons d'identification valides pendant plus d'une heure n'a aucun effet sur la fédération d'identité de charge de travail, mais peut augmenter les risques en cas de fuite accidentelle d'un jeton d'ID. L'utilisation d'une durée de vie nettement inférieure à une heure peut contribuer à réduire ces risques, mais peut entraîner des échanges de jetons fréquents et réduire les performances.

Étapes suivantes