Permitir que los clientes accedan a sus recursos de Trusted Cloud by S3NS desde tu producto o servicio

En este documento se describen los requisitos y las prácticas recomendadas que puede seguir para permitir que los clientes usen su producto para acceder a sus recursos en Trusted Cloud sin usar claves de cuenta de servicio.

Si ofreces un producto o un servicio que permite a los clientes analizar o gestionar datos o recursos, es posible que quieran acceder a datos u otros recursos en su entorno de Trusted Cloud . Estos son algunos ejemplos de productos y servicios:

• Productos de analíticas de datos: es posible que tus clientes quieran usar estos productos para analizar sus datos en BigQuery.
• Productos y servicios de CI/CD: tus clientes pueden usar estos servicios para desplegar infraestructura y aplicaciones en sus Trusted Cloud proyectos.
• Automatización de procesos robóticos (RPA): tus clientes pueden usar la RPA para flujos de trabajo como crear proyectos, gestionar el acceso o automatizar tareas administrativas en Trusted Cloud.

Para autenticar productos on-premise o de software como servicio (SaaS) en Trusted Cloud, los clientes han utilizado tradicionalmente claves de cuentas de servicio, pero estas claves pueden ser difíciles de gestionar y almacenar de forma segura.

Como proveedor de un producto local o SaaS, puedes ayudar a tus clientes a proteger sus Trusted Cloud recursos permitiéndoles usar la federación de identidades de carga de trabajo para acceder a sus Trusted Cloud recursos. Entre los servicios que ya permiten a sus clientes usar Workload Identity Federation se incluyen Terraform Cloud y GitHub, así como GitLab.

En este documento se describe cómo puede ampliar su producto para que sea compatible con la federación de identidades de carga de trabajo y se indican las prácticas recomendadas que puede seguir. En este documento se da por supuesto que conoces la federación de identidades de cargas de trabajo y OpenID Connect.

Arquitectura

El objetivo de la federación de identidades de carga de trabajo es eliminar la necesidad de usar claves de cuentas de servicio. Para ello, permite que tus clientes federen tu producto o servicio con su entorno deTrusted Cloud . De esta forma, tus clientes podrán acceder a sus Trusted Cloud recursos mediante una identidad confirmada por tu producto o servicio.

Para que tus clientes puedan usar la federación de identidades de carga de trabajo, tu producto o servicio debe implementar un subconjunto de OpenID Connect. En concreto, debes permitir que las cargas de trabajo obtengan un token de ID que cumpla los siguientes criterios:

• El token identifica la carga de trabajo en tu producto o plataforma.
• El token identifica la instancia, el arrendatario o la instalación de tu producto o plataforma.
• El token contiene una firma criptográfica que Workload Identity Federation puede usar para verificar la autenticidad del token.

Requisitos

Para admitir la federación de identidades de carga de trabajo, debe asegurarse de que su producto o servicio cumpla los siguientes requisitos:

1. Las cargas de trabajo tienen acceso a un token de ID válido.

   En cualquier momento de su ciclo de vida, una carga de trabajo debe tener acceso a un token de ID que afirme la identidad de la carga de trabajo y cumpla los requisitos definidos por OpenID Connect 1.0.

   Como los tokens de ID tienen una vida útil limitada, debes asegurarte de que un token de ID dure más que su carga de trabajo o de que las cargas de trabajo puedan obtener periódicamente tokens de ID nuevos.

2. Los tokens de ID identifican de forma única la carga de trabajo.

   El token de ID debe contener al menos una reclamación que identifique de forma única la carga de trabajo. El identificador de carga de trabajo debe ser inmutable.

   En el caso de los productos o servicios que admiten multitenencia, el token también debe contener al menos una reclamación que identifique de forma única al arrendatario. El identificador de cliente también debe ser inmutable.

3. Los tokens de ID están firmados, pero no cifrados.

4. Los metadatos del proveedor de OpenID son de acceso público y se pueden descubrir a partir de tokens de ID.

   Debe proporcionar un documento de configuración de proveedor de OpenID en un endpoint accesible públicamente que se pueda descubrir mediante el protocolo de descubrimiento de emisores de OpenID. Por ejemplo, si los tokens de ID contienen una reclamación iss con el valor https://service.example.com/v1/, debe proporcionar un documento de configuración del proveedor de OpenID en https://service.example.com/v1/.well-known/openid-configuration y el endpoint debe ser accesible públicamente a través de Internet desde cualquier dirección IP.

