Configura la federación de Workload Identity con canalizaciones de implementación

En esta guía, se describe cómo usar la federación de identidades para cargas de trabajo para permitir que las canalizaciones de implementación se autentiquen en Google Cloud.

Según el sistema de CI/CD que uses, las canalizaciones de implementación pueden tener acceso a credenciales ambientales y específicas del entorno. Por ejemplo:

Las canalizaciones de Azure DevOps pueden usar una conexión del servicio de federación de identidades para cargas de trabajo de Microsoft Entra para obtener un token de ID que identifica de forma única el proyecto de Azure DevOps.
Los flujos de trabajo de GitHub Actions pueden obtener un token de OIDC de GitHub que identifica de forma única el flujo de trabajo y su repositorio.
SaaS de GitLab permite que los trabajos de CI/CD accedan a un token de ID que identifica el trabajo y su proyecto, entorno y repositorio de manera única.
Terraform Cloud puede proporcionar un token de OIDC para tu configuración de Terraform que identifica de manera inequívoca el lugar de trabajo y el entorno.

Puedes configurar las canalizaciones de implementación para usar estas credenciales a fin de autenticarte en Google Cloud mediante la federación de identidades para cargas de trabajo. Con este enfoque, se elimina la carga de mantenimiento y seguridad asociada con las claves de las cuentas de servicio.

Antes de comenzar

Configura la autenticación

Select the tab for how you plan to use the samples on this page:

Console

When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

gcloud

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

Python

Para usar las muestras de Python de esta página en un entorno de desarrollo local, instala e inicializa gcloud CLI y, luego, configura las credenciales predeterminadas de la aplicación con tus credenciales de usuario.

Install the Google Cloud CLI.
To initialize the gcloud CLI, run the following command:
```
gcloud init
```
If you're using a local shell, then create local authentication credentials for your user account:
```
gcloud auth application-default login
```
You don't need to do this if you're using Cloud Shell.

Si deseas obtener más información, consulta Configura la autenticación para un entorno de desarrollo local en la documentación de autenticación de Google Cloud.

Roles obligatorios

Para obtener los permisos que necesitas para configurar la federación de identidades para cargas de trabajo, pídele a tu administrador que te otorgue el rol de IAM de Administrador de grupos de identidades para cargas de trabajo (roles/iam.workloadIdentityPoolAdmin) en el proyecto. Para obtener más información sobre cómo otorgar roles, consulta Administra el acceso a proyectos, carpetas y organizaciones.

También puedes obtener los permisos necesarios mediante roles personalizados o cualquier otro rol predefinido.

De manera alternativa, el rol básico 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.

Prepara el IdP externo

Azure DevOps

Para permitir que una canalización de Azure DevOps se autentique en Google Cloud, primero debes configurar una conexión de servicio para Azure Resource Manager. Esta conexión permite que la canalización obtenga un token de ID, que luego puede intercambiar por credenciales de Google Cloud.

A fin de crear una conexión de servicio para Azure Resource Manager, haz lo siguiente:

En Azure DevOps, abre tu proyecto y ve a Configuración del proyecto.
Ve a Canalizaciones > Conexiones de servicio.
Haz clic en Crear conexión de servicio.
Selecciona Azure Resource Manager.
Haz clic en Siguiente.
Selecciona Federación de identidades para cargas de trabajo (automática).
Haz clic en Siguiente.
Establece la siguiente configuración:
- Nivel de permiso: Selecciona una suscripción.
  
  Debes seleccionar una suscripción incluso si no planeas usar la conexión del servicio para acceder a los recursos de Azure.
- Nombre de conexión del servicio: ingresa un nombre como google-cloud.
Haz clic en Guardar.

En un paso posterior, necesitarás la entidad emisora y el identificador de asunto de la conexión del servicio. Para buscar estos detalles, haz lo siguiente:

Haz clic en la conexión de servicio que acabas de crear.
Haz clic en Administrar principal de servicio.
Ve a Certificado y secretos > Credenciales federadas.
Haz clic en la credencial federada.
En la página Editar una credencial, busca los siguientes identificadores:
- Emisor: identifica de forma única tu organización de Azure DevOps
- Identificador de asunto: identifica de forma única la conexión de servicio

Azure DevOps otorga acceso de forma automática a la suscripción que seleccionaste como alcance al principal del servicio asociado con tu nueva conexión de servicio. Debido a que no planeas usar la conexión de servicio para acceder a los recursos de Azure, puedes revocar este acceso si haces lo siguiente:

En el portal de Azure, abre la suscripción que seleccionaste como permiso.
Ve a Control de acceso (IAM) > Asignaciones de roles.
Busca la asignación de rol para la conexión de servicio y quítala.

Acciones de GitHub

No es necesario que realices ningún cambio de configuración en la cuenta de GitHub.

Después de configurar un grupo de Workload Identity para que confíe en tu repositorio de GitHub, puedes permitir que los flujos de trabajo en ese repositorio usen su token de OIDC de GitHub a fin de obtener credenciales de Google Cloud de corta duración.

