Configura la federación de identidades de carga de trabajo

En esta guía, se describe cómo usar las credenciales emitidas por un proveedor de identidad externo para actuar en nombre de una cuenta de servicio y acceder a los recursos en Google Cloud. Este proceso se llama federación de Workload Identity.

Los casos de uso comunes para la federación de Workload Identity incluyen los siguientes:

  • Habilitar una aplicación en segundo plano o una canalización de integración continua/entrega continua (CI/CD) que se ejecute fuera de Google Cloud para acceder a los recursos y las API de Google Cloud
  • Permitir que los usuarios de una aplicación web que se ejecuta fuera de Google Cloud accedan a los datos almacenados en un servicio de Google Cloud, como Cloud Storage o BigQuery

A fin de usar la federación de Workload Identity, configura Google Cloud para confiar en un la Vista previa del proveedor de identidad externo, como Amazon Web Services (AWS), Azure Active Directory (AD), un proveedor de identidad compatible con OIDC o SAML 2.0. Luego, las aplicaciones pueden usar credenciales emitidas por el proveedor de identidad externo para actuar en nombre de una cuenta de servicio mediante estos pasos:

  1. Obtén una credencial del proveedor de identidad de confianza.
  2. Intercambia la credencial por un token del servicio de tokens de seguridad.
  3. Usa el token del servicio de tokens de seguridad para actuar en nombre de una cuenta de servicio y obtener un token de acceso de Google de corta duración.

Si usas la federación de Workload Identity, puedes evitar la necesidad de almacenar y administrar claves de cuentas de servicio.

Antes de comenzar

  • Habilita las API de IAM, Resource Manager, Service Account Credentials, and Security Token Service.

    Habilita las API

  • Asegúrate de tener las funciones de administrador de grupos de Workload Identity (roles/iam.workloadIdentityPoolAdmin) y administrador de cuenta de servicio (roles/iam.serviceAccountAdmin) en el proyecto.

    De manera alternativa, la función básica de propietario de IAM (roles/owner) también incluye permisos para configurar la federación de identidades. No deberías otorgar funciones básicas en un entorno de producción, pero puedes otorgarlas en un entorno de desarrollo o de prueba.

  • Instrucciones adicionales específicas del proveedor

    SAML

    Si planeas configurar la federación mediante un proveedor de identidad compatible con SAML 2.0, también debes completar los siguientes pasos.

    • Identifica qué proyecto usarás cuando configures la federación de Workload Identity.

    • Solicita al equipo de cuentas de Google Cloud que solicite acceso a la vista previa de SAML 2.0 de tu proyecto. El equipo de cuentas de Google Cloud te enviará una notificación cuando tengas acceso a la vista previa.

    • Debes usar la herramienta de gcloud para configurar la federación de Workload Identity desde un proveedor de identidad SAML 2.0. Configura billing/quota_project para el proyecto al que se le otorgó acceso a la vista previa de SAML.

Prepara el proveedor de identidad externo

Para usar la federación de Workload Identity, debes configurar un grupo de Workload Identity y un proveedor de Workload Identity en tu proyecto:

AWS

Los usuarios de AWS y las funciones de AWS pueden usar credenciales de seguridad de AWS permanentes o temporales para robar la identidad de una cuenta de servicio en Google Cloud.

Para permitir el uso de credenciales de seguridad de AWS, debes configurar el grupo de identidades de carga de trabajo para que confíe en tu cuenta de AWS. Los tokens de credenciales de seguridad que se emiten para esta cuenta de AWS se reconocen mediante la federación de Workload Identity y puedes usar los tokens a fin de obtener credenciales de cuenta de servicio de corta duración.

Azure

Los usuarios y principales de Azure pueden usar los tokens de acceso de Azure AD para actuar en nombre de una cuenta de servicio en Google Cloud.

Para permitir el uso de tokens de acceso de Azure AD, debes configurar el grupo de identidades de carga de trabajo para que confíe en una aplicación de Azure AD. Los tokens de acceso emitidos para esta aplicación se reconocen mediante la federación de Workload Identity, y puedes usar los tokens para obtener credenciales de cuenta de servicio de corta duración.

