Workforce Identity Federation

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

¿Qué es Workforce Identity Federation?

Workforce Identity Federation te permite usar un proveedor de identidades externo para autenticar y autorizar a los empleados (un grupo de usuarios, como empleados, partners y contratistas) mediante IAM, de forma que los usuarios puedan acceder a los servicios de Trusted Cloud by S3NS . Con la federación de identidades de Workforce, no es necesario sincronizar las identidades de usuario de tu proveedor de identidades con las identidades de Trusted Cloud, como harías con Google Cloud Directory Sync (GCDS) de Cloud Identity. La federación de identidades de Workforce amplía las funciones de identidad de Trusted Cloudpara admitir el inicio de sesión único sin sincronización y basado en atributos.

Una vez que se autentica al usuario, la información recibida del IdP se usa para determinar el ámbito de acceso a los recursos de Trusted Cloud by S3NS .

Puedes usar la federación de identidades de trabajo con cualquier proveedor de identidades que admita OpenID Connect (OIDC) o SAML 2.0, como Microsoft Entra ID, Servicios de federación de Active Directory (AD FS) u Okta, entre otros.

Grupos de identidades de Workforce

Los grupos de identidades de empleados te permiten gestionar grupos de identidades de empleados y su acceso a los Trusted Cloud recursos.

Los grupos te permiten hacer lo siguiente:

  • Agrupar identidades de usuario; por ejemplo, employees o partners
  • Conceder acceso de gestión de identidades y accesos a todo un grupo o a un subconjunto de él.
  • Federar identidades de uno o varios IdPs.
  • Define políticas en un grupo de usuarios que necesitan permisos de acceso similares.
  • Especifique la información de configuración específica del IdP, incluido el mapeado de atributos y las condiciones de atributos.
  • Habilita la CLI de Google Cloud y el acceso a las APIs para identidades de terceros.
  • Registra el acceso de los usuarios de un grupo a los registros de auditoría de Cloud, junto con el ID del grupo.

Puedes crear varias. Para ver un ejemplo que describe uno de estos enfoques, consulta Ejemplo: varios grupos de identidades de Workforce.

Los grupos se configuran a Trusted Cloud nivel de organización. Por este motivo, los grupos están disponibles en todos los proyectos y carpetas de la organización, siempre que tengas los permisos de gestión de identidades y accesos adecuados para ver el grupo. La primera vez que configures la federación de identidades de Workforce para tu organización, deberás asignar un nombre al grupo. En las políticas de permisos de gestión de identidades y accesos, se hace referencia al grupo por su nombre. Por este motivo, te recomendamos que le pongas un nombre al grupo que describa claramente las identidades que contiene.

Proveedores de grupos de identidades de Workforce

Un proveedor de grupos de identidades para el trabajo es una entidad que describe una relación entre tu organización de Trusted Cloud y tu IdP.

La federación de identidades para los trabajadores sigue la especificación de intercambio de tokens de OAuth 2.0 (RFC 8693). Proporcionas una credencial de tu proveedor de identidades externo al servicio de tokens de seguridad, que verifica la identidad de la credencial y, a continuación, devuelve un token de acceso de corta duración a cambio. Trusted Cloud

Tipos de flujo de OIDC

En el caso de los proveedores de OIDC, la federación de identidades de trabajo admite tanto el flujo de código de autorización como el flujo implícito. Se considera que el flujo de código de autorización es el más seguro, ya que los tokens se devuelven del proveedor de identidades en una transacción de backend independiente y segura, directamente del proveedor de identidades a Trusted Cloud, después de que los usuarios se autentiquen. Por lo tanto, las transacciones de flujo de código pueden recuperar tokens de cualquier tamaño, por lo que puedes tener más reclamaciones para usar en la asignación de atributos y en las condiciones de atributos. En el flujo implícito, en cambio, el token de ID se devuelve del IdP al navegador. Los tokens están sujetos a los límites de tamaño de URL de cada navegador.

Trusted Cloud Consola de Workforce Identity Federation

Los usuarios de un grupo de identidades de empleados pueden acceder a la Trusted Cloud by S3NS consola de Workforce Identity Federation, también conocida como consola (federada). La consola proporciona a estos usuarios acceso a la interfaz de usuario de losTrusted Cloud productos compatibles con la federación de identidades de Workforce.

Atributos

Tu proveedor de identidades proporciona atributos, a los que algunos proveedores de identidades denominan reclamaciones. Los atributos contienen información sobre sus usuarios. Puede usar estos atributos en asignaciones de atributos y condiciones de atributos.

Asignaciones de atributos