SaaS de GitLab

No es necesario que realices ningún cambio de configuración en la cuenta de GitLab.

Después de configurar un grupo de Workload Identity para que confíe en tu grupo de GitLab, puedes habilitar la federación de Workload Identity para trabajos de CI/CD individuales.

Terraform Cloud

No es necesario que realices ningún cambio de configuración en la cuenta de Terraform de la nube.

Después de configurar un grupo de Workload Identity para que confíe en Terraform Cloud, puedes habilitar la federación de Workload Identity para lugares de trabajo individuales.

Configura la federación de Workload Identity

Debes realizar estos pasos para cada organización de GitHub, grupo de GitLab o Terraform Cloud.

Para comenzar a configurar la federación de identidades para cargas de trabajo, haz lo siguiente:

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Go to project selector

usar un proyecto exclusivo para administrar los grupos y los proveedores de identidades para cargas de trabajo

Make sure that billing is enabled for your Google Cloud project.

Enable the IAM, Resource Manager, Service Account Credentials, and Security Token Service APIs.

Enable the APIs

Define una asignación de atributos

Las credenciales específicas del entorno de la canalización de implementación pueden contener varios atributos, y debes decidir qué atributo deseas usar como identificador de asunto (google.subject) en Google Cloud.

De manera opcional, puedes mapear atributos adicionales. Luego, puedes hacer referencia a estos atributos adicionales cuando otorgas acceso a los recursos.

Azure DevOps

El token de ID de Azure DevOps incluye una reclamación sub que contiene el identificador de asunto de la conexión del servicio. El identificador de asunto usa el siguiente formato:

sc://ORGANIZATION/PROJECT/CONNECTION

Usa la siguiente asignación de atributos para asignar este identificador a google.subject:

google.subject=assertion.sub

Acciones de GitHub

Las asignaciones de atributos pueden usar cualquiera de las reclamaciones en el token de OIDC de acciones de GitHub. GitHub controla las claves de reclamación de token y sus valores. Como mínimo, debes asignar google.subject a assertion.sub, que corresponde al asunto de OIDC de acciones de GitHub:

google.subject=assertion.sub

El valor del asunto del token de OIDC de acciones de GitHub puede variar según el evento de origen. Otros atributos de reclamación pueden incluir lo siguiente:

repository: Contiene el nombre del propietario y el repositorio, por ejemplo, "google/guava".
repository_id: Contiene el ID del repositorio único, por ejemplo, "20300177".
repository_owner: Contiene el propietario, que puede ser un nombre de usuario o el nombre de una organización de GitHub, por ejemplo "google".
repository_owner_id: Contiene el ID del propietario único, por ejemplo, "1342004".

La lista anterior es un subconjunto de las reclamaciones posibles. Consulta la documentación de GitHub sobre reclamaciones de ejemplo para obtener una lista completa. Asegúrate de mapear todas las reclamaciones que planeas usar como condiciones de atributos o como parte de una condición principalSet futura.

SaaS de GitLab

Las asignaciones de atributos pueden usar las reclamaciones incorporadas en el token de ID de GitLab como atributos de origen, incluidos los siguientes:

sub: Es el nombre del proyecto y la referencia de Git, por ejemplo, project_path:groupname/projectname:ref_type:branch:ref:main.
namespace_id: el ID del grupo único.
project_id: el ID del proyecto único.
user_id: el ID de usuario único.
environment: el entorno al que se aplica el trabajo.
ref_path: la referencia de Git, por ejemplo refs/heads/main.

La siguiente asignación de atributos establece google.subject como la reclamación sub desde el token de ID de GitLab. Debido a que la reclamación sub contiene ambas referencias, el nombre del proyecto 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).

En algunos casos, podría ser suficiente para diferenciar solo el acceso por proyecto o grupo. Por lo tanto, la siguiente asignación incluye dos atributos adicionales que contienen el project_id y el namespace_id de GitLab:

google.subject=assertion.sub
attribute.project_id=assertion.project_id
attribute.namespace_id=assertion.namespace_id

Terraform Cloud

Las asignaciones de atributos pueden usar las reclamaciones incorporadas en el token de OIDC de Terraform Cloud, incluidas las siguientes opciones:

terraform_organization_id: contiene el ID único de la organización, por ejemplo, org-xxxxxxxxxxxxxxxx.
terraform_workspace_id: contiene el ID único del lugar de trabajo, por ejemplo, ws-xxxxxxxxxxxxxxxx.
terraform_workspace_name: contiene el nombre visible del lugar de trabajo.
sub: contiene el nombre visible de la organización, el lugar de trabajo y la fase, por ejemplo, organization:example-org:workspace:example-workspace:run_phase:apply.

La siguiente asignación de atributos establece google.subject en la reclamación terraform_workspace_id desde el token de OIDC de Terraform Cloud:

google.subject=assertion.terraform_workspace_id

Esta asignación te permite controlar el acceso a los recursos de Google Cloud por lugar de trabajo.

