Prácticas recomendadas para usar la federación de identidades para cargas de trabajo

La federación de identidades de cargas de trabajo permite que las aplicaciones que se ejecutan fuera de Google Cloud actúen en nombre de una cuenta de servicio mediante credenciales de un proveedor de identidad externo.

El uso de la federación de Workload Identity puede ayudarte a mejorar la seguridad, ya que permite que las aplicaciones usen los mecanismos de autenticación que proporciona el entorno externo y puede reemplazar las claves de la cuenta de servicio.

Para usar la federación de Workload Identity de forma segura, debes configurarla de modo que te proteja de las siguientes amenazas:

Falsificación de identidad: Una entidad que actúa de mala fe podría intentar falsificar la identidad de otro usuario para obtener acceso no autorizado a los recursos de Google Cloud
Elevación de privilegios: una persona que actúa de mala fe puede aprovechar la federación de Workload Identity para obtener acceso a recursos a los que no tendría acceso.
Sin repudio: una persona malintencionada puede ocultar su identidad y acciones mediante credenciales externas que dificultan el seguimiento de las acciones que recibe.

En esta guía, se presentan las prácticas recomendadas para decidir cuándo usar la federación de Workload Identity y cómo configurarla de una manera que te ayude a minimizar los riesgos.

Cuándo usar la federación de Workload Identity

Recomendaciones:

Usa la federación de Workload Identity para aplicaciones que tienen acceso a credenciales ambientales.
Usa un intercambio de tokens adicional para usar credenciales de ambiente que no sean compatibles con la federación de Workload Identity.
Usa la federación de Workload Identity para reducir la cantidad de credenciales que requieren rotación.

Usa la federación de Workload Identity para aplicaciones que tienen acceso a credenciales ambientales

Las aplicaciones que se ejecutan en proveedores de servicios en la nube que no sean Google Cloud a menudo tienen acceso a las credenciales del ambiente. Estas son credenciales que la aplicación puede obtener sin tener que realizar ninguna autenticación adicional. Los ejemplos incluyen:

En AWS, las aplicaciones implementadas en EC2 pueden usar perfiles de instancias para asumir una función y obtener credenciales temporales.
En Azure, las aplicaciones pueden usar identidades administradas para obtener tokens de acceso.
En GitHub Actions, los flujos de trabajo pueden obtener tokens de ID que reflejan la identidad del trabajo de implementación.

Si las credenciales de ambiente son tokens de OpenID Connect (OIDC), aserciones de SAML o credenciales de AWS, puedes configurar la federación de Workload Identity a fin de permitir que las aplicaciones intercambien estas credenciales para los tokens de acceso de Google de corta duración. Si las credenciales de ambiente usan un formato diferente, es posible que primero puedas intercambiarlas por un token de OIDC o aserción de SAML y, luego, usarlas para la federación de Workload Identity.

Usa la federación de Workload Identity cada vez que una aplicación necesite acceder a Google Cloud y tenga acceso a credenciales ambientales.

Usa un intercambio de tokens adicional para usar credenciales de entornos que no sean compatibles con la federación de Workload Identity

En algunos casos, una aplicación puede tener acceso a las credenciales ambientales, pero los tipos de credenciales no son compatibles con la federación de Workload Identity. En estos casos, verifica si un intercambio de tokens adicional te permite convertir la credencial de ambiente en un tipo de credencial que puedas usar para la federación de Workload Identity.

Por ejemplo, si tu aplicación se ejecuta en un entorno de Active Directory, podría tener acceso a las credenciales de Kerberos. Si tienes un proveedor de identidad, como los Servicios de federación de Active Directory (AD FS) en tu entorno que admite la autenticación integrada de Windows, puedes usar estas credenciales de Kerberos para autenticarte en el proveedor de identidad y obtener un token de acceso de OAuth que use el formato JWT. Si usas este token de acceso y la federación de Workload Identity, puedes permitir que la aplicación realice un segundo intercambio de tokens para obtener credenciales de Google de corta duración.

La cadena de intercambios de tokens aumenta la complejidad y puede introducir dependencias adicionales, pero puede evitar que tengas que administrar y proteger las claves de las cuentas de servicio.

Usa la federación de Workload Identity para reducir la cantidad de credenciales que requieren rotación