Como práctica recomendada, debes crear una aplicación nueva en Azure AD y usarla solo para obtener las credenciales de Google Cloud:

  1. Crea una aplicación y un principal del servicio de Azure AD.

  2. Configura un URI de ID de aplicación para la aplicación.

    En lugar de definir un URI de ID de aplicación personalizado, puedes usar el siguiente URI:

    https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID
    

    Reemplaza los siguientes valores:

    • PROJECT_NUMBER: Es el número del proyecto de Google Cloud que usas para crear el grupo de Workload Identity.
    • POOL_ID: Es el ID que elijas que identifique el grupo de Workload Identity. Debes usar el mismo ID cuando crees el grupo de Workload Identity más adelante.
    • PROVIDER_ID: Es el ID que elijas que identifique al proveedor de grupos de Workload Identity. Debes usar el mismo ID cuando crees el proveedor de grupos de Workload Identity más adelante.

    Este formato garantiza que el URI de ID de aplicación identifique de forma única a un proveedor de grupo de Workload Identity.

Necesitarás el URI de ID de aplicación más adelante cuando configures el proveedor de grupo de Workload Identity.

A fin de permitir que una aplicación obtenga tokens de acceso para la aplicación de Azure AD, puedes usar las identidades administradas:

  1. Crea una identidad administrada. Toma nota del ID de objeto de la identidad administrada. La necesitarás más adelante cuando configures el robo de identidad.

  2. Asigna la identidad administrada a una máquina virtual o a otro recurso que ejecute tu aplicación.

Acciones de GitHub

Puedes permitir que un flujo de trabajo de acciones de GitHub use un token de OIDC de GitHub para actuar en nombre de una cuenta de servicio en Google Cloud.

Para permitir el uso de estos tokens, debes configurar el grupo de Workload Identity para que confíe en los tokens de OIDC que emite GitHub. Los tokens de ID emitidos para flujos de trabajo se reconocen mediante la federación de Workload Identity, y puedes usar los tokens a fin de obtener credenciales de cuenta de servicio de corta duración.

OIDC

Puedes permitir que los usuarios y las aplicaciones actúen en nombre de una cuenta de servicio en Google Cloud mediante tokens de ID o con token de acceso con formato token web JSON que emite un proveedor de identidad compatible con OIDC.

A fin de permitir el uso de estos tokens, debes configurar el grupo de Workload Identity para que confíe en tu proveedor de identidad externo. La federación de Workload Identity reconoce los tokens que emite el proveedor de identidad externo, y puedes usarlos para obtener las credenciales de corta duración de la cuenta de servicio.

Para usar la federación de Workload Identity, el URI de metadatos de OIDC del proveedor de identidad debe ser accesible de forma pública a través de Internet y usar el extremo ISSUER/.well-known/openid-configuration, en el que ISSUER es la URL de la entidad emisora que identifica de forma única a tu proveedor. Google consulta el extremo de metadatos para obtener el conjunto de claves web JSON (JWKS) de tu proveedor y, luego, usa este conjunto de claves a fin de validar tokens.

Por lo general, es mejor usar tokens de ID cuando realizas un intercambio de tokens, ya que estos reflejan la identidad del usuario. Si decides usar tokens de acceso, configura una aplicación o un recurso dedicado en tu proveedor de identidad con el único propósito de obtener las credenciales de Google Cloud.

SAML

Puedes permitir que los usuarios y las aplicaciones actúen en nombre de una cuenta de servicio en Google Cloud mediante aserciones que emite un proveedor de identidad compatible con SAML 2.0. No se admite la federación mediante aserciones encriptadas.

Configura tu proveedor de identidad SAML para emitir aserciones con el proveedor del grupo de Workload Identity como público en el formato https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID.

Si deseas permitir el uso de estas aserciones, debes configurar el grupo de Workload Identity para que confíe en tu proveedor de identidad externo mediante el documento de metadatos de tu proveedor de identidad SAML.