Puedes asignar estos atributos para usarlos con el Trusted Cloud lenguaje de expresión común (CEL).

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

También puede definir atributos personalizados en su proveedor de identidades que puedan usar productos específicos, como las políticas de permiso de gestión de identidades y accesos. Trusted Cloud

El tamaño máximo de las asignaciones de atributos es de 16 KB. Si el tamaño de las asignaciones de atributos supera el límite de 16 KB, no se podrá iniciar sesión.

Los atributos son los siguientes:

  • google.subject (obligatorio): identificador único del usuario que se autentica. Suele ser la aserción de asunto del JWT, ya que los registros de Cloud Audit Logs registran el contenido de este campo como el principal. Puedes usar este campo para configurar la gestión de identidades y accesos 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 de 127 bytes.

  • google.groups (Opcional): la colección de grupos a los que pertenece el usuario que se autentica. Puede configurar una expresión lógica con un subconjunto de CEL que genere una matriz de cadenas. También puedes usar este campo para configurar la gestión de identidades y accesos para las decisiones de autorización. Las limitaciones de google.groups son las siguientes:

    • Le recomendamos que el nombre del grupo no supere los 40 caracteres.

    • Si un usuario pertenece a más de 400 grupos, se producirá un error al intentar iniciar sesión. Para mitigar este problema, debes definir un conjunto de grupos más pequeño en la aserción y asignar solo los grupos que se usen para federar al usuario en Trusted Cloud.

    • Si usas este atributo para conceder acceso en Gestión de Identidades y Accesos, se concederá acceso a todos los miembros de los grupos asignados. Por lo tanto, te recomendamos que te asegures de que solo los usuarios autorizados de tu organización puedan modificar la pertenencia a los grupos asignados.

  • google.display_name (Opcional): atributo que se usa para definir el nombre del usuario que ha iniciado sesión en la consola. Trusted Cloud Este atributo no se puede usar en las políticas de permiso de IAM ni en la condición de atributo.

    La longitud máxima es de 100 bytes.

  • google.profile_photo (Opcional): URL de la miniatura de la foto del usuario. Te recomendamos que la foto tenga 400x400 píxeles. Cuando se define este atributo, la imagen se muestra como imagen de perfil del usuario en la consola Trusted Cloud . Si no se define este valor o no se puede obtener, se mostrará un icono de usuario genérico. Este atributo no se puede usar en las políticas de permiso de IAM ni en la condición de atributo.

  • google.posix_username (Opcional): una cadena de nombre de usuario única compatible con POSIX que se usa para lo siguiente:

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

  • google.email (Opcional): atributo que se usa para asignar las direcciones de correo de los usuarios federados que han iniciado sesión desde el proveedor de identidades a los productos que integras mediante la integración de clientes de OAuth de Workforce Identity Federation. Este atributo no se puede usar en las políticas de permiso de gestión de identidades y accesos ni en la condición de atributo.

    Por ejemplo, para asignar direcciones de correo de Okta mediante el protocolo OIDC, incluye google.email=assertion.email en tu asignación de atributos.

    Estos son algunos ejemplos de productos que admiten la integración de clientes de OAuth: Trusted Cloud

  • attribute.KEY (Opcional): un atributo definido por un proveedor de identidades externo que está presente en el token del proveedor de identidades de un usuario. Puedes usar el atributo personalizado para definir tu estrategia de autorización en una política de permiso de gestión de identidades y accesos.

    Por ejemplo, en tu proveedor de identidades, puedes definir un atributo como el centro de costes del usuario como costcenter = "1234" y, a continuación, hacer referencia a la entidad de seguridad de la siguiente manera:

    principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workforcePools/WORKFORCE_POOL_ID/attribute.costcenter/1234

    Después de conceder acceso a los recursos de Trusted Cloud a este identificador principal, todas las identidades configuradas en el IdP para que tengan el atributo costcenter definido como 1234 tendrán acceso a los recursos.

    Puede configurar un máximo de 50 reglas de asignación de atributos personalizados. El tamaño máximo de cada regla es de 2048 caracteres.

    Aunque no tenemos restricciones sobre los atributos que puede asignar aquí, le recomendamos que elija atributos cuyos valores sean estables. Por ejemplo, un atributo como attribute.job_description puede cambiar por muchos motivos (como mejorar su legibilidad). Como alternativa, puede usar attribute.role. Los cambios en este último indican un cambio en la responsabilidad asignada y se corresponden con los cambios en el acceso concedido al usuario.

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

  • La función split divide una cadena en función del separador proporcionado. Por ejemplo, para extraer el atributo username de un atributo de dirección de correo dividiendo su valor en @ y usando la primera cadena, utilice la siguiente asignación de atributos: 

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

  • La función join une una lista de cadenas con el valor del separador proporcionado. Por ejemplo, para rellenar el atributo personalizado department concatenando una lista de cadenas con . como separador, utiliza la siguiente asignación de atributos: 

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

