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

La federación de identidades de carga de trabajo permite que las aplicaciones que se ejecutan fuera Google Cloud suplanten la identidad de una cuenta de servicio mediante credenciales de un proveedor de identidades externo.

Usar la federación de identidades de carga de trabajo 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 ayudarte a sustituir las claves de las cuentas de servicio.

Para usar la federación de identidades de cargas de trabajo de forma segura, debes configurarla de forma que te proteja de las siguientes amenazas:

  • Suplantación de identidad: un agente malicioso puede intentar suplantar la identidad de otro usuario para obtener acceso no autorizado a los recursos de Google Cloud .
  • Escalada de privilegios: un agente pernicioso podría aprovechar la federación de identidades de carga de trabajo para acceder a recursos a los que, de otro modo, no tendría acceso.
  • No repudio: un agente pernicioso puede ocultar su identidad y sus acciones usando credenciales externas que dificultan el rastreo de las acciones hasta él.
  • Configuraciones de credenciales maliciosas: un agente malicioso podría proporcionar una configuración de credenciales maliciosa para eludir tus defensas de seguridad.

En esta guía se presentan prácticas recomendadas para decidir cuándo usar la federación de identidades de cargas de trabajo y cómo configurarla de forma que te ayude a minimizar los riesgos.

Cuándo usar la federación de identidades de cargas de trabajo

Prácticas recomendadas:

Usa la federación de identidades de cargas de trabajo en aplicaciones que tengan acceso a credenciales de entorno.
Usa un intercambio de tokens adicional para usar credenciales de entorno que no sean compatibles con la federación de identidades de cargas de trabajo.
Usa la federación de identidades de cargas de trabajo para reducir el número de credenciales que requieren rotación.

Usar la federación de identidades de cargas de trabajo en aplicaciones que tengan acceso a credenciales de entorno

Las aplicaciones que se ejecutan en proveedores de servicios en la nube que no son Google Cloud suelen tener acceso a credenciales de entorno. Se trata de credenciales que la aplicación puede obtener sin tener que realizar ninguna autenticación adicional. Estos son algunos ejemplos:

  • En AWS, las aplicaciones implementadas en EC2 pueden usar perfiles de instancia para asumir un rol y obtener credenciales temporales.
  • En Azure, las aplicaciones pueden usar identidades gestionadas para obtener tokens de acceso.
  • En GitHub Actions, los flujos de trabajo pueden obtener tokens de ID que reflejen la identidad del trabajo de implementación.

Si las credenciales del entorno son tokens de OpenID Connect (OIDC), aserciones SAML o credenciales de AWS, puedes configurar la federación de identidades de carga de trabajo para permitir que las aplicaciones intercambien estas credenciales por tokens de acceso de Google de corta duración. Si las credenciales de entorno usan un formato diferente, es posible que puedas cambiarlas por un token de OIDC o una aserción de SAML primero y, después, usarlas para la federación de identidades de carga de trabajo.

Usa la federación de identidades de cargas de trabajo siempre que una aplicación necesite acceder aGoogle Cloud y tenga acceso a credenciales de entorno.

Usar un intercambio de tokens adicional para usar credenciales de entorno que no sean compatibles con la federación de identidades de cargas de trabajo

En algunos casos, una aplicación puede tener acceso a credenciales de entorno, pero los tipos de credenciales no son compatibles con la federación de identidades de carga de trabajo. En estos casos, comprueba 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 identidades de carga de trabajo.

Por ejemplo, si tu aplicación se ejecuta en un entorno de Active Directory, puede que tenga acceso a las credenciales de Kerberos. Si tienes un proveedor de identidades, como los Servicios de federación de Active Directory (AD FS), en tu entorno que admita la autenticación integrada de Windows, puedes usar estas credenciales de Kerberos para autenticarte en el proveedor de identidades y obtener un token de acceso de OAuth que use el formato JWT. Con 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.

Encadenar intercambios de tokens aumenta la complejidad y puede introducir dependencias adicionales, pero puede librarte de tener que gestionar y proteger las claves de cuentas de servicio.

Usar la federación de identidades de cargas de trabajo para reducir el número de credenciales que requieren rotación