Luego, la federación de Workload Identity reconoce las aserciones que emite el proveedor de identidad externo y puedes usar los tokens para obtener credenciales de cuenta de servicio de corta duración.

Configura la federación

Para federar con tu proveedor de identidad externo, debes hacer lo siguiente:

  1. Prepara un proyecto de Google Cloud que contendrá el grupo y el proveedor de Workload Identity.
  2. Define una asignación de atributos y una condición de atributo opcional que asigne las credenciales del proveedor de identidad a las identidades externas.
  3. Crea un proveedor y un grupo de Workload Identity

En las siguientes secciones, se te guiará a través de este proceso.

Prepara el proyecto

Selecciona y prepara el proyecto que contendrá el grupo y el proveedor de Workload Identity:

  1. Asegúrate de tener las funciones de administrador de grupos de Workload Identity (roles/iam.workloadIdentityPoolAdmin) y administrador de cuenta de servicio (roles/iam.serviceAccountAdmin) en el proyecto.

    De manera alternativa, la función básica de propietario de IAM (roles/owner) también incluye permisos para configurar la federación de identidades. No deberías otorgar funciones básicas en un entorno de producción, pero puedes otorgarlas en un entorno de desarrollo o de prueba.

  2. Actualiza la política de la organización para permitir la federación.

  3. Habilita las API de IAM, Resource Manager, Service Account Credentials, and Security Token Service (STS).

    Habilita las API

Define una condición y la asignación de atributos

Define una asignación de atributos y una condición de atributo opcional que asigne las credenciales del proveedor de identidad a las identidades externas.

Las credenciales emitidas por el proveedor de identidad externo contienen uno o más atributos, también conocidos como reclamaciones. La federación de identidades de cargas de trabajo hace referencia a estos atributos como atributos de aserción y les agrega el prefijo assertion.

Una asignación de atributos te permite asignar atributos de aserción a los atributos de destino predefinidos que reconoce la federación de Workload Identity. Estos son los atributos de destino predefinidos:

Atributo Descripción
google.subject Obligatorio. Un identificador único para el usuario. Este atributo se usa en las vinculaciones de funciones principal:// de IAM y aparece en los registros de Cloud Logging. El valor debe ser único y no puede superar los 127 caracteres.
google.groups Opcional. Un conjunto de grupos a los que pertenece la identidad. Este atributo se usa en las vinculaciones de funciones principalSet:// de IAM para otorgar acceso a todos los miembros de un grupo.
attribute.NAME Opcional. Puedes definir hasta 50 atributos personalizados y usar estos atributos en las vinculaciones de funciones principalSet:// de IAM para otorgar acceso a todas las identidades con un atributo determinado.

Una asignación de atributos tiene el formato TARGET_ATTRIBUTE=SOURCE_EXPRESSION. Consulta los ejemplos siguientes:

  • Esta asignación asigna el atributo de aserción sub a google.subject:

    google.subject=assertion.sub
    
  • Esta asignación usa una expresión Common Expression Language (CEL) para concatenar varios atributos de aserción:

    google.subject="myprovider::" + assertion.aud + "::" + assertion.sub
    
  • Esta asignación usa otra expresión CEL para asignar un atributo de aserción con valor GUID workload_id a un nombre y asigna el resultado a un atributo personalizado llamado attribute.my_display_name:

    attribute.my_display_name={
      "8bb39bdb-1cc5-4447-b7db-a19e920eb111": "Workload1",
      "55d36609-9bcf-48e0-a366-a3cf19027d2a": "Workload2"
    }[assertion.workload_id]
    
  • En esta asignación se usan operadores y funciones lógicas CEL para establecer un atributo personalizado llamado attribute.environment en prod o test, según Amazon Resource Name (ARN):

    attribute.environment=assertion.arn.contains(":instance-profile/Production") ? "prod" : "test"
    
  • Esta asignación usa la función extract para propagar un atributo personalizado aws_role con el nombre de la función asumida o, si no se supone ninguna función, con el ARN

    attribute.aws_role=assertion.arn.contains('assumed-role') ? assertion.arn.extract('{account_arn}assumed-role/') + 'assumed-role/' + assertion.arn.extract('assumed-role/{role_name}/') : assertion.arn
    