Define 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. Debes tener una asignación de atributos para todos los campos de condición de atributos.

Azure DevOps

De forma opcional, usa una condición de atributo para restringir el acceso a ciertas conexiones de servicio. Por ejemplo, la siguiente condición limita el acceso a las conexiones en un proyecto de Azure DevOps determinado:

assertion.sub.startsWith('sc://ORGANIZATION/PROJECT/')

Reemplaza lo siguiente:

ORGANIZATION: el nombre de tu organización de Azure DevOps.
PROJECT: Es el nombre de tu proyecto de Azure DevOps.

Acciones de GitHub

Usa la siguiente condición para restringir el acceso a los tokens que emite tu organización de GitHub:

assertion.repository_owner=='ORGANIZATION'

Reemplaza ORGANIZATION por el nombre de tu organización de GitHub.

De forma opcional, extiende la condición del atributo para restringir el acceso a un subconjunto de flujos de trabajo o ramas. Por ejemplo, la siguiente condición limita el acceso a los flujos de trabajo que usan la rama de Git main:

assertion.repository_owner=='ORGANIZATION' && assertion.ref=='refs/heads/main'

SaaS de GitLab

Usa la siguiente condición de atributo para restringir el acceso a los tokens que emite tu grupo de GitLab

assertion.namespace_id=='GROUP_ID'

Reemplaza GROUP_ID por el ID del grupo que se muestra en la página principal de tu grupo de GitLab.

De forma opcional, extiende la condición del atributo para restringir el acceso a un subconjunto de proyectos, ramas o entornos. Por ejemplo, la siguiente condición limita el acceso a los trabajos que usan el entorno production:

assertion.namespace_id=='GROUP_ID' && assertion.environment=='production'

Terraform Cloud

Usa la siguiente condición de atributo para restringir el acceso a los tokens que emite tu organización de Terraform Cloud:

assertion.terraform_organization_id=='ORGANIZATION_ID'

Reemplaza ORGANIZATION_ID por el ID único de tu organización, por ejemplo, org-xxxxxxxxxxxxxxxx. De forma opcional, extiende la condición del atributo para restringir el acceso a un subconjunto de flujos de trabajo o ramas. Por ejemplo, la siguiente condición de atributo limita el acceso a un lugar de trabajo específico:

assertion.terraform_organization_id=='ORGANIZATION_ID' && assertion.terraform_workspace_id=='WORKSPACE_ID'

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

En la consola de Google Cloud, ve a la página Proveedor y grupo de cargas de trabajo nuevos.

Ir a Nuevo proveedor y grupo de cargas de trabajo
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.
Haz clic en Continuar.
Establece la configuración del proveedor:
Azure DevOps
- Selecciona un proveedor: OpenID Connect (OIDC).
- Nombre del proveedor: el nombre del proyecto de Azure DevOps o un nombre personalizado.
- ID de proveedor: el nombre del proyecto de Azure DevOps o un ID personalizado. No puedes cambiar el ID del proveedor más adelante.
- URL del emisor: La entidad emisora de la conexión de servicio que buscaste antes.
- Públicos: Selecciona Públicos permitidos y pega el siguiente valor
  api://AzureADTokenExchange
Acciones de GitHub
- Selecciona un proveedor: OpenID Connect (OIDC).
- Nombre del proveedor: nombre para el proveedor.
- ID de proveedor: ID para el proveedor. No puedes cambiar el ID del proveedor más adelante.
- URL del emisor: https://token.actions.githubusercontent.com/
- Públicos: Público predeterminado
SaaS de GitLab
- Selecciona un proveedor: OpenID Connect (OIDC).
- Nombre del proveedor: nombre para el proveedor.
- ID de proveedor: ID para el proveedor. No puedes cambiar el ID del proveedor más adelante.
- URL del emisor: https://gitlab.com
- Públicos: Público predeterminado
Terraform Cloud
- Selecciona un proveedor: OpenID Connect (OIDC).
- Nombre del proveedor: nombre para el proveedor.
- ID de proveedor: ID para el proveedor. No puedes cambiar el ID del proveedor más adelante.
- URL del emisor: https://app.terraform.io
- Públicos: Público predeterminado
Haz clic en Continuar.
En Configura los atributos del proveedor, agrega las asignaciones de atributos que identificaste antes.
En Condiciones del atributo, ingresa la condición del atributo que identificaste antes.
Haz clic en Guardar para crear el proveedor y el grupo de Workload Identity.

