Federación de identidades de personal

En este documento, se describen los conceptos clave de la federación de identidades de personal.

¿Qué es la federación de identidades de personal?

La federación de identidades de personal te permite usar un proveedor de identidad externo (IdP) para autenticar y autorizar a un personal (un grupo deusuarios, como empleados, socios y contratistas) que usa IAM para que los usuarios puedan acceder a los servicios de Google Cloud. Con la federación de identidades de personal, no necesitas sincronizar las identidades de los usuarios desde el IdP existente con las identidades de Google Cloud, como lo harías con Google Cloud Directory Sync (GCDS) de Cloud Identity. La federación de identidades de personal extiende las capacidades de identidad de Google Cloud para admitir el inicio de sesión único sin sincronización basado en atributos.

Después de la autenticación del usuario, la información que se recibe del IdP se usa para determinar el alcance del acceso a los recursos de Google Cloud.

Puedes usar la federación de identidades de personal con cualquier IdP que admita OpenID Connect (OIDC) o SAML 2.0, como Microsoft Entra ID, Active Directory Federation Services (AD FS), Okta y otros.

Grupos de identidad de trabajadores

Los grupos de Workforce Identity te permiten administrar grupos de identidades del personal y su acceso a los recursos de Google Cloud.

Los grupos te permiten hacer lo siguiente:

  • Agrupar las identidades de los usuarios, por ejemplo, employees o partners
  • Otorgar acceso de IAM a un grupo completo o a un subconjunto de él.
  • Federar las identidades de uno o más IdP.
  • Definir políticas en un grupo de usuarios que requieren permisos de acceso similares.
  • Detallar la información de configuración específica del IdP, incluida la asignación de atributos y las condiciones de atributos.
  • Habilitar Google Cloud CLI y el acceso a la API para las identidades de terceros.
  • Registrar el acceso de los usuarios dentro de un grupo en los Registros de auditoría de Cloud, junto con el ID del grupo.

Puedes crear varios grupos. Para ver un ejemplo en el que se describe uno de estos enfoques, consulta Ejemplo: Varios grupos de Workforce Identity.

Los grupos se configuran a nivel de la organización de Google Cloud. Debido a esto, los grupos están disponibles en todos los proyectos y carpetas dentro de la organización, siempre que tengas los permisos de IAM adecuados para ver el grupo. Cuando configuras por primera vez la federación de identidades de personal para tu organización, debes darle un nombre al grupo. En las políticas de permiso de IAM, debes hacer referencia al grupo por su nombre. Debido a esto, te recomendamos que le asignes un nombre al grupo que describa con claridad las identidades que contiene.

Proveedores de grupos de Workforce Identity

Un proveedor de grupos de Workforce Identity es una entidad que describe una relación entre tu organización de Google Cloud y tu IdP.

La federación de identidades de personal sigue la especificación de intercambio de tokens de OAuth 2.0 (RFC 8693). Proporciona una credencial desde tu proveedor de identidad externo al servicio de tokens de seguridad, que verifica la identidad en la credencial y, luego, muestra un token de acceso de corta duración de Google Cloud a cambio.

Tipos de flujo de OIDC

Para los proveedores de OIDC, la federación de identidades de personal admite el flujo de código de autorización y el flujo implícito. El flujo de código de autorización se considera el más seguro, ya que los tokens se muestran desde el IdP en una transacción de backend independiente y segura, directamente desde el IdP hasta Google Cloud, después de que los usuarios se autentican. Como resultado, las transacciones del flujo de código pueden recuperar tokens de cualquier tamaño, por lo que puedes tener más reclamos para usar en la asignación de atributos y la condición de los atributos. A comparación del flujo implícito, el token de ID se muestra del IdP al navegador. Los tokens están sujetos a límites de tamaño de URL de navegadores individuales.

Consola de la federación de identidades de personal de Google Cloud

Los usuarios de un grupo de Workload Identity pueden acceder a la consola de la federación de identidades de personal de Google Cloud, también conocida como la consola (federada). La consola proporciona a estos usuarios acceso a la IU para los productos de Google Cloud que admiten la federación de identidades de personal.

Asignaciones de atributos

Tu IdP proporciona atributos, a los que algunos IdP se refieren como reclamaciones. Los atributos contienen información sobre tus usuarios. Puedes asignar estos atributos para que los use Google Cloud mediante Common Expression Language (CEL).