Las aplicaciones que se integran a un proveedor de identidad de OpenID o SAML suelen usar un secreto del cliente (o una forma de secreto diferente) para autenticarse. Por lo general, este secreto se almacena como parte de la configuración de la aplicación. Para permitir que esta aplicación acceda a Google Cloud, debes decidir entre las siguientes opciones:

Crea una clave de cuenta de servicio y guárdala junto con el otro secreto.
Usa tokens emitidos por el proveedor de identidad existente e intercámbialos por credenciales de Google mediante la federación de Workload Identity.

La primera opción requiere dos secretos, pero la segunda solo requiere uno. Reducir la cantidad de secretos puede ayudarte a simplificar la rotación de secretos, lo que, a su vez, puede ayudar a mejorar la seguridad.

Proporciona protección contra amenazas de falsificación de identidad

Un grupo de Workload Identity no contiene identidades ni cuentas de usuario, lo que lo diferencia de un directorio de usuarios, como Cloud Identity. En su lugar, un grupo de Workload Identity representa una vista que muestra las identidades de los proveedores de identidad externos para que se puedan usar como principales de IAM.

Según cómo configures el grupo de Workload Identity y sus proveedores, la misma identidad externa podría representarse como varias principales de IAM diferentes, o varias identidades externas podrían asignarse al mismo principal de IAM. Estas ambigüedades pueden permitir que personas que actúan de mala fe inicien ataques de falsificación de identidad.

En la siguiente sección, se describen las prácticas recomendadas para ayudarte a evitar asignaciones ambiguas y reducir el riesgo de falsificación de identidad.

Recomendaciones:

Usa condiciones de atributos cuando federes con GitHub o con otros proveedores de identidad multiusuario.
Usa un proyecto dedicado para administrar grupos y proveedores de Workload Identity.
Usa restricciones de políticas de la organización para inhabilitar la creación de proveedores de grupos de identidades para cargas de trabajo en otros proyectos.
Usa un solo proveedor por grupo de Workload Identity para evitar colisiones de sujetos.
Evita federar con el mismo proveedor de identidad dos veces.
Protege el extremo de metadatos de OIDC del proveedor de identidad.
Usa la URL del proveedor de grupos de Workload Identity como público.
Usa atributos inmutables en las asignaciones de atributos.
Usa atributos no reutilizables en las asignaciones de atributos
No permitas que se modifiquen las asignaciones de atributos
No confíes en atributos que no sean estables ni confiables

Usa condiciones de atributos cuando federes con GitHub o con otros proveedores de identidad multiusuario.

La federación de identidades para cargas de trabajo no mantiene un directorio de cuentas de usuario; en su lugar, implementa identidades basadas en reclamaciones: como resultado, cuando dos tokens son emitidos por el mismo el proveedor de identidad (IdP) y sus reclamaciones se asignan al mismo valor google.subject, se supone que los dos tokens identifican al mismo usuario. Para averiguar qué IdP emitió un token, la federación de identidades para cargas de trabajo inspecciona y verifica la URL del emisor del token.

Algunos proveedores, como GitHub y Terraform Cloud, usan una sola URL de entidad emisora en todos sus usuarios. Para estos proveedores, la URL de la entidad emisora identifica todo GitHub o Terraform Cloud, no una organización específica de GitHub o Terraform Cloud.

Cuando usas estos proveedores de identidad, no es suficiente permitir que la federación de identidades para cargas de trabajo verifique la URL de la entidad emisora de un token para garantizar que provenga de una fuente confiable y que sus reclamaciones sean confiables. Te recomendamos que configures una condición de atributo de la federación de identidades para cargas de trabajo para verificar que el token se origine en un usuario de confianza o, en el caso de GitHub o Terraform Cloud, una organización de confianza.

Para obtener más información, consulta Configura una condición de atributo.

Usa un proyecto dedicado para administrar grupos y proveedores de Workload Identity

En lugar de administrar grupos de proveedores de Workload Identity y de varios proyectos, usa un solo proyecto dedicado para administrar grupos y proveedores de Workload Identity. Usa un proyecto dedicado te ayuda a hacer lo siguiente:

Asegúrate de que solo se usen proveedores de identidad de confianza para la federación de Workload Identity.
Controla el acceso de forma centralizada a la configuración de los proveedores y grupos de Workload Identity.
Aplica asignaciones y condiciones de atributos coherentes en todos los proyectos y las aplicaciones.