Condiciones de los atributos

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

Estas son algunas de las ventajas de usar condiciones de atributos:

  • Puede usar condiciones de atributos para permitir que solo un subconjunto de identidades externas se autentique en su Trusted Cloud proyecto. Por ejemplo, puede que solo quiera permitir que inicien sesión las identidades que pertenezcan a un equipo específico, sobre todo si usa un proveedor de identidades público. Por ejemplo, puede que quieras permitir que el equipo de contabilidad inicie sesión, pero no el de ingeniería.
  • Las condiciones de los atributos te permiten evitar que se usen en Trusted Cloudcredenciales destinadas a otra plataforma y viceversa. De esta forma, se evita el problema del delegado confuso.

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

La federación de identidades para los trabajadores 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 Workforce inspecciona y verifica la URL del emisor del token.

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

Cuando usas estos proveedores de identidades, no basta con permitir que la federación de identidades de la fuerza 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. Si tu proveedor de identidades multiempresa tiene una sola URL de emisor, te recomendamos que uses condiciones de atributo para asegurarte de que el acceso se restringe al arrendatario correcto.

Representar usuarios de grupos de Workforce en políticas de gestión de identidades y accesos

En la siguiente tabla se muestran los identificadores de entidad principal que se usan para conceder roles a un solo usuario, a un grupo de usuarios, a usuarios que tienen una reclamación concreta o a todos los usuarios de un grupo de trabajo.