Las aplicaciones que se integran con un proveedor de identidades OpenID o SAML suelen usar un secreto de cliente (u otra forma de secreto) para autenticarse en el proveedor de identidades. Normalmente, este secreto se almacena como parte de la configuración de la aplicación. Para permitir que una aplicación de este tipo acceda a Google Cloud, debes elegir entre las siguientes opciones:

  1. Crear una clave de cuenta de servicio y almacenarla junto con el otro secreto.
  2. Usando tokens emitidos por el proveedor de identidades y cambiándolos por credenciales de Google mediante la federación de identidades de cargas de trabajo.

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

Protección contra amenazas de suplantación de identidad

Un grupo de identidades de carga de trabajo no contiene ninguna identidad ni cuenta de usuario, lo que lo diferencia de un directorio de usuarios como Cloud Identity. En su lugar, un pool de identidades de carga de trabajo representa una vista que muestra identidades de proveedores de identidades externos para que se puedan usar como entidades principales de gestión de identidades y accesos.

En función de cómo configure el grupo de identidades de cargas de trabajo y sus proveedores, la misma identidad externa puede representarse como varias cuentas principales de IAM diferentes, o bien varias identidades externas pueden asignarse a la misma cuenta principal de IAM. Estas ambigüedades podrían permitir que los agentes malintencionados lancen ataques de suplantación de identidad.

En la siguiente sección se describen las prácticas recomendadas que le ayudarán a evitar asignaciones ambiguas y a reducir el riesgo de suplantación de identidad.

Prácticas recomendadas:

Utilice condiciones de atributo al federar con GitHub u otros proveedores de identidades multiinquilino.
Usa un proyecto específico para gestionar 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 de carga de trabajo en otros proyectos.
Utiliza un único proveedor por grupo de identidades de carga de trabajo para evitar colisiones de asuntos.
No federes con el mismo proveedor de identidades dos veces.
Protege el endpoint de metadatos de OIDC de tu proveedor de identidades.
Usa la URL del proveedor de grupos de identidades de carga de trabajo como audiencia.
Utilice atributos inmutables en las asignaciones de atributos.
Utilice atributos no reutilizables en las asignaciones de atributos.
No permita que se modifiquen las asignaciones de atributos.
No te fíes de los atributos que no sean estables ni fiables.

Usar condiciones de atributos al federar con GitHub u otros proveedores de identidades multiempresa

Workload Identity Federation no mantiene un directorio de cuentas de usuario, sino que implementa identidades basadas en reclamaciones. Por lo tanto, cuando un mismo proveedor de identidades (IdP) emite dos tokens y sus reclamaciones se asignan al mismo valor de google.subject, se da por hecho que los dos tokens identifican al mismo usuario. Para saber qué IdP ha emitido un token, la federación de identidades de cargas de trabajo inspecciona y verifica la URL del emisor del token.

Algunos proveedores, como GitHub y Terraform Cloud, usan una sola URL de emisor en todos sus arrendatarios. En el caso de estos proveedores, la URL del emisor identifica todo GitHub o Terraform Cloud, no una organización específica de GitHub o Terraform Cloud.

Cuando usas estos proveedores de identidades, no es suficiente con que la federación de identidades de carga de trabajo compruebe la URL del emisor de un token para asegurarse de que procede de una fuente de confianza y de que se puede confiar en sus reclamaciones. Te recomendamos que configures una condición de atributo de Workload Identity Federation para comprobar que el token procede de un arrendatario de confianza o, en el caso de GitHub o Terraform Cloud, de una organización de confianza.

Para obtener más información, consulte el artículo sobre cómo configurar una condición de atributo.

Usar un proyecto específico para gestionar grupos y proveedores de Workload Identity

En lugar de gestionar grupos y proveedores de identidades de carga de trabajo en varios proyectos, usa un solo proyecto específico para gestionarlos. Usar un proyecto específico te permite:

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

Puedes usar restricciones de políticas de la organización para aplicar la disciplina de usar un proyecto específico para gestionar grupos y proveedores de Workload Identity.

Usar restricciones de políticas de organización para inhabilitar la creación de proveedores de grupos de identidades de carga de trabajo en otros proyectos

Los usuarios que tengan permiso para crear proveedores de grupos de identidades de carga de trabajo pueden crear grupos y proveedores de identidades de carga de trabajo que podrían ser redundantes con los que gestionas en un proyecto específico.