De manera opcional, también puedes definir una condición de atributo. Las condiciones de los atributos son expresiones CEL que pueden verificar los atributos de aserción y los atributos de destino. Si la condición del atributo se evalúa como true para una credencial determinada, se acepta la credencial. De lo contrario, se rechaza la credencial.

A fin de elegir las asignaciones y condiciones de atributos correctas para tu caso de uso, debes decidir si deseas asignar identidades de servicio o usuarios:

  • Si asignas identidades de servicio, puedes habilitar una aplicación en segundo plano o una canalización de CI/CD que se ejecute fuera de Google Cloud a fin de obtener credenciales de corta duración para Google Cloud. La aplicación obtiene estas credenciales de corta duración en su nombre, sin la participación del usuario.
  • Si asignas identidades de usuario, puedes habilitar a los usuarios de una aplicación que se ejecuta fuera de Google Cloud a fin de obtener credenciales de corta duración para Google Cloud. La aplicación obtiene estas credenciales de corta duración en nombre de un usuario.

Asigna identidades de servicio

AWS

Las asignaciones de atributos pueden usar los campos de respuesta para GetCallerIdentity como atributos de origen. Esto incluye lo siguiente:

  • account, que contiene el número de cuenta de AWS.
  • arn, que contiene el ARN de AWS de la entidad externa.
  • userid, que contiene el identificador único de la entidad que realiza la llamada.

Si tu aplicación se ejecuta en una instancia de Amazon Elastic Compute Cloud (EC2) con una función adjunta, puedes usar la siguiente asignación de atributos:

google.subject=assertion.arn
attribute.aws_role=assertion.arn.contains('assumed-role') ? assertion.arn.extract('{account_arn}assumed-role/') + 'assumed-role/' + assertion.arn.extract('assumed-role/{role_name}/') : assertion.arn

Esta asignación te permite otorgar la capacidad de actuar en nombre de una cuenta de servicio a instancias de EC2 específicas o por función.

Es posible que tu cuenta de AWS contenga una gran cantidad de usuarios y funciones, pero solo un pequeño subconjunto de ellos puede requerir acceso a los recursos de Google Cloud. Para limitar el conjunto de usuarios y funciones que pueden usar la federación de Workload Identity, usa una condición de atributo. Por ejemplo, la siguiente condición permite que una cuenta específica acceda a los recursos de Google Cloud:

assertion.arn.startsWith('arn:aws:sts::ACCOUNT-ID:assumed-role/')

Azure

Las asignaciones de atributos pueden usar las reclamaciones incorporadas en los tokens de acceso de Azure, incluidas las reclamaciones personalizadas, como atributos de origen.

Para obtener una lista completa de reclamaciones a las que puedes hacer referencia, conéctate a una VM de Azure que tenga una identidad administrada y haz lo siguiente:

  1. Obtén un token de acceso de Azure Instance Metadata Service (IMDS):

    Bash

    curl \
      "http://169.254.169.254/metadata/identity/oauth2/token?resource=APP_ID_URI&api-version=2018-02-01" \
      -H "Metadata: true" | jq -r .access_token
    

    Este comando usa la herramienta de jq. jq está disponible de forma predeterminada en Cloud Shell.

    PowerShell

    $SubjectTokenType = "urn:ietf:params:oauth:token-type:jwt"
    $SubjectToken = (Invoke-RestMethod `
      -Uri "http://169.254.169.254/metadata/identity/oauth2/token?resource=APP_ID_URI&api-version=2018-02-01" `
      -Headers @{Metadata="true"}).access_token
    Write-Host $SubjectToken
    

    Reemplaza APP_ID_URI por el URI de ID de aplicación de la aplicación que configuraste para la federación de Workload Identity.

  2. En un navegador web, ve a https://jwt.ms/ y pega el token de acceso en el cuadro de texto.

  3. Haz clic en Reclamaciones para ver la lista de reclamaciones incorporadas en el token de acceso.

