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. Estos son algunos ejemplos de esos productos y servicios:

  • Productos de estadísticas de datos: Es posible que tus clientes deseen usar estos productos para analizar sus datos en BigQuery.
  • Productos y servicios de CI/CD: Es posible que tus clientes usen estos servicios para implementar infraestructura y aplicaciones en sus proyectos de Google Cloud.
  • Automatización robótica de procesos (RPA): Es posible que tus clientes usen la RPA para flujos de trabajo, como crear proyectos, administrar el acceso o automatizar tareas administrativas en Google Cloud.

Para autenticar productos locales o de software como servicio (SaaS) en Google Cloud, los clientes tradicionalmente se han basado en claves de cuenta de servicio, pero estas claves pueden ser difíciles de 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 documento, 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 este documento, 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 que declara 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 durante su ciclo de vida, una carga de trabajo debe tener acceso a un token de ID que confirme su identidad 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 supere a su carga de trabajo o de 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 del usuario también debe ser inmutable.

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

  4. Se puede acceder a los metadatos del proveedor de OpenID de forma pública y se pueden descubrir desde los 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 emisores de OpenID. Por ejemplo, si los tokens de ID contienen una declaració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 de acceso público a través de Internet desde cualquier dirección IP.

  5. Se puede acceder a las claves de firma de forma pública 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 prácticas recomendadas.

Recomendaciones:

Distingue entre los tokens de identidad y los de acceso
Expón los tokens de ID de una 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 tokens de ID.
Incluye información contextual 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.

Expone los tokens de ID de manera compatible con las bibliotecas cliente

Las bibliotecas cliente de Google Cloud pueden obtener tokens de ID automáticamente 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 deban 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

Es posible que los reclamos incorporados en el token de ID de una carga de trabajo sean únicos dentro de una instancia específica de tu producto o servicio, pero es posible que no lo sean en varias instancias de tu producto o servicio. Por ejemplo, dos de tus clientes podrían usar tu producto o servicio para implementar una carga de trabajo y asignarle, de forma inadvertida, el mismo nombre y 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 admite multitenancy, 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 podrían 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, así como 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 representante confundido, evita usar un público estático (derecho aud) en los tokens de ID. En su lugar, permite que las cargas de trabajo especifiquen un público cuando obtengan un token de ID y, de manera opcional, mantengan una lista de entidades permitidas 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 la longitud de la URL del público sea inferior a 180 caracteres.

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

Cuando los clientes desean 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 sujeto, 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 del token de ID de la carga de trabajo.

Si un cliente crea una vinculación de IAM que hace referencia a un reclamo mutable, su carga de trabajo podría perder acceso de forma accidental cuando cambie el valor del reclamo. Por ejemplo, un cliente podría crear una vinculación de IAM que haga referencia al nombre de su carga de trabajo. Si cambia el nombre de la carga de trabajo posteriormente, 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 que no se puedan volver a usar.

Cómo incluir información contextual en los tokens de ID

En lugar de otorgar a las cargas de trabajo acceso incondicional a los recursos de Google Cloud, los clientes pueden 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 reclamos 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 que es propietario de la carga de trabajo o la inició
  • el motivo y la forma en que se inició la carga de trabajo
  • la solicitud que la carga de trabajo está controlando actualmente

Los clientes pueden usar estos reclamos para configurar condiciones de atributos o en identificadores principales.

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

Los tokens de ID tienen una vida útil limitada determinada por el reclamo 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?