Puedes usar restricciones de políticas de la organización para aplicar la disciplina de usar un proyecto dedicado a fin de administrar grupos y proveedores de Workload Identity.

Usa restricciones de políticas de la organización para inhabilitar la creación de proveedores de grupos de Workload Identity en otros proyectos

Los usuarios que tengan permiso para crear proveedores de grupos de Workload Identity pueden crear grupos de proveedores de trabajo y proveedores que podrían ser redundantes a los que administras en un proyecto dedicado.

Puedes evitar la creación de nuevos proveedores de grupos de Workload Identity mediante la restricción de política de la organización constraints/iam.workloadIdentityPoolProviders con una regla configurada como Rechazar todo.

Aplica estas restricciones en la raíz de la jerarquía de la organización para denegar la creación de nuevos proveedores de grupos de Workload Identity de forma predeterminada. Crea excepciones para los proyectos en los que deseas permitir la administración de grupos y proveedores de Workload Identity mediante una restricción de política que permita ciertas cuentas de AWS o proveedores de OIDC confiables.

Usa un solo proveedor por grupo de Workload Identity para evitar colisiones de sujetos

La federación de Workload Identity te permite crear más de un proveedor por grupo de Workload Identity. Usar varios proveedores puede ser útil si estos administran las identidades, pero deseas ocultar esta complejidad de las cargas de trabajo que se ejecutan en Google Cloud.

El uso de varios proveedores presenta un riesgo de colisiones de sujetos, en el que la asignación de atributos para google.subject de un proveedor muestra el mismo valor que la asignación de atributos para otro proveedor. El resultado de una colisión es que varias identidades externas se asignan al mismo principal de IAM, lo que hace que las identidades externas no se puedan distinguir en los registros de auditoría de Cloud.

Para evitar colisiones de temas, usa un solo proveedor por grupo de Workload Identity. Si necesitas federar con varios proveedores, crea varios grupos de Workload Identity, cada uno con un solo proveedor de Workload Identity.

Evita federar con el mismo proveedor de identidad dos veces

Puedes federar con el mismo proveedor de identidad varias veces mediante la creación de varios proveedores de grupos de identidades de carga de trabajo que usan la misma configuración o una similar. Si estos proveedores pertenecen al mismo grupo de Workload Identity, esa configuración puede generar colisiones de sujetos. Si los proveedores pertenecen a diferentes grupos de Workload Identity, no se pueden generar conflictos de temas y, en cambio, la misma identidad externa se representa como diferentes principales de IAM.

Asignar una sola identidad externa a varios principales de IAM dificulta analizar a qué recursos tiene acceso una identidad externa en particular. Esta ambigüedad también puede aumentar el riesgo cuando se intenta revocar el acceso: un administrador puede revocar el acceso a un principal, pero puede no estar al tanto de la existencia de otro principal, lo que provoca que la identidad externa conserve el acceso.

Para minimizar el riesgo de ambigüedades, evita la federación con el mismo proveedor de identidad más de una vez. En su lugar, crea un solo grupo y proveedor de Workload Identity y usa una asignación de atributos y una condición que garantice que se pueda usar para todas las identidades externas que requieren acceso a los recursos de Google Cloud.

Protege el extremo de metadatos de OIDC del proveedor de identidad

Cuando federas con un proveedor de OpenID Connect, la federación de Workload Identity descarga de forma periódica los metadatos de OIDC de tu proveedor de identidad. La federación de identidades de cargas de trabajo usa los metadatos del IdP y el conjunto de claves web JSON (JWKS) para validar tokens.

Para garantizar la autenticidad, la comunicación con tu proveedor de identidad está protegida mediante TLS. Si tu proveedor se implementa detrás de un balanceador de cargas o un proxy inverso que finaliza TLS, la conexión TLS garantiza la autenticidad del balanceador de cargas o del proxy inverso, pero no del proveedor de identidad real.

Una persona malintencionada podría aprovechar esta configuración mediante el lanzamiento de un ataque de intermediarios (MITM) en el que reconfigura el balanceador de cargas para permitir que pase las solicitudes JWKS a un extremo malicioso que entrega un conjunto diferente de claves. Si intercambias el JWKS, permitirás que una persona que actúa de mala fe firme los tokens que la federación de Workload Identity considera válidos y podría permitirles falsificar las identidades de otros usuarios.

