Configurar la federación de identidades de cargas de trabajo con las canalizaciones de implementación

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

En función del sistema de CI/CD que utilices, es posible que tus flujos de procesamiento de implementación tengan acceso a credenciales específicas del entorno. Por ejemplo:

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

Puedes configurar tus flujos de procesamiento de implementación para que usen estas credenciales para autenticarse enGoogle Cloud mediante la federación de identidades de cargas de trabajo. Con este método, se elimina la carga de mantenimiento y seguridad asociada a las claves de cuentas de servicio.

Antes de empezar

Configurar 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 Python muestras de esta página en un entorno de desarrollo local, instala e inicializa la CLI de gcloud y, a continuación, configura las credenciales predeterminadas de la aplicación con tus credenciales de usuario.

    Instala Google Cloud CLI.

    Si utilizas un proveedor de identidades (IdP) externo, primero debes iniciar sesión en la CLI de gcloud con tu identidad federada.

    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.

    If an authentication error is returned, and you are using an external identity provider (IdP), confirm that you have signed in to the gcloud CLI with your federated identity.

Para obtener más información, consulta Configurar ADC en un entorno de desarrollo local en la documentación de autenticación. Google Cloud

Roles obligatorios

Para obtener los permisos que necesitas para configurar la federación de identidades de cargas de trabajo, pide a tu administrador que te conceda el rol de gestión de identidades y accesos Administrador de grupos de Workload Identity (roles/iam.workloadIdentityPoolAdmin) en el proyecto. Para obtener más información sobre cómo conceder roles, consulta el artículo Gestionar el acceso a proyectos, carpetas y organizaciones.

También puedes conseguir los permisos necesarios a través de roles personalizados u otros roles predefinidos.

También puedes usar el rol básico Propietario de gestión de identidades y accesos (roles/owner), que incluye permisos para configurar la federación de identidades. No debes conceder roles básicos en un entorno de producción, pero sí puedes hacerlo en un entorno de desarrollo o de pruebas.

Preparar tu proveedor de identidades 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 puede intercambiar por credenciales deGoogle Cloud .

Para crear una conexión de servicio para Azure Resource Manager, sigue estos pasos:

  1. En Azure DevOps, abra su proyecto y vaya a Configuración del proyecto.
  2. Ve a Pipelines > Service connections (Pipelines > Conexiones de servicio).
  3. Haz clic en Crear conexión de servicio.
  4. Selecciona Azure Resource Manager.
  5. Haz clic en Siguiente.

  6. Configura las siguientes configuraciones:

    • Tipo de identidad: Registro de aplicación (automático)
    • Credencial: Federación de identidades de carga de trabajo

    • Nivel de ámbito: Suscripción.

      Debes seleccionar una suscripción aunque no tengas previsto usar la conexión de servicio para acceder a recursos de Azure.

    • Nombre de la conexión de servicio: introduce un nombre, como google-cloud.

  7. Haz clic en Guardar.