Puedes impedir la creación de proveedores de grupos de identidades de carga de trabajo mediante la restricción de política de organización constraints/iam.workloadIdentityPoolProviders con una regla definida como Denegar todo.

Aplica estas restricciones en la raíz de tu jerarquía organizativa para denegar la creación de proveedores de grupos de identidades de carga de trabajo de forma predeterminada. Crea excepciones para los proyectos en los que quieras permitir la gestión de grupos de identidades de carga de trabajo y proveedores aplicando una restricción de política que permita determinadas cuentas de AWS o proveedores de OIDC de confianza.

Usar un solo proveedor por grupo de identidades de carga de trabajo para evitar colisiones de asuntos

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

Si se usan varios proveedores, existe el riesgo de que se produzcan colisiones de asuntos, en las que la asignación de atributos de google.subject de un proveedor devuelva el mismo valor que la asignación de atributos de otro proveedor. El resultado de esta colisión es que se asignan varias identidades externas a la misma cuenta principal de gestión de identidades y accesos, lo que hace que las identidades externas no se puedan distinguir en los registros de auditoría de Cloud.

Para evitar colisiones de asuntos, usa un solo proveedor por grupo de identidades de carga de trabajo. Si necesitas federar con varios proveedores, crea varios grupos de identidades de carga de trabajo, cada uno con un solo proveedor de identidades de carga de trabajo.

Evitar federar con el mismo proveedor de identidades dos veces

Puede federar con el mismo proveedor de identidades varias veces creando varios proveedores de grupos de identidades de carga de trabajo que usen la misma configuración o una similar. Si estos proveedores pertenecen al mismo grupo de identidades de carga de trabajo, esta configuración puede provocar colisiones de asuntos. Si los proveedores pertenecen a grupos de identidades de carga de trabajo diferentes, no se pueden producir colisiones de asuntos y la misma identidad externa se representa como principales de IAM diferentes.

Si asignas una sola identidad externa a varios principales de IAM, será más difícil analizar a qué recursos tiene acceso una identidad externa concreta. Esta ambigüedad también puede aumentar el riesgo al intentar revocar el acceso: un administrador puede revocar el acceso de una entidad de seguridad, pero no ser consciente de la existencia de otra entidad de seguridad, lo que provoca que la identidad externa conserve el acceso por error.

Para minimizar el riesgo de que se produzcan ambigüedades, no federes con el mismo proveedor de identidades más de una vez. En su lugar, cree un único grupo y proveedor de identidades de carga de trabajo, y use una asignación y una condición de atributos que aseguren que se pueda usar para todas las identidades externas que requieran acceso a recursos de Google Cloud .

Proteger el endpoint de metadatos de OIDC de tu proveedor de identidades

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

Para garantizar la autenticidad, la comunicación con tu proveedor de identidades se protege mediante TLS. Si tu proveedor se ha implementado detrás de un balanceador de carga o un proxy inverso que termina la conexión TLS, la conexión TLS asegura la autenticidad del balanceador de carga o del proxy inverso, pero no la del proveedor de identidad real.

Un agente malintencionado podría aprovechar esta configuración lanzando un ataque man-in-the-middle (MITM) en el que reconfigura el balanceador de carga para que envíe solicitudes JWKS a un endpoint malicioso que sirve un conjunto de claves diferente. Si se cambia el JWKS, un agente malintencionado puede firmar tokens que Workload Identity Federation considere válidos, lo que podría permitirle suplantar la identidad de otros usuarios.

Para protegerte contra la sustitución de JWKS, asegúrate de que tu IdP se haya implementado de forma que lo proteja contra ataques MITM.

Usar la URL del proveedor de grupos de identidades de carga de trabajo como audiencia

Cuando federas con un proveedor de OpenID Connect, la federación de identidades de carga de trabajo verifica que la audiencia de los tokens (codificada en la reclamación aud) coincida con el ajuste de audiencia permitida del proveedor. Del mismo modo, cuando se federa con un proveedor de SAML, la federación de identidades de carga de trabajo comprueba que la aserción de SAML especifica una restricción de audiencia que coincide con la audiencia esperada.