Para protegerte contra el intercambio de JWKS, asegúrate de que tu IdP se implemente de una manera que lo proteja contra ataques de MITM.

Usa la URL del proveedor del grupo de Workload Identity como público.

Cuando federas con un proveedor de OpenID Connect, la federación de Workload Identity verifica que el público de los tokens (codificados en la reclamación aud) coincida con la configuración de público permitida del proveedor. De manera similar, cuando federas con un proveedor de SAML, la federación de Workload Identity verifica que la aserción de SAML especifique una restricción de público que coincida con el público esperado.

De forma predeterminada, la federación de Workload Identity espera que el público coincida con la URL https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID que identifica de forma única al proveedor de grupos de Workload Identity. Exigir tokens y aserciones para usar esta URL como el público ayuda a reducir el riesgo de un ataque de engaño de aplicación delegada. En este ataque, una persona que actúa de mala fe presenta un token o una aserción SAML para la federación de Workload Identity que no se diseñó a fin de usarse en la federación de Workload Identity, pero en otra API.

Exigir el token o la aserción para contener la URL del proveedor de grupo de Workload Identity de destino te ayuda a garantizar que los clientes solo puedan usar tokens y aserciones que se emitieron específicamente para la federación de Workload Identity.

Usa atributos inmutables en las asignaciones de atributos

A fin de otorgar un permiso de identidad externo para actuar en nombre de una cuenta de servicio, crea una vinculación de IAM que haga referencia a la identidad externa por tema, grupo o atributo personalizado. El asunto, el grupo y los atributos personalizados de la identidad externa se derivan de los atributos que el proveedor de identidad externo pasa a la federación de Workload Identity durante el intercambio de tokens.

Algunos proveedores de identidad permiten a los usuarios cambiar algunos de sus propios atributos. Por ejemplo, es posible que un usuario pueda modificar su dirección de correo electrónico o alias. Si las vinculaciones de IAM hacen referencia a atributos que se pueden modificar, los usuarios podrían perder acceso a ciertos recursos de forma accidental mediante la modificación de su perfil. O, lo que sería peor, las entidades malintencionadas podrían obtener acceso no autorizado a otros recursos mediante la modificación deliberada de sus atributos de usuario para que coincidan con vinculaciones de IAM existentes.

A fin de protegerse de esta amenaza de falsificación de identidad, limita las asignaciones de atributos a los atributos que el usuario no puede modificar o que no pueden modificar.

Usa atributos no reutilizables en las asignaciones de atributos

Cuando otorgas un permiso de identidad externa para actuar en nombre de una cuenta de servicio y, luego, borras al usuario en el proveedor de identidad externo, la vinculación de IAM de la cuenta de servicio no se modifica.

Si luego agregas un usuario nuevo al proveedor de identidad externo y el usuario comparte ciertos atributos con el usuario borrado antes (por ejemplo, la misma dirección de correo electrónico), los usuarios nuevos y los anteriores no se podrán distinguir para la federación de Workload Identity. Como resultado, una vinculación de IAM que se refería solo al usuario anterior podría aplicarse también al usuario nuevo.

Para evitar estas ambigüedades, usa asignaciones de atributos que se basen exclusivamente en atributos que no se pueden volver a usar con el tiempo, como un ID de usuario único.

Si la política de tu empresa permite volver a usar atributos como las direcciones de correo electrónico, evita usar estos atributos en las asignaciones de atributos y usa un atributo diferente que, con el tiempo, esté garantizado.

No permitas que se modifiquen las asignaciones de atributos

La federación de Workload Identity usa asignaciones de atributos para seleccionar qué atributos del proveedor de identidad externo se deben incorporar a un token del STS y cómo se deben traducir los nombres de los atributos. La configuración de las asignaciones de atributos es un paso clave para configurar la relación de confianza entre el proveedor de identidad externo y Google Cloud.

Las asignaciones de atributos también son fundamentales para la seguridad del uso de la federación de Workload Identity: si otorgaste un conjunto principal o principal federado para que actúe en nombre de una cuenta de servicio y, luego, cambias la asignación de atributos, puedes cambiar qué usuarios tienen acceso a la cuenta de servicio.