gcloud

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: el ID único para el grupo
- DISPLAY_NAME: el nombre del grupo
- DESCRIPTION: la descripción del grupo. Esta descripción aparece cuando se otorga acceso a identidades de grupo
Agrega un proveedor de grupos de Workload Identity:
Azure DevOps
```
gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \
    --location="global" \
    --workload-identity-pool="POOL_ID" \
    --issuer-uri="ISSUER" \
    --attribute-mapping="MAPPINGS" \
    --attribute-condition="CONDITIONS"
```
Reemplaza los siguientes valores:
- PROVIDER_ID: el nombre del proyecto de Azure DevOps o un ID personalizado para el proveedor.
- POOL_ID: el ID del grupo.
- ISSUER: la entidad emisora de la conexión del servicio que buscaste antes.
- MAPPINGS: una la lista separada por comas de las asignaciones de atributos que identificaste antes
- CONDITIONS: la condición de atributo que identificaste antes
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/" \
    --allowed-audiences="api://AzureADTokenExchange" \
    --attribute-mapping="MAPPINGS" \
    --attribute-condition="CONDITIONS"
```
Reemplaza los siguientes valores:
- PROVIDER_ID: el ID único para el proveedor
- POOL_ID: el ID del grupo.
- MAPPINGS: una la lista separada por comas de las asignaciones de atributos que identificaste antes
- CONDITIONS: la condición de atributo que identificaste antes
SaaS de GitLab
```
gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \
    --location="global" \
    --workload-identity-pool="POOL_ID" \
    --issuer-uri="https://gitlab.com" \
    --attribute-mapping="MAPPINGS" \
    --attribute-condition="CONDITIONS"
```
Reemplaza los siguientes valores:
- PROVIDER_ID: el ID único para el proveedor
- POOL_ID: el ID del grupo.
- MAPPINGS: una la lista separada por comas de las asignaciones de atributos que identificaste antes
- CONDITIONS: la condición de atributo que identificaste antes
Terraform Cloud
```
gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \
    --location="global" \
    --workload-identity-pool="POOL_ID" \
    --issuer-uri="https://app.terraform.io" \
    --attribute-mapping="MAPPINGS" \
    --attribute-condition="CONDITIONS"
```
Reemplaza los siguientes valores:
- PROVIDER_ID: el ID único para el proveedor.
- POOL_ID: el ID del grupo.
- MAPPINGS: una lista separada por comas de las asignaciones de atributos que identificaste antes.
- CONDITIONS: la condición de atributo que identificaste antes.

Actualiza la condición de atributo en un proveedor de identidades para cargas de trabajo

En esta sección, se describe cómo puedes actualizar la condición del atributo en un proveedor de grupos de identidades para cargas de trabajo existente para restringir el acceso a los tokens que emite la organización de GitHub, el grupo de GitLab o la organización de Terraform Cloud.

Para encontrar la condición de atributo recomendada para tu canalización, consulta Define una condición de atributo.

Console

En la consola de Google Cloud, ve a la página Grupos de Workload Identity.

Ir a Grupos de Workload Identity
Busca el grupo de identidades de la carga de trabajo que contiene el proveedor y, luego, haz clic en el ícono Expandir nodo para el grupo.
Busca el proveedor de grupos de identidades para cargas de trabajo que deseas editar y haz clic en Editar.
En Condiciones del atributo, ingresa la condición del atributo que identificaste antes.
Para actualizar el proveedor y el grupo de identidades para cargas de trabajo, haz clic en Guardar.

gcloud

Para actualizar el proveedor de grupos de identidades para cargas de trabajo, ejecuta el siguiente comando:

gcloud iam workload-identity-pools providers update-oidc PROVIDER_ID \
    --location="global" \
    --workload-identity-pool="POOL_ID" \
    --attribute-condition="CONDITIONS"

Reemplaza los siguientes valores:

PROVIDER_ID: el ID único para el proveedor
POOL_ID: el ID del grupo.
CONDITIONS: Es la condición de atributo que identificaste antes.

Autentica una canalización de implementación

Debes realizar estos pasos para cada flujo de trabajo de GitHub Actions o lugar de trabajo de Terraform Cloud.

Permite que tu carga de trabajo externa acceda a los recursos de Google Cloud

Para completar las instrucciones más adelante en esta guía, debes configurar la identidad temporal como cuenta de servicio como se describe en esta sección.

Para proporcionar a tu carga de trabajo acceso a los recursos de Google Cloud, te recomendamos que otorgues acceso directo a los recursos al principal. En este caso, el principal es el usuario federado. Algunos productos de Google Cloud tienen limitaciones de las APIs de Google Cloud. Si tu carga de trabajo llama a un extremo de API que tiene una limitación, puedes usar el robo de identidad temporal como cuenta de servicio. En este caso, el principal es la cuenta de servicio de Google Cloud, que actúa como la identidad. Otorga acceso a la cuenta de servicio en el recurso.

Acceso directo a recursos

Puedes otorgar acceso a una identidad federada directamente en los recursos con la consola de Google Cloud o gcloud CLI.

Console

Para usar la consola de Google Cloud para otorgar roles de IAM directamente en un recurso, debes ir a la página del recurso y, luego, otorgar el rol. En el siguiente ejemplo, se muestra cómo ir a la página de Cloud Storage y otorgar el rol de visualizador de objetos de almacenamiento (roles/storage.objectViewer) a una identidad federada directamente en un bucket de Cloud Storage.

En la consola de Google Cloud, ve a la página Buckets de Cloud Storage.
Ir a Buckets
En la lista de buckets, haz clic en el nombre del bucket para el que deseas otorgar el rol.
Elige la pestaña Permisos cerca de la parte superior de la página.
Haz clic en el botón Otorgar acceso.

Aparecerá el cuadro de diálogo Agregar principales.
En el campo Nuevas principales, ingresa una o más identidades que necesiten acceso a tu bucket.
Por tema
```
principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT
```
Reemplaza lo siguiente:
- PROJECT_NUMBER: el número del proyecto
- POOL_ID: el ID del grupo de cargas de trabajo
- SUBJECT: El sujeto individual asignado desde tu IdP, por ejemplo, administrator@example.com
Por grupo
```
principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP
```
Reemplaza lo siguiente:
- PROJECT_NUMBER: el número del proyecto
- WORKLOAD_POOL_ID: el ID del grupo de cargas de trabajo
- GROUP: El grupo asignado desde tu IdP, por ejemplo: administrator-group@example.com
Por atributo
```
principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE
```
Reemplaza lo siguiente:
- PROJECT_NUMBER: el número del proyecto
- WORKLOAD_POOL_ID: el ID del grupo de cargas de trabajo
- ATTRIBUTE_NAME: Uno de los atributos que se asignó desde tu IdP
- ATTRIBUTE_VALUE: el valor del atributo.
Elige un rol (o roles) del menú desplegable Selecciona un rol. Los roles que seleccionas aparecen en el panel con una descripción breve del permiso que otorgan.
Haz clic en Guardar.

gcloud

Para usar la CLI de gcloud para otorgar roles de IAM en un recurso en un proyecto, haz lo siguiente:

Obtén el número del proyecto en el que se define el recurso.

gcloud projects describe $(gcloud config get-value core/project) --format=value\(projectNumber\)

Otorga el acceso al recurso.

Para usar gcloud CLI con el objetivo de otorgar el rol de Visualizador de objetos de almacenamiento (roles/storage.objectViewer) a identidades externas que cumplan con ciertos criterios, ejecuta el siguiente comando.
Por tema
```
gcloud storage buckets add-iam-policy-binding BUCKET_ID \
    --role=roles/storage.objectViewer \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT"