De forma predeterminada, la federación de identidades de cargas de trabajo espera que la audiencia coincida con la URLhttps://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID que identifica de forma única al proveedor de grupos de identidades de carga de trabajo. Requerir tokens y aserciones para usar esta URL como audiencia ayuda a reducir el riesgo de un ataque de confused deputy. En este tipo de ataque, un agente malintencionado presenta un token o una aserción SAML a la federación de identidades de carga de trabajo que no se ha diseñado para la federación de identidades de carga de trabajo, sino para otra API.

Si exiges que el token o la aserción contengan la URL del proveedor de identidades de carga de trabajo de destino, te aseguras de que los clientes solo puedan usar tokens y aserciones que se hayan emitido específicamente para la federación de identidades de carga de trabajo.

Usar atributos inmutables en las asignaciones de atributos

Para conceder permiso a una identidad externa para suplantar una cuenta de servicio, crea un enlace de IAM que haga referencia a la identidad externa por asunto, grupo o atributo personalizado. Los atributos de asunto, grupo y personalizados de la identidad externa se derivan de los atributos que el proveedor de identidades externo transfiere a la federación de identidades de carga de trabajo durante el intercambio de tokens.

Algunos proveedores de identidades permiten que los usuarios cambien algunos de sus atributos. Por ejemplo, se puede permitir que un usuario modifique su dirección de correo o sus alias. Si tus enlaces de gestión de identidades y accesos hacen referencia a atributos que se pueden modificar, los usuarios podrían perder el acceso a determinados recursos por error al modificar su perfil de usuario. O, lo que es peor, los agentes malintencionados podrían obtener acceso no autorizado a otros recursos modificando deliberadamente sus atributos de usuario para que coincidan con las vinculaciones de gestión de identidades y accesos.

Para protegerse frente a esta amenaza de suplantación de identidad, limite las asignaciones de atributos a atributos que el usuario no pueda modificar o que no se puedan modificar en absoluto.

Usar atributos no reutilizables en las asignaciones de atributos

Si concede a una identidad externa permiso para suplantar la identidad de una cuenta de servicio y, posteriormente, elimina el usuario en el proveedor de identidades externo, el enlace de IAM de la cuenta de servicio se mantendrá.

Si más adelante añades un nuevo usuario a tu proveedor de identidades externo y este comparte determinados atributos con el usuario eliminado anteriormente (por ejemplo, la misma dirección de correo electrónico), no se podrá distinguir entre el usuario antiguo y el nuevo en la federación de identidades de carga de trabajo. Por lo tanto, una vinculación de IAM que solo se refería al usuario antiguo también podría aplicarse al nuevo.

Para evitar este tipo de ambigüedades, usa mapeos de atributos que se basen exclusivamente en atributos que no se puedan reutilizar con el tiempo, como un ID de usuario único.

Si la política de tu empresa permite reutilizar atributos como las direcciones de correo electrónico, no utilices estos atributos en las asignaciones de atributos y usa otro atributo que sea único a lo largo del tiempo.

No permitir que se modifiquen las asignaciones de atributos

La federación de identidades de carga de trabajo usa asignaciones de atributos para seleccionar qué atributos proporcionados por el proveedor de identidades externo se deben insertar en un token de STS y cómo se deben traducir los nombres de los atributos. Configurar las asignaciones de atributos es un paso clave para establecer la relación de confianza entre el proveedor de identidades externo y Google Cloud.

Las asignaciones de atributos también son cruciales para la seguridad de la federación de identidades de carga de trabajo: si has concedido a un principal federado o a un conjunto de principales la capacidad de suplantar la identidad de una cuenta de servicio y luego cambias la asignación de atributos, es posible que cambies los usuarios que tienen acceso a la cuenta de servicio.

Para modificar las asignaciones de atributos, se necesita el permiso iam.googleapis.com/workloadIdentityPoolProviders.update. Los roles que contienen este permiso son los siguientes:

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

Si un agente malintencionado tiene permiso para modificar las asignaciones de atributos, podría cambiar las reglas de asignación de forma que le permita suplantar su identidad y obtener acceso a una cuenta de servicio. Para evitar este tipo de modificaciones maliciosas, asegúrate de que solo unos pocos usuarios administradores tengan permiso para modificar las asignaciones de atributos.