Para autenticar con una principal de servicio, puedes usar la siguiente asignación de atributos:

google.subject=assertion.sub

Para un token de acceso emitido a una identidad administrada, la reclamación sub contiene el ID de objeto de la identidad administrada. Si usas otra reclamación, asegúrate de que sea única y no se pueda reasignar.

En el caso de las identidades de servicio, por lo general, no es necesario crear una asignación para google.groups o ningún atributo personalizado.

A fin de controlar qué identidades pueden obtener credenciales de corta duración para Google Cloud, no definas condiciones de atributos. En su lugar, configura tu aplicación de Azure AD para que use asignaciones de funciones de la aplicación.

Acciones de GitHub

Las asignaciones de atributos pueden usar las reclamaciones incorporadas en el token de OIDC como atributos de origen. Estas son algunas de las funciones:

  • sub: Contiene el nombre del repositorio y la referencia de Git, por ejemplo repo:username/reponame:ref:refs/heads/master.
  • repository: Contiene el nombre del propietario y el repositorio, por ejemplo, username/reponame.
  • repository_owner: Contiene el propietario, que puede ser un nombre de usuario o el nombre de una organización de GitHub.
  • ref: Contiene la referencia de Git, por ejemplo refs/heads/main.

La siguiente asignación de atributos establece google.subject en la reclamación sub desde el token de OIDC de acciones de GitHub. Debido a que la reclamación sub contiene ambas referencias, el nombre del repositorio y la referencia de Git, esta asignación te permite controlar el acceso por repositorio y rama:

google.subject=assertion.sub

Controlar el acceso por repositorio y rama puede ser útil si ciertas ramas (por ejemplo, main) necesitan un acceso diferente a los recursos que otras ramas (por ejemplo, ramas de funciones).

Si no planeas diferenciar el acceso por rama, puedes usar la siguiente asignación de atributos, que establece google.subject en la reclamación repository:

google.subject=assertion.repository

De forma opcional, puedes usar una condición de atributo para definir los requisitos adicionales que deben cumplir los tokens de ID. Por ejemplo, la siguiente condición limita el acceso a los tokens de ID para los flujos de trabajo que usan la rama de Git main:

assertion.ref=='refs/heads/main'

OIDC

Las asignaciones de atributos pueden usar las reclamaciones incorporadas en el token de ID o el token de acceso emitido por el proveedor de identidad externo.

Debes asignar una de estas reclamaciones a google.subject para identificar de forma única al usuario. Para protegerte contra las amenazas de falsificación de identidad, elige un reclamo con un valor único que no pueda cambiarse.

Muchos proveedores de identidad propagan la reclamación sub con un ID inmutable y único. Para estos proveedores de identidad, considera asignar la reclamación de sub a google.subject:

google.subject=assertion.sub

Evita usar una reclamación como email con este propósito. Por lo general, las direcciones de correo electrónico se pueden reasignar o cambiar, por lo que no identifican de forma única y permanente a un usuario.

Es posible que tu proveedor de identidad contenga una gran cantidad de usuarios, pero solo un pequeño subconjunto de ellos puede requerir acceso a los recursos de Google Cloud. Para limitar el conjunto de usuarios y credenciales que pueden usar la federación de Workload Identity, puedes usar una condición de atributo de forma opcional.

Por ejemplo, la siguiente condición restringe el acceso a los tokens que contienen una reclamación service_account personalizada con un valor true:

assertion.service_account==true

SAML

Tus asignaciones de atributos pueden usar los elementos <Subject> y <Attribute> incorporados en la aserción emitida por el proveedor de identidad externo. Se puede hacer referencia a los atributos de SAML mediante las siguientes palabras clave:

  • assertion.subject, contiene el NameID del usuario autenticado que se encontró en el elemento <Subject>.
  • assertion.attributes['ATTRIBUTE_NAME'], contiene una lista de valores para el <Attribute> con nombre similar.