En un paso posterior, necesitarás el identificador de emisor y de asunto de la conexión de servicio. Para consultar estos detalles, sigue estos pasos:

  1. Haga clic en la conexión de servicio que acaba de crear.
  2. Haz clic en Gestionar registro de aplicación.
  3. Selecciona Gestionar > Certificados y secretos > Credenciales federadas.
  4. Haz clic en la credencial federada.

  5. En la página Editar una credencial, busca los siguientes identificadores:

    • Issuer (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 concede automáticamente acceso a la suscripción que hayas seleccionado como ámbito a la entidad de servicio asociada a tu nueva conexión de servicio. Como no tienes previsto usar la conexión de servicio para acceder a recursos de Azure, puedes revocar este acceso haciendo lo siguiente:

  1. En el portal de Azure, abre la suscripción que has seleccionado como ámbito.
  2. Ve a Control de acceso (IAM) > Asignaciones de roles.
  3. Busca la asignación de rol de la conexión de servicio y elimínala.

GitHub Actions

No tienes que hacer ningún cambio en la configuración de tu cuenta de GitHub.

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

SaaS de GitLab

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

Después de configurar un grupo de identidades de carga de trabajo para que confíe en tu grupo de GitLab, puedes habilitar Workload Identity Federation en trabajos de CI/CD concretos.

Terraform Cloud

No es necesario que hagas ningún cambio en la configuración de tu cuenta de Terraform Cloud.

Después de configurar un grupo de identidades de cargas de trabajo para que confíe en Terraform Cloud, puedes habilitar la federación de identidades de cargas de trabajo en espacios de trabajo concretos.

Configurar la federación de identidades de cargas de trabajo

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

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

  1. In the Google Cloud console, go to the project selector page.

    Go to project selector

  2. Select or create a Google Cloud project.

    3. Lo más recomendable es usar un proyecto específico para gestionar los grupos y proveedores de Workload Identity.

    Verify 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

Definir una asignación de atributos

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

Si quiere, puede mapear atributos adicionales. Después, puede hacer referencia a estos atributos adicionales cuando conceda 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 tu conexión de servicio. El identificador de asunto usa el siguiente formato:

sc://ORGANIZATION/PROJECT/CONNECTION

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

google.subject=assertion.sub

GitHub Actions

En tus asignaciones de atributos puedes usar cualquiera de las reclamaciones del token OIDC de GitHub Actions. GitHub controla estas claves de reclamación de tokens y sus valores. Como mínimo, debes asignar google.subject a assertion.sub, lo que corresponde al asunto del token OIDC de GitHub Actions:

google.subject=assertion.sub

El valor del asunto del token OIDC de GitHub Actions puede variar en función del evento de origen. Otros atributos de la reclamación pueden ser:

  • repository: contiene el nombre del propietario y del repositorio (por ejemplo, "google/guava").

  • repository_id: contiene el ID de 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 de propietario único. Por ejemplo, "1342004".

Esta lista es un subconjunto de las posibles reclamaciones. Consulta la documentación de GitHub sobre las reclamaciones de ejemplo para ver la lista completa. Asegúrate de asignar las reclamaciones que vayas a usar como condiciones de atributos o como parte de una condición principalSet en el futuro.

SaaS de GitLab

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

  • sub: el nombre del proyecto y la referencia de Git. Por ejemplo: project_path:groupname/projectname:ref_type:branch:ref:main
  • namespace_id: el ID de grupo único.
  • project_id: el ID de 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 define google.subject en la reclamación sub del token de ID de GitLab. Como la reclamación sub contiene tanto el nombre del proyecto como 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 determinadas ramas (por ejemplo, main) necesitan un acceso a los recursos diferente al de otras ramas (por ejemplo, las ramas de funciones).

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

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

Terraform Cloud

Tus mapeos de atributos pueden usar las reclamaciones insertadas en el token OIDC de Terraform Cloud, incluidas las siguientes:

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

La siguiente asignación de atributos define google.subject en la reclamación terraform_workspace_id del token OIDC de Terraform Cloud:

google.subject=assertion.terraform_workspace_id

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

Definir una condición de atributo

Las condiciones de atributos son expresiones CEL que pueden comprobar 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. Debe tener una asignación de atributos para todos los campos de condición de atributo.

Azure DevOps

Opcionalmente, usa una condición de atributo para restringir el acceso a determinadas conexiones de servicio. Por ejemplo, la siguiente condición limita el acceso a las conexiones de un proyecto de Azure DevOps concreto:

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

Haz los cambios siguientes:

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

GitHub Actions

Usa la siguiente condición de atributo para restringir el acceso a los tokens emitidos por tu organización de GitHub:

assertion.repository_owner=='ORGANIZATION'

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

También puedes ampliar 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 emitidos por tu grupo de GitLab. 

assertion.namespace_id=='GROUP_ID'

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

De forma opcional, puedes ampliar 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

Utilice la siguiente condición de atributo para restringir el acceso a los tokens emitidos por su organización de Terraform Cloud:

assertion.terraform_organization_id=='ORGANIZATION_ID'

Sustituye ORGANIZATION_ID por el ID único de tu organización. Por ejemplo, org-xxxxxxxxxxxxxxxx. También puedes ampliar 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 espacio de trabajo específico:

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

Crear el grupo y el proveedor de identidades de carga de trabajo

Ahora ya tienes toda la información que necesitas para crear un grupo y un proveedor de identidades de carga de trabajo:

Consola

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

    Ve a Nuevo proveedor y grupo de cargas de trabajo.

  2. En Create an identity pool (Crear un grupo de identidades), introduce lo siguiente:

    • Nombre: nombre del grupo. El nombre también se usa como ID del grupo. No podrás cambiar el ID del grupo más adelante.
    • Descripción: texto que describe el propósito del grupo.

  3. Haz clic en Continuar.

  4. Configura los ajustes 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 podrás cambiar el ID de proveedor más adelante.
    • URL del emisor: el emisor de la conexión de servicio que has buscado anteriormente.

    • Audiencias: selecciona Audiencias permitidas y pega el siguiente valor:

      api://AzureADTokenExchange

    GitHub Actions

    • Selecciona un proveedor: OpenID Connect (OIDC).
    • Nombre del proveedor: nombre del proveedor.
    • ID de proveedor: ID del proveedor. No podrás cambiar el ID de proveedor más adelante.
    • URL del emisor: https://token.actions.githubusercontent.com/
    • Audiencias: Audiencia predeterminada

    SaaS de GitLab

    • Selecciona un proveedor: OpenID Connect (OIDC).
    • Nombre del proveedor: nombre del proveedor.
    • ID de proveedor: ID del proveedor. No podrás cambiar el ID de proveedor más adelante.
    • URL del emisor: https://gitlab.com
    • Audiencias: Audiencia predeterminada

    Terraform Cloud

    • Selecciona un proveedor: OpenID Connect (OIDC).
    • Nombre del proveedor: nombre del proveedor.
    • ID de proveedor: ID del proveedor. No podrás cambiar el ID de proveedor más adelante.
    • URL del emisor: https://app.terraform.io
    • Audiencias: Audiencia predeterminada

  5. Haz clic en Continuar.

  6. En Configurar atributos del proveedor, añade las asignaciones de atributos que hayas identificado anteriormente.

  7. En Condiciones de los atributos, introduzca la condición de los atributos que ha identificado anteriormente.

  8. Haz clic en Guardar para crear el grupo de identidades de carga de trabajo y el proveedor.

gcloud

  1. Crea un grupo de identidades de carga de trabajo:

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

    Sustituye los siguientes valores:

    • POOL_ID: ID único del grupo.
    • DISPLAY_NAME: el nombre del grupo
    • DESCRIPTION: la descripción del grupo. Esta descripción aparece al conceder acceso a identidades de grupo

  2. Añade un proveedor de grupos de identidades de carga de trabajo:

    Azure DevOps 

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

    Sustituye los siguientes valores:

    GitHub Actions 

    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"

    Sustituye los siguientes valores:

    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"

    Sustituye los siguientes valores:

    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"

    Sustituye los siguientes valores:

Actualizar la condición de atributo en un proveedor de identidades de carga de trabajo

En esta sección se describe cómo puede actualizar la condición del atributo en un proveedor de identidades de carga de trabajo para restringir el acceso a los tokens emitidos por su organización de GitHub, su grupo de GitLab o su organización de Terraform Cloud.

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

Consola

  1. En la Google Cloud consola, ve a la página Grupos de identidades de carga de trabajo.

    Ir a Grupos de Workload Identity

  2. Busca el grupo de identidades de carga de trabajo que contiene el proveedor y, a continuación, haz clic en el icono Expandir nodo del grupo.

  3. Busca el proveedor del grupo de identidades de carga de trabajo que quieras editar y haz clic en Editar.

  4. En Condiciones de atributo, introduzca la condición de atributo que ha identificado anteriormente.

  5. Para actualizar el grupo y el proveedor de identidades de carga de trabajo, haz clic en Guardar.

gcloud

Para actualizar el proveedor de grupos de identidades de carga 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"

Sustituye los siguientes valores:

Autenticar una canalización de implementación

Debes seguir estos pasos para cada flujo de trabajo de GitHub Actions o espacio de trabajo de Terraform Cloud.

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

Para completar las instrucciones que se indican más adelante en esta guía, debe configurar la suplantación de identidad de la cuenta de servicio, tal como se describe en esta sección.

Para proporcionar a tu carga de trabajo acceso a los recursos de Google Cloud , te recomendamos que concedas acceso directo a los recursos a la entidad principal. En este caso, el principal es el usuario federado. Algunos Google Cloud productos tienen limitaciones en la API de Google Cloud. Si tu carga de trabajo llama a un endpoint de API que tiene una limitación, puedes usar la suplantación de identidad de la cuenta de servicio. En este caso, el principal es laGoogle Cloud cuenta de servicio, que actúa como identidad. Concede acceso a la cuenta de servicio en el recurso.

Acceso directo a recursos

Puedes conceder acceso a una identidad federada directamente a los recursos mediante la Google Cloud consola o la CLI de gcloud.

Consola

Para usar la Google Cloud consola y asignar roles de gestión de identidades y accesos directamente a un recurso, debes ir a la página del recurso y, a continuación, asignar el rol. En el siguiente ejemplo se muestra cómo ir a la página de Cloud Storage y asignar el rol Lector de objetos de Storage (roles/storage.objectViewer) a una identidad federada directamente en un segmento de Cloud Storage.

  1. En la Google Cloud consola, ve a la página Segmentos de Cloud Storage.

    Ir a Contenedores

  2. En la lista de segmentos, haga clic en el nombre del segmento al que quiera conceder el rol.

  3. Seleccione la pestaña Permisos, situada cerca de la parte superior de la página.

  4. Haz clic en el botón Conceder acceso.

    Aparecerá el cuadro de diálogo Añadir principales.

  5. En el campo Nuevos principales, introduzca una o varias identidades que necesiten acceder a su contenedor.

    Por tema 

    principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT

    Haz los cambios siguientes:

    • PROJECT_NUMBER: el número del proyecto
    • POOL_ID: el ID del grupo de cargas de trabajo
    • SUBJECT: el asunto individual asignado desde tu proveedor de identidades. Por ejemplo: administrator@example.com

    Por grupo 

    principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP

    Haz los cambios siguientes:

    • PROJECT_NUMBER: el número del proyecto
    • WORKLOAD_POOL_ID: el ID del grupo de cargas de trabajo
    • GROUP: el grupo asignado de tu proveedor de identidades. 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

    Haz los cambios siguientes:

    • 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 ha asignado desde tu proveedor de identidades
    • ATTRIBUTE_VALUE: el valor del atributo

  6. Selecciona uno o varios roles en el menú desplegable Selecciona un rol. Los roles que selecciones aparecerán en el panel con una breve descripción de los permisos que conceden.

  7. Haz clic en Guardar.

gcloud

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

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

  2. Concede acceso al recurso.

    Para usar la CLI de gcloud y asignar el rol Lector de objetos de Storage (roles/storage.objectViewer) a identidades externas que cumplan determinados 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"

    Haz los cambios siguientes:

    • BUCKET_ID: el contenedor al que se va a conceder acceso
    • PROJECT_NUMBER: el número de proyecto del proyecto que contiene el grupo de identidades de carga de trabajo.
    • POOL_ID: el ID del grupo de identidades de carga de trabajo
    • SUBJECT: el valor esperado del atributo que has asignado a google.subject
    • GROUP: el valor esperado del atributo que has asignado a google.groups
    • ATTRIBUTE_NAME: el nombre de un atributo personalizado en tu asignación de atributos
    • ATTRIBUTE_VALUE: el valor del atributo personalizado en tu asignación de atributos

    Puedes conceder roles en cualquier Google Cloud recurso que admita políticas de permiso de gestión de identidades y accesos.

Suplantación de identidad de cuentas de servicio

  1. Para crear una cuenta de servicio para la carga de trabajo externa, sigue estos pasos:

    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 utilices una cuenta de servicio específica para cada carga de trabajo. La cuenta de servicio no tiene que estar en el mismo proyecto que el grupo de identidades de carga de trabajo, pero debes hacer referencia al proyecto que contiene la cuenta de servicio.

    3. Concede acceso a la cuenta de servicio a los recursos a los que quieras que accedan las identidades externas.

  2. Para permitir que la identidad federada suplante la cuenta de servicio, haz lo siguiente:

Consola

Para usar la Google Cloud consola y conceder roles de gestión de identidades y accesos a una identidad federada con una cuenta de servicio, sigue estos pasos:

Cuenta de servicio en el mismo proyecto

  1. Para conceder acceso mediante la suplantación de identidad de una cuenta de servicio en el mismo proyecto, sigue estos pasos:

    1. Ve a la página Grupos de Workload Identity.

      Ir a Grupos de Workload Identity

    2. Selecciona Conceder acceso.

    3. En el cuadro de diálogo Grant access to service account (Conceder acceso a la cuenta de servicio), selecciona Grant access using Service Account impersonation (Conceder acceso mediante la suplantación de la cuenta de servicio).

    4. En la lista Cuentas de servicio, selecciona la cuenta de servicio que las identidades externas deben suplantar y haz lo siguiente:

    5. Para elegir qué identidades del grupo pueden suplantar la identidad de la cuenta de servicio, realiza una de las siguientes acciones:

      • Para permitir que solo determinadas identidades del grupo de identidades de carga de trabajo suplanten la identidad de la cuenta de servicio, seleccione Solo las identidades que coincidan con el filtro.

      • En la lista Nombre del atributo, seleccione el atributo por el que quiera filtrar.

      • En el campo Valor del atributo, introduzca el valor esperado del atributo. Por ejemplo, si utiliza una asignación de atributos google.subject=assertion.sub, defina el nombre del atributo como subject y el valor del atributo como el valor de la reclamación sub en los tokens emitidos por su proveedor de identidades externo.

    6. Para guardar la configuración, haz clic en Guardar y, a continuación, en Cerrar.

Cuenta de servicio en otro proyecto

  1. Para conceder acceso mediante la suplantación de identidad de una cuenta de servicio en otro proyecto, sigue estos pasos:

    1. Ve a la página Cuentas de servicio.

      Ir a Cuentas de servicio

    2. Selecciona la cuenta de servicio que quieras suplantar.

    3. Haz clic en Gestionar acceso.

    4. Haz clic en Añadir principal.

    5. En el campo Nuevo principal, introduce uno de los siguientes identificadores principales de las identidades de tu grupo que suplantarán la cuenta de servicio.

      Por tema 

      principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT

      Haz los cambios siguientes:

      • PROJECT_NUMBER: el número del proyecto
      • POOL_ID: el ID del grupo de cargas de trabajo
      • SUBJECT: el asunto individual asignado desde tu proveedor de identidades. Por ejemplo: administrator@example.com

      Por grupo 

      principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP

      Haz los cambios siguientes:

      • PROJECT_NUMBER: el número del proyecto
      • WORKLOAD_POOL_ID: el ID del grupo de cargas de trabajo
      • GROUP: el grupo asignado de tu proveedor de identidades. 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

      Haz los cambios siguientes:

      • 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 ha asignado desde tu proveedor de identidades
      • ATTRIBUTE_VALUE: el valor del atributo

      Por piscina

      principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/*

      Haz los cambios siguientes:

      • PROJECT_NUMBER: el número del proyecto
      • WORKLOAD_POOL_ID: el ID del grupo de cargas de trabajo

    6. En Selecciona un rol, selecciona el rol Usuario de Workload Identity (roles/iam.workloadIdentityUser).

    7. Para guardar la configuración, haz clic en Guardar.

gcloud

Para conceder el rol de usuario de identidad de carga de trabajo (roles/iam.workloadIdentityUser) a un principal federado o a un conjunto de principales, ejecuta el siguiente comando. Para obtener más información sobre los identificadores principales de la federación de identidades de cargas de trabajo, consulta Tipos de principales.

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"

Haz los cambios siguientes:

  • SERVICE_ACCOUNT_EMAIL: la dirección de correo de la cuenta de servicio
  • PROJECT_NUMBER: el número de proyecto del proyecto que contiene el grupo de identidades de carga de trabajo.
  • POOL_ID: el ID del grupo de identidades de carga de trabajo
  • SUBJECT: el valor esperado del atributo que has asignado a google.subject
  • GROUP: el valor esperado del atributo que has asignado a google.groups
  • ATTRIBUTE_NAME: el nombre de un atributo personalizado en tu asignación de atributos
  • ATTRIBUTE_VALUE: el valor del atributo personalizado en tu asignación de atributos

Configurar el flujo de procesamiento de despliegue

En esta sección se describe cómo usar la federación de identidades de cargas de trabajo en tu canalización de implementación. En las instrucciones de esta sección se da por hecho que tus cargas de trabajo usan la suplantación de identidad de cuentas de servicio para acceder a los recursos. Google Cloud

Azure DevOps

Edita el archivo azure-pipelines.yml y añade 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

Sustituye los siguientes valores:

  • CONNECTION: el nombre de tu conexión de servicio.
  • PROJECT_NUMBER: el número del proyecto que contiene el grupo de identidades de carga de trabajo.
  • POOL_ID: el ID del grupo de identidades de carga de trabajo.
  • PROVIDER_ID: el ID del proveedor del grupo de identidades de carga de trabajo.
  • SERVICE_ACCOUNT_EMAIL: la dirección de correo de la cuenta de servicio, si usas la suplantación de identidad de la cuenta de servicio. Si usas el acceso directo a recursos, omite GoogleCloud.WorkloadIdentity.ServiceAccount y service_account_impersonation_url.

La configuración hace lo siguiente:

  1. Usa la tarea AzureCLI para obtener un token de ID de la conexión de 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 indica a las bibliotecas de cliente que lean el token de ID de .workload_identity.jwt y lo usen para suplantar la identidad de una cuenta de servicio.
  4. Define la variable de entorno GOOGLE_APPLICATION_CREDENTIALS para que apunte al archivo de configuración de la credencial.

GitHub Actions

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 de cliente y las herramientas, como terraform, pueden usar este archivo de configuración de credenciales para obtener automáticamente credenciales de Google.

Edita el archivo YAML de GitHub Actions y añade lo siguiente:

  • Permite que la tarea obtenga un token de ID de GitHub añadiendo la siguiente configuración:

    permissions:
  id-token: write
  contents: read

  • Añade 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'

Haz los cambios siguientes:

  • PROJECT_NUMBER: número del proyecto que contiene el grupo de identidades de carga de trabajo.
  • POOL_ID: el ID del grupo de identidades de carga de trabajo.
  • PROVIDER_ID: el ID del proveedor de grupos de identidades de carga de trabajo.
  • SERVICE_ACCOUNT_EMAIL: la dirección de correo de la cuenta de servicio, si usas la suplantación de identidad de la cuenta de servicio. Si usas el acceso directo a recursos, omite service_account.

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 información sobre cómo usar la acción google-github-actions/auth, consulta el artículo Configurar la federación de identidades de cargas de trabajo.

SaaS de GitLab

Edita el archivo .gitlab-ci.yml y añade 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

Sustituye los siguientes valores:

  • PROJECT_NUMBER: el número del proyecto que contiene el grupo de identidades de carga de trabajo.
  • POOL_ID: el ID del grupo de identidades de carga de trabajo.
  • PROVIDER_ID: el ID del proveedor del grupo de identidades de carga de trabajo.
  • SERVICE_ACCOUNT_EMAIL: la dirección de correo de la cuenta de servicio, si usas la suplantación de identidad de la cuenta de servicio. Si usas el acceso directo a recursos, omite SERVICE_ACCOUNT y service_account_impersonation_url.

La configuración hace lo siguiente:

  1. 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 tu proveedor de grupos de identidades de carga de trabajo como audiencia.
  2. Guarda el token de ID en un archivo temporal llamado .workload_identity.jwt.
  3. Crea un archivo de configuración de credenciales que indica a las bibliotecas de cliente que lean el token de ID de .workload_identity.jwt y lo usen para suplantar la identidad de una cuenta de servicio.
  4. Define la variable de entorno GOOGLE_APPLICATION_CREDENTIALS para que apunte al archivo de configuración de la credencial.

Terraform Cloud

Configura tu espacio de trabajo de Terraform Cloud para que use la federación de identidades de carga de trabajo para autenticarse en Google Cloud mediante la suplantación de cuentas de servicio:

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

  2. Añade las siguientes variables:

    Categoría de 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 de la cuenta de servicio, si utilizas la suplantación de identidad de la cuenta de servicio. Por ejemplo, terraform@my-project-123.iam.gserviceaccount.com. Omite esta variable de entorno si utilizas el acceso directo a recursos.
    Variable de entorno TFC_GCP_PROJECT_NUMBER Número del proyecto que contiene el grupo de identidades de carga de trabajo
    Variable de entorno TFC_GCP_WORKLOAD_POOL_ID El ID del grupo de identidades de carga de trabajo
    Variable de entorno TFC_GCP_WORKLOAD_PROVIDER_ID ID del proveedor de grupos de identidades de carga de trabajo

    Si usas la suplantación de identidad de cuentas de servicio, puedes añadir variables de entorno adicionales para que Terraform Cloud use diferentes cuentas de servicio en las fases plan y apply. Para obtener más información sobre el uso de variables de entorno en configuraciones de Terraform, consulta Variables de entorno opcionales.

  3. En la lista de variables, compruebe que Categoría tenga el valor env en las cinco variables que ha añadido en el paso anterior.

  4. Comprueba que tu configuración de Terraform utilice la versión 4.48.0 o una posterior del proveedor 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 al repositorio de código fuente.

Siguientes pasos