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

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:

1. En Azure DevOps, abre tu proyecto y ve a Configuración del proyecto.
2. Ve a Canalizaciones > Conexiones de servicio.
3. Haz clic en Crear conexión de servicio.
4. Selecciona Azure Resource Manager.
5. Haz clic en Siguiente.
6. Selecciona Federación de identidades para cargas de trabajo (automática).
7. Haz clic en Siguiente.

8. 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.

9. 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:

1. Haz clic en la conexión de servicio que acabas de crear.
2. Haz clic en Administrar principal de servicio.
3. Ve a Certificado y secretos > Credenciales federadas.
4. Haz clic en la credencial federada.

5. 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:

1. En el portal de Azure, abre la suscripción que seleccionaste como permiso.
2. Ve a Control de acceso (IAM) > Asignaciones de roles.
3. 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.

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.

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'

Console

1. 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

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. Haz clic en Continuar.

4. 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

5. Haz clic en Continuar.

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

7. En Condiciones del atributo, ingresa la condición del atributo que identificaste antes.

8. 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: 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

2. 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.

Console

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

   Ir a Grupos de Workload Identity

2. Busca el grupo de identidades de la carga de trabajo que contiene el proveedor y, luego, haz clic en el ícono arrow_right Expandir nodo para el grupo.

3. Busca el proveedor de grupos de identidades para cargas de trabajo que deseas editar y haz clic en edit Editar.

4. En Condiciones del atributo, ingresa la condición del atributo que identificaste antes.

5. 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.

Acceso directo a recursos

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

Uso de identidad temporal como cuenta de servicio

1. 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:

2. 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:

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"

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"

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"

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:

1. 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.
2. Guarda el token de ID en un archivo temporal llamado .workload_identity.jwt.
3. 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.
4. 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:

1. 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.
2. Guarda el token de ID en un archivo temporal llamado .workload_identity.jwt.
3. 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.
4. 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:

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

2. 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.

3. En la lista de variables, verifica que Categoría esté configurada en env para las cinco variables que agregaste en el paso anterior.

4. 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"
       }
     }
   }
   

5. Envía los cambios a tu repositorio de código fuente.