Permitir que los clientes accedan a sus recursos de Google Cloud desde tu producto o servicio

En este artículo, se describen los requisitos y las prácticas recomendadas que puedes seguir para permitir que los clientes usen tu producto para acceder a sus recursos en Google Cloud sin usar las.claves de cuenta de servicio.

Si ofreces un producto o tienes un servicio que permite a los clientes analizar o administrar datos o recursos, es posible que tus clientes quieran acceder a datos o a otros recursos en su entorno de Google Cloud. Los siguientes son algunos ejemplos de esos productos y servicios:

  • Productos de análisis de datos: Es posible que tus clientes quieran usar esos productos para analizar sus datos en BigQuery.
  • Productos y servicios de CI/CD: Tus clientes pueden usar estos servicios para implementar infraestructura y aplicaciones en sus proyectos de Google Cloud.
  • Automatización de procesos robólicos (RPA): Tus clientes pueden usar RPA para flujos de trabajo como crear proyectos, administrar acceso o automatizar tareas administrativas en Google Cloud.

Para autenticar productos locales o de software como servicio (SaaS) en Google Cloud, los clientes dependen, de manera convencional, de las claves de las cuentas de servicio, pero estas claves pueden ser desafíos para administrar y almacenar de forma segura..

Como proveedor de un producto local o SaaS, puedes ayudar a tus clientes a proteger sus recursos de Google Cloud si les permites usar la federación de identidades para cargas de trabajo para acceder a sus recursos de Google Cloud. Los ejemplos de servicios que ya permiten a sus clientes usar la federación de identidades para cargas de trabajo incluyen Terraform Cloud, GitHub y GitLab.

En este artículo, se describe cómo extender tu producto para admitir la federación de identidades para cargas de trabajo y se describe la práctica recomendada que puedes seguir. En el artículo, se supone que estás familiarizado con la federación de identidades para cargas de trabajo y OpenID Connect.

Arquitectura

La intención de la federación de identidades para cargas de trabajo es eliminar la necesidad de claves de cuenta de servicio, ya que permite que tus clientes federen tu producto o servicio con su entorno de Google Cloud. Luego, tus clientes pueden acceder a sus recursos de Google Cloud con una identidad confirmada por tu producto o servicio.

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

  • El token identifica la carga de trabajo dentro de tu producto o plataforma
  • El token identifica la instancia, el usuario o la instalación de tu producto o plataforma.
  • El token contiene una firma criptográfica que la federación de identidades para cargas de trabajo puede usar para verificar la autenticidad del token.

Requisitos

Para admitir la federación de identidades para cargas de trabajo, debes asegurarte de que tu producto o servicio cumpla con 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 confirme la identidad de la carga de trabajo y cumpla con los requisitos definidos por OpenID Connect 1.0.

    Debido a que los tokens de ID tienen una vida útil limitada, debes asegurarte de que un token de ID sobreviva a su carga de trabajo o que las cargas de trabajo puedan obtener tokens de ID nuevos de forma periódica.

  2. Los tokens de ID identifican de forma inequívoca la carga de trabajo.

    El token de ID debe contener al menos una reclamación que identifique de manera inequívoca la carga de trabajo. El identificador de la carga de trabajo debe ser inmutable.

    Para los productos o servicios que admiten multiusuarios, el token también debe contener al menos una reclamación que identifique de manera inequívoca al usuario. El identificador de usuarios también debe ser inmutable.

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

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

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

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

    Debes proporcionar un documento conjunto de claves web JSON (JWKS) en un extremo de acceso público que se pueda descubrir desde el campo jwks_uri en los metadatos del proveedor de OpenID.

Prácticas recomendadas

Cuando extiendas tu producto o servicio para admitir la federación de identidades para cargas de trabajo, ten en cuenta las siguientes recomendaciones.

Prácticas recomendadas:

Diferencia entre tokens de identidad y de acceso.
Expón los tokens de ID de manera compatible con las bibliotecas cliente.
Usa URLs de entidades emisoras específicas de usuarios.
Permite que los usuarios especifiquen el público del token de ID.
Usa identificadores inmutables y no reutilizables en las reclamaciones de token de ID.
Incluye información del contexto en los tokens de ID.
Limita la vida útil del token de ID a 30-60 minutos.

Distingue entre los tokens de identidad y los de acceso

Dentro del contexto de la federación de identidades para cargas de trabajo, el propósito de un token de ID es confirmar la identidad de la carga de trabajo: el token debe contener suficiente información para que la federación de identidades para cargas de trabajo identifique la carga de trabajo y para distinguirla en otras cargas de trabajo.

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

Si tu producto o servicio usa tokens de acceso con 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 para cargas de trabajo. En lugar de volver a usar tokens de acceso como tokens de ID, considera ingresar 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 para cargas de trabajo.

Expón los tokens de ID de una manera compatible con las bibliotecas cliente

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

  • Un extremo HTTP (credenciales basadas en URL)
  • Un archivo local (credenciales basadas en archivos)