Modifica las asignaciones de atributos requiere el permiso iam.googleapis.com/workloadIdentityPoolProviders.update. Los roles que contienen este permiso incluyen las siguientes opciones:

Propietario (roles/owner)
Administrador de grupos de Workload Identity de IAM (roles/iam.workloadIdentityPoolAdmin)

Si una persona que actúa de mala fe tiene permiso para modificar las asignaciones de atributos, es posible que pueda cambiar las reglas de asignación de una manera que le permita falsificar su identidad y obtener acceso a una cuenta de servicio. A fin de evitar tales modificaciones maliciosas, asegúrate de que solo algunos usuarios con acceso de administrador tengan permiso para modificar las asignaciones de atributos.

Considera crear un proyecto de Google Cloud dedicado para administrar los grupos de Workload Identity, lo que te ayuda a limitar el riesgo de que los usuarios reciban de forma involuntaria uno de estos roles en un nivel superior de la jerarquía de recursos.

No confíes en atributos que no sean estables ni confiables

Un proveedor de identidad usa atributos para comunicar información sobre los usuarios autenticados. Por lo general, los proveedores de identidad garantizan que algunos atributos sean confiables, pero otros no. Por ejemplo, un proveedor de identidad externo puede incorporar un nombre de usuario y un ID de usuario en un token de OIDC. Ambos atributos identifican de forma única a un usuario y pueden parecer intercambiables. Sin embargo, el proveedor de identidad externo puede garantizar que el ID de usuario sea estable y autorizado, pero permite que se cambien los nombres de usuario.

Si las asignaciones de atributos se basan en atributos que no son estables ni confiables, una persona/entidad que actúa de mala fe puede falsificar su identidad mediante la modificación de su perfil de usuario en el proveedor de identidad externo. Por ejemplo, pueden cambiar su nombre de usuario por el de un usuario que se borró en el proveedor de identidad externo hace poco, pero que aún tiene acceso a una cuenta de servicio en Google Cloud.

Para evitar estos ataques de falsificación de identidad, asegúrate de que las asignaciones de atributos solo dependan de los atributos que el proveedor de identidad externo garantiza que sean estables y confiables.

Cómo brindar protección contra amenazas no repudiantes

Cada vez que observes una actividad sospechosa que afecte a uno de tus recursos en Google Cloud, los registros de auditoría de Cloud son una fuente importante de información para saber cuándo ocurrió la actividad y qué usuarios participaron.

Cuando una aplicación usa la federación de Workload Identity, actúa en nombre de una cuenta de servicio. En los registros de auditoría de Cloud, cualquier actividad que realice la aplicación se atribuye a la cuenta de servicio que se usará. Para reconstruir la cadena completa de eventos que generaron la actividad, debes poder correlacionar los registros de auditoría de Cloud con los registros de tu proveedor de identidad a fin de descubrir qué identidad externa estuvo involucrada y por qué se realizó una actividad.

En esta sección, se describen las prácticas recomendadas que pueden ayudarte a mantener un registro de auditoría que no se pueda rechazar.

Recomendaciones:

Habilita los registros de acceso a los datos para las API de IAM.
Usa una asignación de asunto única.

Habilita los registros de acceso a los datos para las API de IAM

Los servicios como Compute Engine incluyen una sección serviceAccountDelegationInfo en los registros de auditoría de Cloud para ayudarte a identificar y comprender las situaciones de robo de identidad de las cuentas de servicio. Cuando una aplicación usa la federación de Workload Identity, esta sección incluye el asunto del principal que se usó para actuar en nombre de la cuenta de servicio.

No todos los servicios incluyen detalles de robo de identidad en sus registros de auditoría de Cloud. Para ayudar a mantener un registro de auditoría que no se pueda rechazar, también debes registrar todos los eventos de robo de identidad mediante las siguientes acciones: Habilita los registros de acceso a los datos paraAPI del servicio de token de seguridad y la API de Identity and Access Management. Habilita estos registros para todos los proyectos de Cloud que contengan grupos de Workload Identity o cuentas de servicio que se usan en la federación de Workload Identity.

Si habilitas estos registros, te aseguras de que se agregue una entrada a los registros de auditoría de Cloud cada vez que una aplicación use la federación de Workload Identity para intercambiar una credencial externa y actúa en nombre de una cuenta de servicio.

Usa una asignación de asunto única