```
Por grupo
```
gcloud storage buckets add-iam-policy-binding BUCKET_ID \
    --role=roles/storage.objectViewer \
    --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP"
```
Por atributo
```
gcloud storage buckets add-iam-policy-binding BUCKET_ID \
    --role=roles/storage.objectViewer \
    --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE"
```
Reemplaza lo siguiente:
- BUCKET_ID: Es el bucket en el que se otorgará acceso.
- PROJECT_NUMBER: el número del proyecto que contiene el grupo de Workload Identity.
- POOL_ID: el ID del grupo de identidades para cargas de trabajo
- SUBJECT: el valor esperado para el atributo que asignaste a google.subject
- GROUP: el valor esperado para el atributo que asignaste a google.groups
- ATTRIBUTE_NAME: el nombre de un atributo personalizado en la asignación de atributos
- ATTRIBUTE_VALUE: Es el valor del atributo personalizado en tu asignación de atributos.
Puedes otorgar roles en cualquier recurso de Google Cloud que admita políticas de permisos de IAM.

Nota: Debes usar el número de proyecto, no el ID del proyecto, en el identificador de miembro.

Uso de identidad temporal como cuenta de servicio

Para crear una cuenta de servicio para la carga de trabajo externa, haz lo siguiente:
1. Enable the IAM, Security Token Service, and Service Account Credentials APIs.
  Enable the APIs
2. Crea una cuenta de servicio que represente la carga de trabajo. Te recomendamos que uses una cuenta de servicio dedicada para cada carga de trabajo. No es necesario que la cuenta de servicio esté en el mismo proyecto que el grupo de identidades para cargas de trabajo, pero debes consultar el proyecto que contiene la cuenta de servicio.
3. Otorga acceso a la cuenta de servicio a los recursos a los que deseas que accedan las identidades externas.
4. Otorga el rol de usuario de Workload Identity (roles/iam.workloadIdentityUser) a la cuenta de servicio:
Para otorgar acceso a una identidad federada mediante la identidad temporal como cuenta de servicio con la consola de Google Cloud o gcloud CLI, haz lo siguiente:

Console

Para usar la consola de Google Cloud para otorgar roles de IAM a una identidad federada con una cuenta de servicio, haz lo siguiente:

Cuenta de servicio en el mismo proyecto

Para otorgar acceso mediante la identidad temporal como cuenta de servicio para una cuenta de servicio en el mismo proyecto, haz lo siguiente:
1. Ve a la página Grupos de identidades para cargas de trabajo.
  
  Ir a Grupos de Workload Identity
2. Selecciona Otorgar acceso.
3. En el cuadro de diálogo Otorgar acceso a la cuenta de servicio, selecciona Otorgar acceso mediante la identidad temporal como cuenta de servicio.
4. En la lista Cuentas de servicio, selecciona la cuenta de servicio para las identidades externas que actuarán en nombre de ella y haz lo siguiente:
5. Para elegir qué identidades en el grupo pueden actuar en nombre de la cuenta de servicio, realiza una de las siguientes acciones:
  - Para permitir que solo las identidades específicas del grupo de identidades para cargas de trabajo actúen en nombre de la cuenta de servicio, selecciona Solo identidades que coinciden con el filtro.
  - En la lista Nombre del atributo, selecciona el atributo que deseas filtrar.
  - En el campo Valor del atributo, ingresa el valor esperado del atributo; por ejemplo, si usas una asignación de atributos google.subject=assertion.sub, establece el nombre del atributo en subject y el valor del atributo en el valor de la declaración sub en los tokens que emite tu proveedor de identidad externo.
6. Para guardar la configuración, haz clic en Guardar y, luego, en Descartar.

Cuenta de servicio en otro proyecto

Para otorgar acceso mediante la identidad temporal como cuenta de servicio para una cuenta de servicio en un proyecto diferente, haz lo siguiente:
1. Ve a la página de cuentas de servicio.
  
  Ir a Cuentas de servicio
2. Elige la cuenta de servicio de la que quieres usar la identidad.
3. Haz clic en Administrar acceso.
4. Haz clic en Agregar principal.
5. En el campo Principal nuevo, ingresa uno de los siguientes identificadores principales para las identidades de tu grupo que actuarán en nombre de la cuenta de servicio.
  Por tema
  principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT
  Reemplaza lo siguiente:
  - PROJECT_NUMBER: el número del proyecto
  - POOL_ID: el ID del grupo de cargas de trabajo
  - SUBJECT: El sujeto individual asignado desde tu IdP, por ejemplo, administrator@example.com
  Por grupo
  principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP
  Reemplaza lo siguiente:
  - PROJECT_NUMBER: el número del proyecto
  - WORKLOAD_POOL_ID: el ID del grupo de cargas de trabajo
  - GROUP: El grupo asignado desde tu IdP, por ejemplo: administrator-group@example.com
  Por atributo
  principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE
  Reemplaza lo siguiente:
  - PROJECT_NUMBER: el número del proyecto
  - WORKLOAD_POOL_ID: el ID del grupo de cargas de trabajo
  - ATTRIBUTE_NAME: Uno de los atributos que se asignó desde tu IdP
  - ATTRIBUTE_VALUE: el valor del atributo.
  Junto al grupo
  <principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/*
  Reemplaza lo siguiente:
  - PROJECT_NUMBER: el número del proyecto
  - WORKLOAD_POOL_ID: el ID del grupo de cargas de trabajo
6. En Selecciona un rol, elige el rol de usuario de Workload Identity (roles/iam.workloadIdentityUser).
7. Para guardar la configuración, haz clic en Guardar.

gcloud

Para usar la CLI de gcloud a fin de otorgar el rol de usuario de Workload Identity (roles/iam.workloadIdentityUser) a identidades externas que cumplan con ciertos criterios, ejecuta el siguiente comando.

Por tema

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
    --role=roles/iam.workloadIdentityUser \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT"

Por grupo

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
    --role=roles/iam.workloadIdentityUser \
    --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP"

Por atributo

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
    --role=roles/iam.workloadIdentityUser \
    --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE"

Reemplaza lo siguiente:

SERVICE_ACCOUNT_EMAIL: La dirección de correo electrónico de la cuenta de servicio
PROJECT_NUMBER: el número del proyecto que contiene el grupo de Workload Identity.
POOL_ID: el ID del grupo de identidades para cargas de trabajo
SUBJECT: el valor esperado para el atributo que asignaste a google.subject
GROUP: el valor esperado para el atributo que asignaste a google.groups
ATTRIBUTE_NAME: el nombre de un atributo personalizado en la asignación de atributos
ATTRIBUTE_VALUE: Es el valor del atributo personalizado en tu asignación de atributos.

Configura la canalización de implementación

En esta sección, se describe cómo trasladar tu infraestructura de Hadoop existente a un modelo efímero. En las instrucciones de esta sección, se supone que tus cargas de trabajo usan la identidad temporal como cuenta de servicio para acceder a los recursos de Google Cloud.

Azure DevOps

Edita el archivo azure-pipelines.yml y agrega lo siguiente a la configuración del trabajo:

variables:
- name: Azure.WorkloadIdentity.Connection
  value: CONNECTION
- name: GoogleCloud.WorkloadIdentity.ProjectNumber
  value: PROJECT_NUMBER
- name: GoogleCloud.WorkloadIdentity.Pool
  value: POOL_ID
- name: GoogleCloud.WorkloadIdentity.Provider
  value: PROVIDER_ID
- name: GoogleCloud.WorkloadIdentity.ServiceAccount
  value: SERVICE_ACCOUNT_EMAIL
- name: GOOGLE_APPLICATION_CREDENTIALS
  value: $(Pipeline.Workspace)/.workload_identity.wlconfig

steps:
  - task: AzureCLI@2
    inputs:
      connectedServiceNameARM: $(Azure.WorkloadIdentity.Connection)
      addSpnToEnvironment: true
      scriptType: 'bash'
      scriptLocation: 'inlineScript'
      inlineScript: |
        echo $idToken > $(Pipeline.Workspace)/.workload_identity.jwt
        cat << EOF > $GOOGLE_APPLICATION_CREDENTIALS
        {
          "type": "external_account",
          "audience": "//iam.googleapis.com/projects/$(GoogleCloud.WorkloadIdentity.ProjectNumber)/locations/global/workloadIdentityPools/$(GoogleCloud.WorkloadIdentity.Pool)/providers/$(GoogleCloud.WorkloadIdentity.Provider)",
          "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
          "token_url": "https://sts.googleapis.com/v1/token",
          "credential_source": {
            "file": "$(Pipeline.Workspace)/.workload_identity.jwt"
          },
          "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/$(GoogleCloud.WorkloadIdentity.ServiceAccount):generateAccessToken"
        }
        EOF

Reemplaza los siguientes valores:

CONNECTION: el nombre de la conexión del servicio
PROJECT_NUMBER: es el número del proyecto que contiene el grupo de workload identity
POOL_ID: El ID del grupo de Workload Identity
PROVIDER_ID: El ID del proveedor de grupos de Workload Identity
SERVICE_ACCOUNT_EMAIL: La dirección de correo electrónico de la cuenta de servicio

La configuración hace lo siguiente:

Usa la tarea AzureCLI a fin de obtener un token de ID para la conexión del servicio y lo pone a disposición en una variable llamada idToken.
Guarda el token de ID en un archivo temporal llamado .workload_identity.jwt.
Crea un archivo de configuración de credenciales que indique a las bibliotecas cliente que lean el token de ID de .workload_identity.jwt y lo usen para actuar en nombre de una cuenta de servicio.
Establece la variable de entorno GOOGLE_APPLICATION_CREDENTIALS para que apunte al archivo de configuración de credenciales.

Acciones de GitHub

La acción google-github-actions/auth te permite generar automáticamente un archivo de configuración de credenciales durante la ejecución del flujo de trabajo. Las bibliotecas cliente y las herramientas como terraform pueden usar este archivo de configuración de credenciales para obtener credenciales de Google de forma automática.

Edita el archivo YAML de GitHub Actions y agrega lo siguiente:

Para permitir que el trabajo recupere un token de ID de GitHub, agrega la siguiente configuración:
```
permissions:
  id-token: write
  contents: read