En esta sección, se describe el conjunto de atributos obligatorios y opcionales que proporciona Google Cloud.

También puedes definir atributos personalizados en tu IdP que luego puedan usar productos específicos de Google Cloud, por ejemplo, las políticas de permisoS de IAM.

El tamaño máximo para la asignación de atributos es de 4 KB.

Los atributos son los siguientes:

  • google.subject (obligatorio): un identificador único para el usuario que se autentica. Es a menudo la aserción del asunto del JWT, porque los Registros de auditoría de Cloud registran el contenido de este campo como el principal. Puedes usar este campo a fin de configurar IAM para las decisiones de autorización. Te recomendamos que no uses un valor mutable, ya que si cambias el valor en el directorio de usuarios de tu IdP, el usuario perderá el acceso.

    La longitud máxima es 127 bytes.

  • google.groups (Opcional): la colección de grupos de la que es miembro el usuario que se autentica. Puedes configurar una expresión lógica mediante un subconjunto de CEL que produzca un arreglo de strings. También puedes usar este campo a fin de configurar IAM para las decisiones de autorización. Las limitaciones de google.groups son las siguientes:

    • Te recomendamos limitar el nombre del grupo a 100 caracteres.

    • Si un usuario está asociado con más de 100 grupos, define un conjunto de grupos más pequeño y solo incluye esos grupos en las aserciones que se usen para federar el usuario en Google Cloud. Si un usuario pertenece a más de 100 grupos, la autenticación falla.

    • Si usas este atributo para otorgar acceso en IAM, a cada miembro de los grupos asignados se le otorga acceso. Por lo tanto, recomendamos que te asegures de que solo los usuarios autorizados en tu organización puedan modificar la membresía de los grupos asignados.

  • google.display_name (Opcional): Es un atributo que se usa para configurar el nombre del usuario que accedió a la consola de Google Cloud. Este atributo no se puede usar en las políticas de permiso de IAM ni en la condición del atributo.

    La longitud máxima es 100 bytes.

  • google.profile_photo (opcional): Es una URL de la foto en miniatura del usuario. Recomendamos que la foto sea de 400 x 400 píxeles. Cuando se configura este atributo, la imagen es visible como la foto de perfil del usuario en la consola de Google Cloud. Si no se configura este valor o no se puede recuperar, se muestra un ícono de usuario genérico en su lugar. Este atributo no se puede usar en las políticas de permiso de IAM ni en la condición del atributo.

  • google.posix_username (opcional): Una cadena de nombre de usuario única que cumple con POSIX y se usa para lo siguiente:

    Este atributo no se puede usar en las políticas de permiso de IAM ni en la condición del atributo. La longitud máxima es de 32 caracteres.

  • attribute.KEY (Opcional): un atributo definido por el cliente que está presente en el token de IdP de un usuario. Puedes usar estos atributos personalizados para definir tu estrategia de autorización en una política de permisos de IAM. Por ejemplo, puedes definir un atributo, como el centro de costos del usuario: attribute.costcenter = "1234". Este atributo se puede usar en condiciones de IAM para otorgar acceso solo a los usuarios de ese centro de costos.

    Puedes configurar un máximo de 50 reglas de asignación de atributos personalizados. El tamaño máximo de cada regla es de 2,048 caracteres.

    Aunque no tenemos restricciones sobre los atributos que puedes asignar aquí, te recomendamos que elijas atributos cuyos valores sean estables. Por ejemplo, un atributo como attribute.job_description puede cambiar por muchos motivos (como mejorar su legibilidad). Como alternativa, considera usar attribute.role. Los cambios en esta última indican un cambio de responsabilidad asignada y se alinean con los cambios en el acceso otorgado al usuario.

Puedes transformar los valores de los atributos con las funciones estándar de CEL. También puedes usar las siguientes funciones personalizadas:

  • La función split divide una string en el valor del separador proporcionado. Por ejemplo, para extraer el atributo username de un atributo de dirección de correo electrónico mediante la división de su valor en @ y el uso de la primera string, usa la siguiente asignación de atributos: 

    attribute.username=assertion.email.split("@")[0]

  • La función join une una lista de strings en el valor del separador proporcionado. Por ejemplo, para propagar el atributo personalizado department mediante la concatenación de una lista de strings con . como separador, usa la siguiente asignación de atributos: 

    attribute.department=assertion.department.join(".")

Condiciones de atributos