Para obtener tokens de ID de otras fuentes, es posible que tus clientes necesiten modificar su código o implementar herramientas o bibliotecas adicionales. Si expones los tokens de ID de manera compatible con las bibliotecas cliente, puedes evitar esa complejidad adicional y facilitar que los clientes adopten la federación de identidades para cargas de trabajo.

Usa las URLs de la entidad emisora específica de los usuarios

Las reclamaciones incorporadas en el token de ID de una carga de trabajo pueden ser únicas dentro de una instancia específica de tu producto o servicio, pero pueden no ser únicas en varias instancias de tu producto o servicio. Por ejemplo, dos de tus clientes pueden usar tu producto o servicio para implementar una carga de trabajo y asignarle de forma involuntaria el mismo nombre y el mismo ID.

La federación de identidades para cargas de trabajo intenta compensar esta posible falta de unicidad mediante la verificación de la URL del emisor (iss) de los tokens de ID y solo mediante la habilitación de tokens de una sola entidad emisora por grupo de identidades para cargas de trabajo.

Si tu producto o servicio es multiusuario, es posible que varios de tus clientes compartan una sola instancia de tu producto o servicio y los tokens de ID de sus cargas de trabajo puedan usar la misma URL de la entidad emisora. Si usas la misma URL de emisor en varios usuarios, puedes exponer a tus clientes a ataques de falsificación de identidad. Por ejemplo, una persona/entidad que actúa de mala fe puede crear una carga de trabajo en su propio usuario, asignarle el mismo ID o nombre que una carga de trabajo en el usuario de la víctima y usar el token de ID de su carga de trabajo para falsificar la identidad de la carga de trabajo de la víctima.

Para ayudar a proteger a tus clientes de los ataques de falsificación de identidad, evita usar las mismas URLs de la entidad emisora en varias instancias y, luego, incorpora un ID de usuario único en la URL de la entidad emisora, por ejemplo, https://saas.example.com/tenant-123/.

Permite que los usuarios especifiquen el público del token de ID

Es posible que algunas de las cargas de trabajo de tu cliente necesiten acceder a Google Cloud y a otros servicios de terceros. Cuando los clientes deciden federar tu producto o servicio con varias partes interesadas, se pueden encontrar en una situación en la que el token de ID de una carga de trabajo se usa de forma involuntaria o maliciosa para una parte confiable: por ejemplo, una persona/entidad que actúa de mala fe puede engañar a una carga de trabajo para que revele un token de ID destinado a un servicio de terceros y, luego, usar ese token de ID para la federación de identidades para cargas de trabajo.

Para evitar que tus clientes sean víctimas de estos ataques de engaño de aplicación delegada, evita usar un público estático (reclamación de aud) en los tokens de ID. En cambio, permite que las cargas de trabajo especifiquen un público cuando obtienen un token de ID y, de forma opcional, mantén una lista de anunciantes permitidos para los públicos que las cargas de trabajo pueden solicitar.

De forma predeterminada, la federación de identidades para cargas de trabajo espera que el público 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 público para los tokens de ID y que los públicos puedan tener hasta 180 caracteres.

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

Cuando los clientes deseen otorgar a una de sus cargas de trabajo acceso a los recursos de Google Cloud, deben crear una vinculación de IAM que haga referencia a la identidad de la carga de trabajo por tema, grupo o atributo personalizado. El asunto, el grupo y los atributos personalizados de la identidad de la carga de trabajo se derivan de las reclamaciones en el token de ID de la carga de trabajo.

Si un cliente crea una vinculación de IAM que hace referencia a una reclamación mutable, es posible que su carga de trabajo pierda acceso por accidente cuando el valor de la reclamación cambie. Por ejemplo, un cliente podría crear una vinculación de IAM que haga referencia al nombre de su carga de trabajo. Si luego cambian el nombre de la carga de trabajo, es posible que la vinculación de IAM ya no se aplique.

Peor aún, entidades que actúan de mala fe podrían intentar obtener acceso no autorizado a otros recursos mediante el cambio de nombre intencional de las cargas de trabajo o la modificación del entorno de una carga de trabajo para falsificar la identidad de otra carga de trabajo.

Para ayudar a los clientes a evitar estos problemas de falsificación de identidad, asegúrate de que los tokens de ID contengan identificadores inmutables y que no se puedan volver a usar.

Incluye información de contexto en los tokens de ID

En lugar de otorgar a las cargas de trabajo acceso incondicional a los recursos de Google Cloud, es posible que los clientes deseen restringir el acceso para que una carga de trabajo solo pueda obtener credenciales de Google cuando se cumplan ciertos criterios adicionales.

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

  • información sobre el usuario que posee o inició la carga de trabajo
  • el motivo y la forma en que se inició la carga de trabajo
  • la solicitud que la carga de trabajo maneja

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

Limita la vida útil del token de ID a 60 minutos

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

El uso de tokens de ID que sean válidos durante más de una hora no tiene efecto en la federación de identidades para cargas de trabajo, pero puede aumentar los riesgos si un token de ID se filtra de forma accidental. Usar una vida útil significativamente menor a 1 hora puede ayudar a reducir estos riesgos, pero puede conducir a intercambios de tokens frecuentes y rendimiento reducido.

¿Qué sigue?