El tema principal que se usa en la sección serviceAccountDelegationInfo en las entradas de registros de auditoría de Cloud se determina mediante la asignación de atributos del proveedor de grupos de identidades de carga de trabajo para google.subject.

Cuando detectas actividad sospechosa y necesitas saber qué identidad externa estuvo involucrada, debes poder buscar una identidad externa por su valor google.subject correspondiente.

Del mismo modo, cuando una identidad externa se vio comprometida y necesitas averiguar si la identidad se usó para acceder a los recursos de Google Cloud, debes poder encontrar entradas de registros de auditoría de Cloud que correspondan a la identidad externa.

Cuando defines la asignación de atributos para un proveedor de grupo de Workload Identity, elige una asignación única para google.subject de modo que se den las siguientes situaciones:

Una identidad externa se asigna a un solo valor google.subject.
Un valor google.subject se asigna a una identidad externa exacta.
Puedes buscar una identidad externa por su valor google.subject.

Usar una asignación de atributos que cumpla con estos criterios de exclusividad te ayuda a garantizar que puedas buscar identidades externas por su valor de google.subject y viceversa.

Protege contra amenazas de elevación de privilegios

Para aplicar el principio de privilegio mínimo cuando usas la federación de Workload Identity, debes hacer lo siguiente:

Limita la cantidad de identidades externas que pueden actuar como una cuenta de servicio.
Limita los recursos a los que puede acceder una cuenta de servicio.

Una configuración demasiado permisiva puede conducir a una situación en la que una persona que actúa de mala fe puede usar una identidad externa para derivar sus privilegios y acceder a los recursos a los que no debería tener acceso.

En las siguientes secciones, se proporcionan prácticas recomendadas que pueden ayudarte a protegerte contra las amenazas de elevación de privilegios.

Recomendaciones:

Usa cuentas de servicio que residan en el mismo proyecto que los recursos a los que necesitas acceder.
Usa una cuenta de servicio dedicada para cada aplicación.
Evita otorgar acceso a todos los miembros de un grupo.

Usar cuentas de servicio que residan en el mismo proyecto que los recursos a los que necesitas acceder

Cuando un cliente usa la federación de identidades para cargas de trabajo con bibliotecas cliente o la API de REST, se sigue un proceso de tres pasos:

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

Para el último paso, usa una cuenta de servicio que resida en el mismo proyecto que los recursos a los que necesitas acceder. El uso de una cuenta de servicio administrada en el mismo proyecto te ayuda a aplicar permisos de acceso más restringidos y facilita la decisión de cuándo ya no se necesita la cuenta de servicio.

Usa una cuenta de servicio dedicada para cada aplicación

Si tienes varias aplicaciones que usan la federación de Workload Identity a fin de acceder a los recursos en el mismo proyecto, crea una cuenta de servicio dedicada para cada aplicación. Usar las cuentas de servicio específicas de la aplicación te ayuda a evitar el permiso excesivo, ya que solo otorga acceso a los recursos que requiere cada aplicación individual.

Evita otorgar acceso a todos los miembros de un grupo

Antes de que una identidad externa pueda actuar en nombre de una cuenta de servicio, debes otorgarle la función roles/iam.workloadIdentityUser en la cuenta de servicio. Cuando otorgues esta función, evita otorgarla a todos los miembros del grupo de Workload Identity. En su lugar, otorga la función a identidades externas específicas o a identidades que coincidan con ciertos criterios.

En principio, la cantidad de usuarios externos que necesitan acceso a los recursos de Google Cloud puede ser pequeña. Por lo tanto, la condición del atributo del grupo de Workload Identity y la configuración del proveedor de identidad podrían permitir que algunas identidades externas usen la federación de Workload Identity.

Cuando incorpores cargas de trabajo nuevas en Google Cloud, es posible que debas modificar la configuración del proveedor de identidad o la condición del atributo del grupo de Workload Identity para que permita identidades externas adicionales.

Si solo otorgas la función roles/iam.workloadIdentityUser a identidades externas específicas, puedes asegurarte de que crezca de forma segura un grupo de Workload Identity sin otorgar de manera involuntaria más acceso al robo de identidades externas de lo necesario.

¿Qué sigue?

Obtén más información sobre las prácticas recomendadas para trabajar con cuentas de servicio.
Obtén más información sobre las prácticas recomendadas para administrar claves de cuenta de servicio.