5. Las claves de firma son accesibles públicamente y se pueden descubrir a partir de los metadatos del proveedor de OpenID.

   Debe proporcionar un documento JSON Web Key Set (JWKS) en un endpoint accesible públicamente que se pueda descubrir desde el campo jwks_uri de los metadatos del proveedor de OpenID.

Prácticas recomendadas

Cuando amplíe su producto o servicio para que sea compatible con la federación de identidades de cargas de trabajo, tenga en cuenta las siguientes prácticas recomendadas.

Diferencias entre tokens de identidad y de acceso

En el contexto de la federación de identidades de cargas de trabajo, el objetivo de un token de ID es afirmar la identidad de la carga de trabajo. El token debe contener información suficiente para que la federación de identidades de cargas de trabajo identifique la carga de trabajo y la distinga de otras cargas de trabajo.

A diferencia de los tokens de ID, los tokens de acceso suelen tener un propósito diferente: se usan para tomar decisiones de acceso y pueden contener información sobre los permisos que tiene una carga de trabajo o a qué APIs puede acceder.

Si tu producto o servicio usa tokens de acceso para fines como permitir que las cargas de trabajo llamen a la API de tu producto, es posible que estos tokens de acceso no sean adecuados para la federación de identidades de carga de trabajo. En lugar de reutilizar tokens de acceso como tokens de ID, considera la posibilidad de introducir un segundo tipo de token que coincida con la definición de un token de ID y permite que las cargas de trabajo usen el token de ID para la federación de identidades de carga de trabajo.

Exponer tokens de ID de forma compatible con las bibliotecas de cliente

Las bibliotecas de cliente Trusted Cloud pueden obtener automáticamente tokens de ID de varias fuentes, incluidas las siguientes:

• Un endpoint HTTP (credenciales procedentes de una URL)
• Un archivo local (credenciales procedentes de un archivo)

Para obtener tokens de ID de otras fuentes, es posible que tus clientes tengan que modificar su código o implementar herramientas o bibliotecas adicionales. Si expones los tokens de ID de forma compatible con las bibliotecas de cliente, puedes evitar esta complejidad adicional y facilitar a tus clientes la adopción de la federación de identidades de carga de trabajo.

Usar URLs de entidad emisora específicas del arrendatario

Las reclamaciones insertadas en el token de ID de una carga de trabajo pueden ser únicas en una instancia específica de tu producto o servicio, pero no en varias instancias de tu producto o servicio. Por ejemplo, dos de sus clientes pueden usar su producto o servicio para desplegar una carga de trabajo y, sin querer, asignar a esas cargas de trabajo el mismo nombre e ID.

La federación de identidades de carga de trabajo intenta compensar esta posible falta de singularidad verificando la URL del emisor (iss) de los tokens de ID y permitiendo solo tokens de un único emisor por grupo de identidades de carga de trabajo.

Si su producto o servicio admite la arquitectura multiempresa, es posible que varios de sus clientes compartan una sola instancia de su producto o servicio, y que los tokens de ID de sus cargas de trabajo utilicen la misma URL de emisor. Si se usa la misma URL de emisor en varios arrendatarios, los clientes pueden sufrir ataques de suplantación de identidad. Por ejemplo, un agente malintencionado podría crear una carga de trabajo en su propio arrendatario, asignarle el mismo ID o nombre que a una carga de trabajo del arrendatario de la víctima y usar el token de ID de su carga de trabajo para suplantar la identidad de la carga de trabajo de la víctima.

Para proteger a tus clientes frente a ataques de suplantación de identidad, evita usar las mismas URLs de emisor en varios arrendatarios e inserta un ID de arrendatario único en la URL del emisor. Por ejemplo, https://saas.example.com/tenant-123/.

Permitir que los usuarios especifiquen la audiencia del token de ID

