Es posible que parte o toda la información de esta página no se aplique a Trusted Cloud by S3NS. Para obtener más información, consulta las diferencias con Google Cloud.

Esta página se ha traducido con Cloud Translation API.

Federación de identidades de cargas de trabajo

En este documento se ofrece una descripción general de la federación de identidades de carga de trabajo. Con la federación de identidades de cargas de trabajo, puedes proporcionar a las cargas de trabajo on-premise o multinube acceso a los Trusted Cloud by S3NS recursos mediante identidades federadas en lugar de una clave de cuenta de servicio.

Puedes usar Workload Identity Federation con cargas de trabajo que se ejecuten en Amazon Web Services (AWS) y Azure, en Active Directory local, en servicios de implementación (como GitHub y GitLab) y con cualquier proveedor de identidades que admita OpenID Connect (OIDC) o Security Assertion Markup Language (SAML) V2.0.

¿Por qué usar la federación de identidades de cargas de trabajo?

Tradicionalmente, las aplicaciones que se ejecutan fuera de Trusted Cloud pueden usar claves de cuenta de servicio para acceder a los recursos de Trusted Cloud . Sin embargo, las claves de cuentas de servicio son credenciales potentes y pueden suponer un riesgo para la seguridad si no se gestionan correctamente. La federación de identidades de cargas de trabajo elimina la carga de mantenimiento y seguridad asociada a las claves de cuentas de servicio.

Con la federación de identidades de cargas de trabajo, puedes usar Gestión de Identidades y Accesos (IAM) para asignar roles de IAM a principales basados en identidades federadas de un grupo de identidades de cargas de trabajo. Puedes conceder acceso a las entidades de seguridad en recursos Trusted Cloud específicos. Este enfoque se denomina acceso directo. También puedes conceder acceso a una cuenta de servicio, que podrá acceder a los recursos de Trusted Cloud . Este método se denomina suplantación de identidad de cuenta de servicio.

Grupos de identidades de carga de trabajo

Un grupo de identidades de carga de trabajo es una entidad que te permite gestionar identidades externas.

En general, te recomendamos que crees un nuevo grupo por cada entorno que no sea deTrusted Cloud producción y que necesite acceder a recursos Trusted Cloud , como los entornos de desarrollo o de preproducción.

Proveedores de grupos de identidades de carga de trabajo

Un proveedor de grupos de identidades de carga de trabajo es una entidad que describe una relación entre Trusted Cloud y tu proveedor de identidades, que incluye lo siguiente:

AWS
ID de Microsoft Entra
GitHub
GitLab
Clústeres de Kubernetes
Okta
Servicios de federación de Active Directory (AD FS) on-premise
Terraform

La federación de identidades de cargas de trabajo sigue la especificación de intercambio de tokens de OAuth 2.0. Proporcionas una credencial de tu proveedor de identidades al servicio de tokens de seguridad, que verifica la identidad de la credencial y, a continuación, devuelve un token federado a cambio.

Proveedor de OIDC con JWKs locales

Para federar cargas de trabajo que no tengan un endpoint de OIDC público, puedes subir conjuntos de claves web JSON (JWKS) de OIDC directamente al grupo. Esto es habitual si tienes Terraform o GitHub Enterprise alojados en tu propio entorno o si tienes requisitos normativos que te impiden exponer URLs públicas. Para obtener más información, consulta Gestionar JWKs de OIDC (opcional).

Asignaciones de atributos

Los tokens emitidos por tu proveedor de identidades externo contienen uno o varios atributos. Algunos proveedores de identidades se refieren a estos atributos como reclamaciones.

Los tokens del servicio de tokens de seguridad de Google también contienen uno o varios atributos, tal como se indica en la siguiente tabla:

Atributo	Descripción
`google.subject`	Obligatorio. Identificador único del usuario. Este atributo se usa en las enlaces de roles de gestión de identidades y accesos `principal://` y aparece en los registros de Cloud Logging. El valor debe ser único y no puede superar los 127 caracteres.
`google.groups`	Opcional. Conjunto de grupos a los que pertenece la identidad. Este atributo se usa en las enlaces de roles de gestión de identidades y accesos `principalSet://` para conceder acceso a todos los miembros de un grupo.
`attribute.NAME`	Opcional. Puedes definir hasta 50 atributos personalizados y usarlos en enlaces de roles de `principalSet://` de gestión de identidades y accesos para conceder acceso a todas las identidades con un atributo determinado.

Una asignación de atributos define cómo derivar el valor del atributo de token del servicio de tokens de seguridad de Google a partir de un token externo. Para cada atributo de token del servicio de tokens de seguridad de Google, puedes definir una asignación de atributos con el siguiente formato:

TARGET_ATTRIBUTE=SOURCE_EXPRESSION

Haz los cambios siguientes:

TARGET_ATTRIBUTE es un atributo del token del servicio de tokens de seguridad de Google.
SOURCE_EXPRESSION es una expresión del lenguaje de expresión común (CEL) que transforma uno o varios atributos de los tokens emitidos por tu proveedor de identidades externo.

En la siguiente lista se muestran ejemplos de asignación de atributos:

Asigna el atributo de aserción sub a google.subject:
```
google.subject=assertion.sub
```

Concatenar varios atributos de aserción:

google.subject="myprovider::" + assertion.aud + "::" + assertion.sub

Asigna un atributo de aserción con valor GUID workload_id a un nombre y asigna el resultado a un atributo personalizado llamado attribute.my_display_name:

attribute.my_display_name={
  "8bb39bdb-1cc5-4447-b7db-a19e920eb111": "Workload1",
  "55d36609-9bcf-48e0-a366-a3cf19027d2a": "Workload2"
}[assertion.workload_id]

Usa operadores y funciones lógicos de CEL para asignar el valor prod o test al atributo personalizado attribute.environment, en función del nombre de recurso de Amazon (ARN) de la identidad:
```
attribute.environment=assertion.arn.contains(":instance-profile/Production") ? "prod" : "test"
```

Usa la función extract para rellenar un atributo personalizado aws_role con el nombre del rol asumido o, si no se ha asumido ningún rol, con el ARN de la identidad.

attribute.aws_role=assertion.arn.contains('assumed-role') ? assertion.arn.extract('{account_arn}assumed-role/') + 'assumed-role/' + assertion.arn.extract('assumed-role/{role_name}/') : assertion.arn

La función split divide una cadena en función del valor 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(".")
```

En el caso de AWS, Google proporciona asignaciones predeterminadas que abarcan los casos más habituales. También puedes proporcionar asignaciones personalizadas.

En el caso de los proveedores de OIDC, usted proporciona las asignaciones. Para crear la asignación, consulta la documentación del proveedor para ver una lista de atributos de sus credenciales.

Para obtener más información, consulta la documentación de la API sobre el campo attributeMapping.

Condiciones de los atributos

Una condición de atributo es una expresión CEL que puede comprobar atributos de aserción y atributos de destino. Si el atributo de condición se evalúa como true para una credencial determinada, se acepta la credencial. De lo contrario, se rechaza la credencial.

Puede usar una condición de atributo para restringir las identidades que pueden autenticarse con su grupo de identidades de carga de trabajo.

Las condiciones de los atributos son útiles en situaciones como las siguientes:

Si tu carga de trabajo usa un proveedor de identidades que está disponible para el público en general, puedes restringir el acceso para que solo las identidades que elijas tengan acceso a tu grupo de identidades de carga de trabajo.
Si utilizas un proveedor de identidades con varias plataformas en la nube, puedes evitar que se usen con Trusted Cloudlas credenciales destinadas a otra plataforma y viceversa. De esta forma, se evita el problema del delegado confuso.

La condición de atributo de un proveedor de grupos de identidades de carga de trabajo puede usar la palabra clave assertion, que hace referencia a un mapa que representa la credencial de autenticación emitida por el proveedor de identidades. Puedes usar la notación de punto para acceder a los valores del mapa. Por ejemplo, las credenciales de AWS incluyen un valor arn al que puedes acceder como assertion.arn. Además, la condición del atributo puede usar cualquier atributo definido en el mapeo de atributos del proveedor.

En el siguiente ejemplo, solo se permiten solicitudes de identidades que tengan un rol de AWS específico:

attribute.aws_role == "ROLE_MAPPING"

Para obtener más información, consulta la documentación de la API sobre el campo attributeCondition.

Gestión de accesos

El flujo de intercambio de tokens devuelve un token de acceso federado. Puedes usar este token de acceso federado para conceder acceso a tu carga de trabajo en nombre de identidades principales en Trusted Cloud recursos y obtener un token de acceso de OAuth 2.0 de corta duración.

Puedes usar este token de acceso para proporcionar acceso de gestión de identidades y accesos.

Te recomendamos que uses la federación de identidades de cargas de trabajo para proporcionar acceso directamente a un Trusted Cloud recurso. Aunque la mayoría de las APIs admiten la federación de identidades de carga de trabajo, algunas APIs tienen limitaciones. Trusted Cloud Como alternativa, puedes usar la suplantación de identidad de cuenta de servicio.

El token de acceso de corta duración te permite llamar a cualquier API Trusted Cloud a la que tenga acceso el recurso o la cuenta de servicio.

Acceso directo a recursos

Puedes usar el acceso directo a recursos para conceder a tu identidad externa acceso directo a un recurso de Trusted Cloud mediante roles específicos del recurso.

Alternativa: suplantación de identidad de cuenta de servicio

Como alternativa a la asignación de acceso directo a los recursos, puedes usar la suplantación de identidad de cuentas de servicio.

Debes asignar a tu cuenta de servicio el rol Usuario de Workload Identity (roles/iam.workloadIdentityUser).

Ámbitos de principales y seguridad

Para conceder acceso a principales o subconjuntos de estos, se usan tipos de principales.

Tipos principales

En la siguiente tabla se describe cómo definir principales como personas y grupos de identidades:

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

Siguientes pasos

Usa la federación de identidades de carga de trabajo para que tus cargas de trabajo accedan a recursos de AWS o Azure, Active Directory, pipelines de implementación o proveedores de OIDC o SAML.
Consulta cómo gestionar grupos de identidades de carga de trabajo con la CLI de Google Cloud o la API REST.