```

Agrega un paso para crear un archivo de configuración de credenciales:

- id: 'auth'
  name: 'Authenticate to Google Cloud'
  uses: 'google-github-actions/auth@v1'
  with:
    create_credentials_file: true
    workload_identity_provider: 'projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID'
    service_account: 'SERVICE_ACCOUNT_EMAIL'

Reemplaza los siguientes valores:

PROJECT_NUMBER: El número del proyecto que contiene el grupo de Workload Identity.
POOL_ID: El ID del grupo de Workload Identity.
PROVIDER_ID: El ID del proveedor de grupos de Workload Identity.
SERVICE_ACCOUNT_EMAIL: Reemplaza por la dirección de correo electrónico de la cuenta de servicio.

En el siguiente ejemplo, se configura la acción de GitHub:

jobs:
  build:
    # Allow the job to fetch a GitHub ID token
    permissions:
      id-token: write
      contents: read

    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - id: 'auth'
        name: 'Authenticate to Google Cloud'
        uses: 'google-github-actions/auth@v1'
        with:
          create_credentials_file: true
          workload_identity_provider: 'projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID'
          service_account: 'SERVICE_ACCOUNT_EMAIL'

Para obtener más detalles sobre el uso de la acción google-github-actions/auth, consulta Configura la federación de identidades para cargas de trabajo.

SaaS de GitLab

Edita el archivo .gitlab-ci.yml y agrega lo siguiente a la configuración del trabajo:

job:
  variables:
    WORKLOAD_IDENTITY_PROJECT_NUMBER: PROJECT_NUMBER
    WORKLOAD_IDENTITY_POOL: POOL_ID
    WORKLOAD_IDENTITY_PROVIDER: PROVIDER_ID
    SERVICE_ACCOUNT: SERVICE_ACCOUNT_EMAIL
    GOOGLE_APPLICATION_CREDENTIALS: $CI_BUILDS_DIR/.workload_identity.wlconfig

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

  script:
    - |-
      echo $WORKLOAD_IDENTITY_TOKEN > $CI_BUILDS_DIR/.workload_identity.jwt
      cat << EOF > $GOOGLE_APPLICATION_CREDENTIALS
      {
        "type": "external_account",
        "audience": "//iam.googleapis.com/projects/$WORKLOAD_IDENTITY_PROJECT_NUMBER/locations/global/workloadIdentityPools/$WORKLOAD_IDENTITY_POOL/providers/$WORKLOAD_IDENTITY_PROVIDER",
        "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
        "token_url": "https://sts.googleapis.com/v1/token",
        "credential_source": {
          "file": "$CI_BUILDS_DIR/.workload_identity.jwt"
        },
        "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/$SERVICE_ACCOUNT:generateAccessToken"
      }
      EOF

Reemplaza los siguientes valores:

PROJECT_NUMBER: El número del proyecto que contiene el grupo de Workload Identity.
POOL_ID: El ID del grupo de Workload Identity
PROVIDER_ID: El ID del proveedor de grupos de Workload Identity
SERVICE_ACCOUNT_EMAIL: La dirección de correo electrónico de la cuenta de servicio

La configuración hace lo siguiente:

Le indica a GitLab que emita un token de ID y lo pone a disposición en la variable de entorno llamada WORKLOAD_IDENTITY_TOKEN. El token de ID usa el proveedor de grupos de Workload Identity como público.
Guarda el token de ID en un archivo temporal llamado .workload_identity.jwt.
Crea un archivo de configuración de credenciales que indique a las bibliotecas cliente que lean el token de ID de .workload_identity.jwt y lo usen para actuar en nombre de una cuenta de servicio.
Establece la variable de entorno GOOGLE_APPLICATION_CREDENTIALS para que apunte al archivo de configuración de credenciales.

Terraform Cloud

Configura tu lugar de trabajo de Terraform Cloud para que use la federación de Workload Identity para autenticarse en Google Cloud mediante la identidad temporal como cuenta de servicio:

En Terraform Cloud, abre tu lugar de trabajo y ve a Variables.

Agrega las siguientes variables:

Categoría variable	Clave	Valor
Variable de entorno	`TFC_GCP_PROVIDER_AUTH`	`true`
Variable de entorno	`TFC_GCP_RUN_SERVICE_ACCOUNT_EMAIL`	La dirección de correo electrónico de la cuenta de servicio, por ejemplo, `terraform@my-project-123.iam.gserviceaccount.com`
Variable de entorno	`TFC_GCP_PROJECT_NUMBER`	El número de proyecto del proyecto que contiene el grupo de identidades para cargas de trabajo.
Variable de entorno	`TFC_GCP_WORKLOAD_POOL_ID`	El ID del grupo de identidades para cargas de trabajo
Variable de entorno	`TFC_GCP_WORKLOAD_PROVIDER_ID`	El ID del proveedor de grupos de identidades para cargas de trabajo

De manera opcional, puedes agregar variables de entorno adicionales para permitir que Terraform Cloud use diferentes cuentas de servicio para las fases plan y apply. Para obtener más información, consulta Variables de entorno opcionales.

En la lista de variables, verifica que Categoría esté configurada en env para las cinco variables que agregaste en el paso anterior.
Verifica que tu configuración de Terraform use la versión 4.48.0 o una versión posterior del proveedor de Google Cloud y actualízala si es necesario, de la siguiente manera:
```
terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 4.48.0"
    }
  }
}
```
Envía los cambios a tu repositorio de código fuente.

¿Qué sigue?

Obtén más información sobre la federación de Workload Identity.
Obtén más información sobre las prácticas recomendadas para usar la federación de Workload Identity en canalizaciones de implementación.
Consulta cómo puedes administrar grupos y proveedores de identidades para cargas de trabajo.

Configura la federación de Workload Identity con canalizaciones de implementación

Antes de comenzar

Configura la autenticación

Console

gcloud

Python

Roles obligatorios

Prepara el IdP externo

Azure DevOps

Acciones de GitHub

SaaS de GitLab

Terraform Cloud

Configura la federación de Workload Identity

Define una asignación de atributos

Azure DevOps

Acciones de GitHub

SaaS de GitLab

Terraform Cloud

Define una condición de atributo

Azure DevOps

Acciones de GitHub

SaaS de GitLab

Terraform Cloud

Crea el proveedor y el grupo de Workload Identity

Console

Azure DevOps

Acciones de GitHub

SaaS de GitLab

Terraform Cloud

gcloud

Azure DevOps

Acciones de GitHub

SaaS de GitLab

Terraform Cloud

Actualiza la condición de atributo en un proveedor de identidades para cargas de trabajo

Console

gcloud

Autentica una canalización de implementación

Permite que tu carga de trabajo externa acceda a los recursos de Google Cloud

Acceso directo a recursos

Console

Por tema

Por grupo

Por atributo

gcloud

Por tema

Por grupo

Por atributo

Uso de identidad temporal como cuenta de servicio

Console

Cuenta de servicio en el mismo proyecto

Cuenta de servicio en otro proyecto

Por tema

Por grupo

Por atributo

Junto al grupo

gcloud

Por tema

Por grupo

Por atributo

Configura la canalización de implementación

Azure DevOps

Acciones de GitHub

SaaS de GitLab

Terraform Cloud

¿Qué sigue?