Las condiciones de los atributos son expresiones CEL opcionales que te permiten establecer restricciones en los atributos de identidad que acepta Google Cloud.

Los beneficios de usar condiciones de atributos incluyen los siguientes:

  • Puedes usar condiciones de atributos para permitir que solo un subconjunto de identidades externas se autentique en el proyecto de Google Cloud. Por ejemplo, es posible que desees permitir que solo accedan las identidades que están en un equipo específico, en especial si usas un IdP público. Para otro ejemplo, es posible que desees permitir que el equipo de contabilidad acceda, pero no el equipo de ingeniería.
  • Las condiciones de los atributos te permiten evitar que las credenciales destinadas a usarse con otra plataforma se usen con Google Cloud, y viceversa. Esto ayuda a evitar el problema de engaño de aplicación delegada.

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

La federación de identidades de personal no mantiene un directorio de cuentas de usuario, sino que implementa identidades basadas en reclamos. Como resultado, cuando el mismo proveedor de identidad (IdP) emite dos tokens y sus reclamos se asignan al mismo valor de 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.

Las IdP multiusuario, 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. Si tu IdP multiusuario tiene una sola URL de emisor, te recomendamos que uses condiciones de atributo para garantizar que el acceso se restrinja al usuario correcto.

Representa a los usuarios del grupo de personal en las políticas de IAM

En la tabla siguiente, se muestran los identificadores principales que usas para otorgar roles a un solo usuario, a un grupo de usuarios, a los usuarios que realizan una reclamación particular o a todos los usuarios de un grupo de personal.