Te recomendamos que crees un Google Cloud proyecto específico para gestionar los grupos de identidades de carga de trabajo, lo que te ayudará a limitar el riesgo de que se conceda por error a los usuarios uno de estos roles en un nivel superior de la jerarquía de recursos.

No te bases en atributos que no sean estables ni fiables

Un proveedor de identidades usa atributos para comunicar información sobre los usuarios autenticados. Los proveedores de identidades suelen garantizar que algunos atributos son autorizados, pero otros no. Por ejemplo, un proveedor de identidades externo puede insertar tanto un nombre de usuario como 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 identidades externo puede garantizar que el ID de usuario sea estable y autorizado, pero permitir que se cambien los nombres de usuario.

Si tus asignaciones de atributos dependen de atributos que no son estables ni autorizados, un agente malintencionado podría falsificar su identidad modificando su perfil de usuario en el proveedor de identidades externo. Por ejemplo, puede cambiar su nombre de usuario por el de un usuario que se haya eliminado recientemente en el proveedor de identidades externo, pero que siga teniendo acceso a una cuenta de servicio en Google Cloud.

Para evitar este tipo de ataques de suplantación de identidad, asegúrese de que sus asignaciones de atributos solo se basen en atributos que el proveedor de identidades externo garantice que son estables y autorizados.

Protección frente a amenazas de no repudio

Cuando detectes actividad sospechosa que afecte a uno de tus recursos enGoogle Cloud, los registros de auditoría de Cloud serán una fuente de información importante para averiguar cuándo se produjo la actividad y qué usuarios estuvieron implicados.

Cuando una aplicación usa la federación de identidades de cargas de trabajo, suplanta la identidad de una cuenta de servicio. En Registros de auditoría de Cloud, cualquier actividad realizada por la aplicación se atribuye a la cuenta de servicio suplantada. Para reconstruir la cadena completa de eventos que han llevado a la actividad, debe poder correlacionar los registros de auditoría de Cloud con los registros de su proveedor de identidades para saber qué identidad externa ha estado implicada y por qué se ha realizado una actividad.

En esta sección se describen las prácticas recomendadas que pueden ayudarte a mantener una pista de auditoría irrefutable.

Prácticas recomendadas:

Habilita los registros de acceso a datos de las APIs de gestión de identidades y accesos.
Usa una asignación de asunto única.

Habilitar los registros de acceso a datos de las APIs de IAM

Para ayudarte a identificar y comprender los casos de suplantación de identidad de cuentas de servicio, servicios como Compute Engine incluyen una sección serviceAccountDelegationInfo en los registros de auditoría de Cloud. Cuando una aplicación usa la federación de identidades de cargas de trabajo, esta sección incluye el asunto de la principal que se ha usado para suplantar la identidad de la cuenta de servicio.

No todos los servicios incluyen detalles de suplantación de identidad en los registros de auditoría de Cloud. Para mantener un registro de auditoría irrefutable, también debes registrar todos los eventos de suplantación habilitando los registros de acceso a datos de la API Security Token Service y la API Identity and Access Management. Habilita estos registros en todos los proyectos de Cloud que contengan grupos de identidades de carga de trabajo o cuentas de servicio que se usen para la federación de identidades de carga de trabajo.

Si habilitas estos registros, te aseguras de que se añada una entrada a los registros de auditoría de Cloud cada vez que una aplicación use la federación de identidades de carga de trabajo para intercambiar una credencial externa y suplantar la identidad de una cuenta de servicio.

Usar un mapeado de asunto único

El elemento principal usado en la sección serviceAccountDelegationInfo de las entradas de registros de auditoría de Cloud se determina mediante la asignación de atributos de google.subject de tu proveedor de grupo de identidades de carga de trabajo.

Cuando detecte actividad sospechosa y necesite saber qué identidad externa está implicada, debe poder buscar una identidad externa por su valor google.subject correspondiente.

Del mismo modo, si se ha vulnerado una identidad externa y necesitas saber si se ha usado para acceder a recursos de Google Cloud , debes poder encontrar las entradas de Cloud Audit Logs que correspondan a la identidad externa.