Debes asignar una de estas reclamaciones a google.subject para identificar de forma única al usuario. Para protegerte contra las amenazas de falsificación de identidad, elige un reclamo con un valor único que no pueda cambiarse.

Muchos proveedores de identidad propagan el NameId con un ID inmutable y único. Para estos proveedores de identidad, considera asignar el atributo NameId a google.subject:

google.subject=assertion.subject

Evita usar un atributo como http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress para este fin. Por lo general, las direcciones de correo electrónico se pueden reasignar o cambiar, por lo que no identifican de forma única y permanente a un usuario.

Es posible que tu proveedor de identidad contenga una gran cantidad de usuarios, pero solo un pequeño subconjunto de ellos puede requerir acceso a los recursos de Google Cloud. Para limitar el conjunto de usuarios y credenciales que pueden usar la federación de Workload Identity, puedes usar una condición de atributo de forma opcional.

Por ejemplo, la siguiente condición restringe el acceso a las aserciones que contienen un atributo https://example.com/SAML/Attributes/AllowGcpFederation personalizado con un valor true:

assertion.attributes['https://idp.com/SAML/Attributes/AllowGcpFederation'][0]=='true'

Crea el proveedor y el grupo de Workload Identity

Ya recopilaste toda la información que necesitas para crear un grupo y un proveedor de Workload Identity:

Console

  1. En Cloud Console, ve a la página Nuevo proveedor y grupo de cargas de trabajo.

    Ir a Nuevo proveedor y grupo de cargas de trabajo

  2. En Crear un grupo de identidades, ingresa lo siguiente:

    • Nombre: Es el nombre del grupo. El nombre también se usa como el ID del grupo. No puedes cambiar el ID del grupo más adelante.
    • Descripción: Es el texto que describe el propósito del grupo.
  3. Haga clic en Continuar.

  4. En la lista desplegable Seleccionar un proveedor, selecciona tu proveedor:

    • AWS si federas con AWS.
    • OpenID Connect (OIDC) si federas con un proveedor compatible con OIDC, como Microsoft Azure
    • No puedes configurar la federación de Workload Identity desde un proveedor de identidad SAML 2.0 con Cloud Console. Debes usar la herramienta de gcloud para configurar la federación de Workload Identity desde un proveedor de identidad de SAML 2.0.
  5. En Detalles del proveedor, ingresa los detalles para tu proveedor de identidad:

    AWS

    • Nombre del proveedor: nombre para el proveedor. El nombre también se usa como el ID del proveedor. No puedes cambiar el ID del proveedor más adelante.

    Azure

    • Nombre del proveedor: nombre para el proveedor. El nombre también se usa como el ID del proveedor. No puedes cambiar el ID del proveedor más adelante.
    • URL del emisor: https://sts.windows.net/TENANT_ID en la que TENANT_ID es el ID de usuario (GUID) de tu instancia de Azure AD.

    Acciones de GitHub

    • Nombre del proveedor: nombre para el proveedor. El nombre también se usa como el ID del proveedor. No puedes cambiar el ID del proveedor más adelante.
    • URL del emisor: https://token.actions.githubusercontent.com/

    OIDC

    • Nombre del proveedor: nombre para el proveedor. El nombre también se usa como el ID del proveedor. No puedes cambiar el ID del proveedor más adelante.
    • URL del emisor: La URL del emisor de tu proveedor de identidad.
  6. Haga clic en Continuar.

  7. En Configura los atributos del proveedor, agrega las asignaciones de atributos que identificaste antes.

  8. En Condiciones del atributo, ingresa la condición del atributo que identificaste antes. Deja el campo en blanco si no tienes una condición de atributo.

  9. Haz clic en Guardar para crear el proveedor y el grupo de Workload Identity.