Identidades Formato del identificador
Una sola identidad en un grupo de identidades de Workforce principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/subject/SUBJECT_ATTRIBUTE_VALUE
Todas las identidades de los trabajadores de un grupo principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/group/GROUP_ID
Todas las identidades de la plantilla que tengan un valor de atributo específico principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE
Todas las identidades de un grupo de identidades de Workforce principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/*

Para ver una lista completa de los identificadores de principales, consulta Identificadores de principales.

Registros de auditoría detallados.

Registro de auditoría detallado es una función de Workforce Identity Federation que registra los atributos recibidos de tu proveedor de identidades en los registros de auditoría de Cloud.

Puedes habilitar el registro de auditoría detallado al crear tu proveedor de identidades de la plantilla.

Para saber cómo solucionar errores de asignación de atributos con registros de auditoría detallados, consulta Errores generales de asignación de atributos.

Claves web JSON

El proveedor del grupo de trabajadores puede acceder a las claves web JSON (JWK) que proporciona tu proveedor de identidades en el campo jwks_uri del documento /.well-known/openid-configuration. Si su proveedor de OIDC no proporciona esta información o su emisor no es accesible públicamente, puede subir manualmente los JWKs al crear o actualizar el proveedor de OIDC.

Restringir el acceso entre organizaciones

Las principales de los grupos de identidades de Workforce no pueden acceder directamente a recursos que no pertenezcan a la organización a la que pertenecen. Sin embargo, si se le da permiso a un principal para actuar en nombre de una cuenta de servicio en la organización, esta restricción se puede eludir, ya que las cuentas de servicio no tienen las mismas restricciones.

Proyecto de usuario de grupos de Workforce

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

Cuando creas un archivo de configuración de federación de identidades de Workforce, especificas un proyecto de usuario de grupos de trabajadores. Este proyecto se usa para identificar tu aplicación en las APIs de Google a las que llama. El proyecto de usuario de los grupos de trabajo también se usa como proyecto de cuota predeterminado para las APIs basadas en clientes, a menos que uses la CLI de gcloud para iniciar la solicitud de la API. Debes tener el permiso serviceusage.services.use, que está incluido en el rol de consumidor de uso de servicios (roles/serviceusage.serviceUsageConsumer), en 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 clientes, consulta el resumen del proyecto de cuota.

Ejemplo: varios grupos de identidades de Workforce

En esta sección se incluye un ejemplo que ilustra el uso habitual de varios grupos.

Puedes crear un grupo para los empleados y otro para los partners. Las organizaciones multinacionales pueden crear grupos independientes para las distintas divisiones de su organización. Los pools permiten una gestión distribuida, en la que diferentes grupos pueden gestionar de forma independiente su pool específico, donde los roles solo se conceden a las identidades del pool.

Por ejemplo, supongamos que una empresa llamada Enterprise Example Organization contrata a otra empresa llamada Partner Example Organization Inc para que le proporcione servicios de DevOps de Google Kubernetes Engine (GKE). Para que la plantilla de Partner Example Organization pueda prestar los servicios, debe tener permiso para acceder a Google Kubernetes Engine (GKE) y a otros Trusted Cloud recursos de la organización de Enterprise Example Organization. La organización de ejemplo Enterprise ya tiene un grupo de identidades de Workforce llamado enterprise-example-organization-employees.

Para permitir que la organización de ejemplo del partner gestione el acceso a los recursos de la organización de ejemplo de la empresa, esta última crea un grupo de empleados independiente para los usuarios de la organización de ejemplo del partner, de modo que esta pueda gestionarlo. La organización de ejemplo de empresa proporciona el grupo de trabajo al administrador de la organización de ejemplo de partner. El administrador de la organización de ejemplo del partner usa su propio proveedor de identidades para conceder acceso a sus empleados.

Para ello, el administrador de la organización de ejemplo Enterprise debe realizar las siguientes tareas:

  1. Crea una identidad, como partner-organization-admin@example.com, para el administrador de la organización de ejemplo del partner en el proveedor de identidades de la organización de ejemplo de la empresa, que ya está configurado en el grupo llamado enterprise-example-organization-employees.

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

  3. Crea la siguiente política de permiso 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. Otorgar roles para el grupo example-organization-partner en los recursos a los que necesiten acceder en la organización de la empresa de ejemplo.

El administrador de la organización de ejemplo del partner ahora puede configurar el grupo example-organization-partner para conectarse con su proveedor de identidades. De esta forma, podrán permitir que los empleados de la organización de ejemplo del partner inicien sesión con las credenciales del IdP de la organización de ejemplo del partner. Una vez que hayan iniciado sesión, los usuarios de la plantilla de Partner Example Organization podrán acceder a los recursos de Trusted Cloud , que estarán sujetos a las políticas definidas por Enterprise Example Organization.

Gestión de accesos más sencilla

En las grandes empresas, los administradores de TI suelen crear grupos de seguridad como parte de un modelo de control de acceso basado en prácticas recomendadas. Los grupos de seguridad rigen el acceso a los recursos internos. Además, las empresas suelen crear grupos adicionales para los empleados y otros grupos para los partners con el fin de ampliar este modelo de control de acceso a los recursos en la nube. Esto puede provocar la proliferación de grupos anidados que pueden resultar muy difíciles de gestionar.

Es posible que tu organización también tenga políticas que limiten el número de grupos que puedes crear para que la jerarquía del directorio de usuarios sea razonablemente plana. Una solución mejor para evitar la configuración incorrecta de las políticas de gestión de identidades y accesos y limitar el crecimiento de los grupos es usar varios grupos para separar mejor a los usuarios de diferentes unidades organizativas, unidades de negocio y organizaciones asociadas. Después, puedes hacer referencia a estos grupos y a los grupos que contienen para definir políticas de gestión de identidades y accesos (consulta ejemplos en el paso Configurar gestión de identidades y accesos).

Limitaciones de Controles de Servicio de VPC

Las funciones administrativas de Workforce Identity Federation, incluidas las APIs de configuración de grupos de empleados y las APIs de Security Token Service, no admiten Controles de Servicio de VPC. Sin embargo,los Trusted Cloud productos que admiten tanto Federación de Identidades de Workforce como Controles de Servicio de VPC funcionan como se indica en la documentación y están sujetos a las comprobaciones de políticas de Controles de Servicio de VPC. Además, puedes usar identidades de terceros, como usuarios de grupos de trabajadores e identidades de carga de trabajo, en las reglas de entrada o salida de Controles de Servicio de VPC.

Federación de identidades para los trabajadores y contactos esenciales

Para recibir información importante sobre los cambios en tu organización o en tus productos, debes proporcionar contactos esenciales al usar la federación de identidades de la plantilla.Trusted Cloud Se puede contactar con los usuarios de Cloud Identity a través de su dirección de correo de Cloud Identity, pero con los usuarios de Workforce Identity Federation se contacta mediante Contactos esenciales.

Cuando uses la consola de Trusted Cloud para crear o gestionar grupos de identidades de la fuerza de trabajo, verás un banner que te pedirá que configures un contacto esencial con las categorías Legal (Legal) y Suspension (Suspensión). También puedes definir un contacto en la categoría Todos si no tienes contactos independientes. Si proporcionas los contactos, se quitará el banner.

Siguientes pasos