Identidades Formato del identificador
Identidad única en un grupo de identidad de personal principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/subject/SUBJECT_ATTRIBUTE_VALUE
Todas las identidades del personal de un grupo principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/group/GROUP_ID
Todas las identidades del personal con un valor de atributo específico principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE
Todas las identidades en un grupo de identidad de personal principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/*

Claves web JSON

El proveedor del grupo de Workforce Identity puede acceder a las claves web JSON (JWK) que proporciona tu IdP en el campo jwks_uri del documento /.well-known/openid-configuration. Si tu proveedor de OIDC no proporciona esta información o si no se puede acceder públicamente a tu emisor, puedes subir los JWK de forma manual cuando crees o actualices el proveedor de OIDC.

Restringir el acceso entre organizaciones

Las principales del grupo de identidades de trabajo no pueden acceder directamente a los recursos fuera de la organización a la que pertenecen. Sin embargo, si se otorga permiso a una cuenta principal para actuar en nombre de una cuenta de servicio dentro de la organización, esta restricción se puede omitir, puesto que las cuentas de servicio no están restringidas por igual.

Proyecto de usuario de grupos de personal

La mayoría de las APIs de Google Cloud cobran la facturación y el uso de cuotas al proyecto que contiene el recurso al que accede tu solicitud a las APIs. Estas APIs se denominan APIs basadas en recursos. Algunas APIs de Google Cloud se cobran al proyecto asociado con el cliente. Estas se denominan APIs basadas en el cliente. El proyecto que se usa para fines de facturación y cuota se denomina proyecto de cuota.

Cuando creas un archivo de configuración de federación de identidades de personal, especificas un proyecto de usuario de grupos de personal. Este proyecto se usa para identificar tu aplicación en las APIs de Google a las que llama. El proyecto de usuario de grupos de personal también se usa como el proyecto de cuota predeterminado para las API basadas en el cliente, a menos que uses la gcloud CLI a fin de iniciar la solicitud a las APIs. Debes tener el permiso serviceusage.services.use, que se incluye en el rol Consumidor de Service Usage (roles/serviceusage.serviceUsageConsumer) para el proyecto que especifiques.

Para obtener más información sobre el proyecto de cuota, las APIs basadas en recursos y las APIs basadas en el cliente, consulta Descripción general de las cuotas de proyectos.

Ejemplo: Varios grupos de Workforce Identity

Esta sección contiene un ejemplo que ilustra el uso típico de varios grupos.

Puedes crear un grupo para empleados y otro para socios. Las organizaciones multinacionales pueden crear grupos separados para diferentes divisiones en su organización. Los grupos permiten la administración distribuida, en la que diferentes grupos pueden administrar de forma independiente su grupo específico en el que los roles se otorgan solo a las identidades en el grupo.

Por ejemplo, supongamos que una empresa llamada Enterprise Example Organization contrata a otra empresa llamada Partner Example Organization Inc para proporcionar servicios de DevOps de Google Kubernetes Engine (GKE). Para que el personal de Partner Example Organization pueda proporcionar los servicios, debe poder acceder a Google Kubernetes Engine (GKE) y a otros recursos de Google Cloud en la organización de la organización Enterprise Example Organization. Enterprise Example Organization ya tiene un grupo de Workforce Identity llamado enterprise-example-organization-employees.

Para permitir que Partner Example Organization administre el acceso a los recursos de Enterprise Example Organization, esta última crea un grupo de personal separado para los usuarios del personal de Partner Example Organization a fin de que esta pueda administrar. Enterprise Example Organization proporciona el grupo de personal a un administrador de Partner Example Organization. El administrador de Partner Example Organization usa su propio IdP para otorgar acceso a su personal.

Para ello, el administrador de Enterprise Example Organization realiza las siguientes tareas:

  1. Crea una identidad, como partner-organization-admin@example.com, para el administrador de Partner Example Organization en el IdP de Enterprise Example Organization, que ya está configurado en el grupo llamado enterprise-example-organization-employees.

  2. Crea un nuevo grupo de personal llamado example-organization-partner.

  3. Crea la siguiente política de IAM para el grupo example-organization-partner:

    {
  "bindings": [
    {
      "role": "roles/iam.workforcePoolEditor",
      "members": [
        "principalSet://iam.googleapis.com/locations/global/workforcePools/enterprise-example-organization-employees/subject/partner-organization-admin@example.com"
      ]
    }
  ]
}

  4. Otorga roles para el grupo example-organization-partner en los recursos a los que necesitan acceso en la organización de Enterprise Example Organization.

El administrador de Partner Example Organization ahora puede configurar el grupo example-organization-partner para que se conecte con su IdP. Luego, pueden permitir que el personal de Partner Example Organization acceda con las credenciales de IdP de Partner Example Organization. Después de acceder, los usuarios del personal de Partner Example Organization pueden acceder a los recursos de Google Cloud, limitados por las políticas que define Enterprise Example Organization.

Administración de accesos más sencilla

En grandes empresas, los administradores de TI suelen crear grupos de seguridad como parte de un modelo de control de accesos de prácticas recomendadas. Los grupos de seguridad rigen el acceso a los recursos internos. Además, las empresas suelen crear grupos adicionales para empleados y otros grupos para que los socios extiendan este modelo de control de accesos a los recursos de la nube. Esto puede provocar la proliferación de grupos anidados de forma profunda que pueden ser muy difíciles de administrar.

Tu organización también podría tener políticas que limiten la cantidad de grupos que puedes crear para mantener la jerarquía de directorios de usuarios razonablemente plana. Una mejor solución para evitar una configuración incorrecta de las políticas de IAM y limitar el crecimiento de grupos es usar varios grupos a fin de crear una separación más amplia de usuarios de diferentes unidades organizativas y empresariales, y organizaciones asociadas. Luego, puedes hacer referencia a estos grupos y a grupos contenidos en ellos para definir las políticas de IAM (consulta los ejemplos en el paso de configuración de IAM).

Limitaciones de los Controles del servicio de VPC

Las API de federación de identidades de personal las API de configuración de grupos de personal y las API de servicios de tokens de seguridad no son compatibles con los Controles del servicio de VPC. Sin embargo, los productos de Google Cloud a los que los usuarios del grupo de personal pueden acceder son compatibles con los Controles del servicio de VPC. Para obtener más información, consulta la página Productos admitidos y limitaciones de los Controles del servicio de VPC.

federación de identidades de personal y Essential Contacts

Para recibir información importante sobre los cambios en tu organización o productos de Google Cloud, debes proporcionar Essential Contacts cuando uses la federación de identidades de personal. Se puede contactar a los usuarios de Cloud Identity a través de su dirección de correo electrónico de Cloud Identity, pero a los usuarios de la ffederación de identidades de personal y se los contacta por medio de Essential Contacts.

Cuando uses la consola de Google Cloud para crear o administrar grupos de Workforce Identity, verás un banner que te solicita configurar un Essential Contact con el siguiente comando: Asuntos legales y Suspensión. Como alternativa, puedes definir un contacto en la categoría Todos si no tienes contactos separados. Si proporcionas los contactos, se quitará el banner.

¿Qué sigue?