Cuando defina la asignación de atributos de un proveedor de grupos de identidades de carga de trabajo, elija una asignación única para google.subject de forma que:

  • Una identidad externa se asigna exactamente a un valor de google.subject.
  • Un valor de google.subject se asigna exactamente a una identidad externa.
  • Puedes buscar una identidad externa por su valor google.subject.

Si usa una asignación de atributos que cumpla estos criterios de unicidad, podrá buscar identidades externas por su valor google.subject y valores google.subject por sus identidades externas.

Protección contra amenazas de apropiación de privilegios

Para aplicar el principio de mínimos accesos al usar la federación de identidades de cargas de trabajo, debes hacer lo siguiente:

  • Limitar el número de identidades externas que pueden suplantar la identidad de una cuenta de servicio
  • Limitar los recursos a los que puede acceder una cuenta de servicio

Una configuración demasiado permisiva puede provocar que un agente malintencionado use una identidad externa para aumentar sus privilegios y acceder a recursos a los que no debería tener acceso.

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

Prácticas recomendadas:

Usa cuentas de servicio que se encuentren en el mismo proyecto que los recursos a los que necesites acceder.
Usa una cuenta de servicio específica para cada aplicación.
No concedas acceso a todos los miembros de un grupo.

Usa cuentas de servicio que se encuentren en el mismo proyecto que los recursos a los que necesites acceder

Cuando un cliente usa la federación de identidades de carga de trabajo mediante bibliotecas de cliente o la API REST, sigue un proceso de tres pasos:

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

En el último paso, usa una cuenta de servicio que resida en el mismo proyecto que los recursos a los que necesites acceder. Si usas una cuenta de servicio gestionada en el mismo proyecto, podrás aplicar permisos de acceso más restrictivos y te resultará más fácil decidir cuándo ya no necesites la cuenta de servicio.

Usar una cuenta de servicio específica para cada aplicación

Si tienes varias aplicaciones que usan la federación de identidades de carga de trabajo para acceder a recursos del mismo proyecto, crea una cuenta de servicio específica para cada aplicación. Usar cuentas de servicio específicas de aplicaciones te ayuda a evitar que se concedan permisos en exceso, ya que solo se concede acceso a los recursos que requiere cada aplicación.

No concedas acceso a todos los miembros de un grupo

Para que una identidad externa pueda usar la identidad de una cuenta de servicio, debes concederle el rol roles/iam.workloadIdentityUser en la cuenta de servicio. Cuando concedas este rol, evita asignarlo a todos los miembros del grupo de identidades de carga de trabajo. En su lugar, concede el rol a identidades externas específicas o a identidades que cumplan determinados criterios.

Al principio, puede que el número de usuarios externos que necesiten acceder a los recursos de Google Cloud sea reducido. Por lo tanto, la condición de atributo de tu grupo de identidades de carga de trabajo y la configuración de tu proveedor de identidades solo pueden permitir que unas pocas identidades externas usen la federación de identidades de cargas de trabajo.

Cuando incorpores nuevas cargas de trabajo a Google Cloudmás adelante, es posible que tengas que modificar la configuración de tu proveedor de identidades o la condición de atributo del grupo de identidades de carga de trabajo para que permita identidades externas adicionales.

Si solo asignas el rol roles/iam.workloadIdentityUser a identidades externas específicas, puedes asegurarte de que puedes aumentar de forma segura un grupo de identidades de carga de trabajo sin conceder por error a más identidades externas acceso de suplantación del necesario.

Protección frente a configuraciones de credenciales maliciosas

Algunas configuraciones de credenciales contienen URLs y rutas de archivo que, si una carga de trabajo no las valida correctamente, podrían provocar que la carga de trabajo use endpoints maliciosos.

Prácticas recomendadas:

Valida las configuraciones de las credenciales de una fuente externa antes de usarlas para autenticarte en las APIs de Google.

Validar las configuraciones de credenciales de una fuente externa antes de usarlas para autenticar las APIs de Google

Cuando aceptes una configuración de credenciales de una fuente externa, debes validar el JSON antes de usarlo. Si no valida la configuración de las credenciales, un agente malintencionado podría usarla para que su carga de trabajo acceda a endpoints maliciosos.

Para obtener más información, consulta Requisitos de seguridad al usar configuraciones de credenciales de una fuente externa.

Siguientes pasos