gcloud

  1. Crea un nuevo grupo de Workload Identity:

    gcloud iam workload-identity-pools create POOL_ID \
        --location="global" \
        --description="DESCRIPTION" \
        --display-name="DISPLAY_NAME"
    

    Reemplaza los siguientes valores:

    • POOL_ID: Es el ID único para el grupo.
    • DISPLAY_NAME: es el nombre del grupo.
    • DESCRIPTION: Es la descripción del grupo. Esta descripción aparece cuando se otorga acceso a identidades de grupo.
  2. Agrega un proveedor de grupos de Workload Identity:

    AWS

    gcloud iam workload-identity-pools providers create-aws PROVIDER_ID \
      --location="global"  \
      --workload-identity-pool="POOL_ID" \
      --account-id="AWS_ACCOUNT_ID" \
      --attribute-mapping="MAPPINGS" \
      --attribute-condition="CONDITIONS"
    

    Reemplaza los siguientes valores:

    Ejemplo:

    gcloud iam workload-identity-pools providers create-aws example-provider \
      --location="global"  \
      --workload-identity-pool="pool-1" \
      --account-id="123456789000" \
      --attribute-mapping="google.subject=assertion.arn"
    

    Azure

    gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \
        --location="global" \
        --workload-identity-pool="POOL_ID" \
        --issuer-uri="https://sts.windows.net/TENANT_ID" \
        --allowed-audiences="APPLICATION_ID_URI" \
        --attribute-mapping="MAPPINGS" \
        --attribute-condition="CONDITIONS"
    

    Reemplaza los siguientes valores:

    Ejemplo:

    gcloud iam workload-identity-pools providers create-oidc example-provider \
        --location="global" \
        --workload-identity-pool="pool-1" \
        --issuer-uri="https://sts.windows.net/00000000-1111-2222-3333-444444444444" \
        --allowed-audiences="api://my-app" \
        --attribute-mapping="google.subject=assertion.sub,google.groups=assertion.groups"
    

    Acciones de GitHub

    gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \
        --location="global" \
        --workload-identity-pool="POOL_ID" \
        --issuer-uri="https://token.actions.githubusercontent.com/" \
        --attribute-mapping="MAPPINGS" \
        --attribute-condition="CONDITIONS"
    

    Reemplaza los siguientes valores:

    OIDC

    gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \
        --location="global" \
        --workload-identity-pool="POOL_ID" \
        --issuer-uri="ISSUER" \
        --allowed-audiences="AUDIENCE" \
        --attribute-mapping="MAPPINGS" \
        --attribute-condition="CONDITIONS"
    

    Reemplaza los siguientes valores:

    • PROVIDER_ID: Es el ID único para el proveedor.
    • POOL_ID: Es el ID del grupo.
    • ISSUER: Es el URI de la entidad emisora, como se define en los metadatos de OIDC.
    • AUDIENCE: Es el público esperado de los tokens de ID, para muchos proveedores, el público coincide con el ID de cliente.
    • MAPPINGS: Es la lista separada por comas de las asignaciones de atributos que identificaste antes.
    • CONDITIONS: Es la condición de atributo que identificaste antes. Quita el parámetro si no tienes una condición de atributo.

    SAML

    gcloud iam workload-identity-pools providers create-saml PROVIDER_ID \
        --location="global" \
        --workload-identity-pool="POOL_ID" \
        --idp-metadata-path="IDP_METADATA_PATH" \
        --attribute-mapping="MAPPINGS" \
        --attribute-condition="CONDITIONS"
    

    Reemplaza los siguientes valores:

    Ejemplo:

    gcloud iam workload-identity-pools providers create-saml example-provider \
        --location="global" \
        --workload-identity-pool="pool-1" \
        --idp-metadata-path="/path/to/idp_metadata.xml" \
        --attribute-mapping="google.subject=assertion.subject,google.groups=assertion.attributes.groups"
    

    Si recibes el siguiente error, haz lo siguiente:

    INVALID_ARGUMENT: Invalid WorkloadIdentityPoolProvider IDP configuration: PROVIDERCONFIG_NOT_SET.
    

    verifica que completaste los pasos descritos en la página de solicitud de acceso a la vista previa de SAML.

¿Qué sigue?