Es posible que algunas de las cargas de trabajo de tu cliente necesiten acceder a Trusted Cloud y a otros servicios de terceros. Cuando los clientes deciden federar su producto o servicio con varios terceros de confianza, pueden encontrarse en una situación en la que el token de ID de una carga de trabajo se utilice de forma inadvertida o malintencionada para el tercero de confianza incorrecto. Por ejemplo, un agente malintencionado puede engañar a una carga de trabajo para que revele un token de ID destinado a un servicio de terceros y, a continuación, usar ese token de ID para la federación de identidades de carga de trabajo.

Para evitar que tus clientes sean víctimas de este tipo de ataques de confusión de privilegios, no uses una audiencia estática (aud reclamación) en los tokens de ID. En su lugar, permite que las cargas de trabajo especifiquen una audiencia cuando obtengan un token de ID y, opcionalmente, mantén una lista de permitidos de las audiencias que pueden solicitar las cargas de trabajo.

De forma predeterminada, la federación de identidades de cargas de trabajo espera que la audiencia de un token de ID coincida con la URL https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID. Asegúrate de que las cargas de trabajo puedan usar una URL como audiencia de los tokens de ID y de que la longitud de la URL de la audiencia sea inferior a 180 caracteres.

Usar identificadores inmutables y no reutilizables en las reclamaciones de tokens de ID

Cuando los clientes quieren conceder acceso a uno de sus recursos a sus cargas de trabajo, deben crear un enlace de IAM que haga referencia a la identidad de la carga de trabajo por asunto, grupo o atributo personalizado. Trusted CloudEl asunto, el grupo y los atributos personalizados de la identidad de la carga de trabajo se derivan de las reclamaciones del token de ID de la carga de trabajo.

Si un cliente crea un enlace de IAM que hace referencia a una reclamación mutable, es posible que su carga de trabajo pierda el acceso por error cuando cambie el valor de la reclamación. Por ejemplo, un cliente puede crear un enlace de IAM que haga referencia al nombre de su carga de trabajo. Si posteriormente cambian el nombre de la carga de trabajo, es posible que la vinculación de gestión de identidades y accesos ya no se aplique.

Lo que es peor, los agentes malintencionados podrían intentar obtener acceso no autorizado a otros recursos cambiando deliberadamente el nombre de las cargas de trabajo o modificando el entorno de una carga de trabajo para suplantar la identidad de otra.

Para ayudar a los clientes a evitar este tipo de problemas de suplantación de identidad, asegúrate de que los tokens de ID contengan identificadores que sean inmutables y no se puedan reutilizar.

Incluir información de contexto en los tokens de ID

En lugar de conceder a las cargas de trabajo acceso incondicional a los recursos de Trusted Cloud , los clientes pueden querer restringir el acceso para que una carga de trabajo solo pueda obtener credenciales de Google cuando se cumplan determinados criterios adicionales.

Para permitir que los clientes configuren estas restricciones, incluya reclamaciones adicionales en el token de ID que contengan información de contexto. Estos son algunos ejemplos de información contextual:

• Información sobre el usuario propietario o que ha iniciado la carga de trabajo.
• El motivo y la forma en que se inició la carga de trabajo
• la solicitud que está gestionando la carga de trabajo

Los clientes pueden usar estas reclamaciones para configurar condiciones de atributos o identificadores principales.

Limitar la duración del token de ID a 60 minutos

Los tokens de ID tienen una duración limitada determinada por la reclamación exp. Cuando una carga de trabajo usa un token de ID para realizar un intercambio de tokens, la federación de identidades de cargas de trabajo valida la reclamación exp del token de ID y emite un token de STS que es válido durante el mismo tiempo que el token de entrada, pero como máximo durante 1 hora.

Usar tokens de ID válidos durante más de una hora no afecta a la federación de identidades de carga de trabajo, pero puede aumentar los riesgos si un token de ID se filtra por error. Usar un tiempo de vida significativamente inferior a 1 hora puede ayudar a reducir estos riesgos, pero puede provocar intercambios de tokens frecuentes y un rendimiento menor.

Siguientes pasos

• Consulta más información sobre la federación de identidades de cargas de trabajo.
• Consulta las prácticas recomendadas para usar la federación de identidades de cargas de trabajo.