Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Configura la federación de identidades de personal (BYOID)

En esta guía, se explica cómo configurar Usa tu proveedor de identidad (BYOID) para la API de Multi-party Compute con la federación de identidades de personal y la federación de identidades para cargas de trabajo. Con la federación de identidades, los usuarios humanos y las cargas de trabajo de firmantes automatizadas pueden autenticarse en la computación multipartita con el proveedor de identidad (IdP) externo de tu organización, como Okta, Microsoft Entra ID o Ping Identity. No es necesario que crees Cuentas de Google ni que administres claves de cuentas de servicio de larga duración.

Descripción general

La federación de identidades se integra con el modelo de seguridad de defensa en profundidad de la computación multipartita en las siguientes capas:

Autorización de Identity and Access Management (IAM) perimetral: Los emisores intercambian credenciales de un IdP externo de OpenID Connect (OIDC) o SAML 2.0 con el servicio de tokens de seguridad de Google Cloud (servicio de tokens de seguridad) por un token de acceso federado de corta duración. La puerta de enlace de la API de Google Cloud evalúa las vinculaciones de roles de IAM con el URI de la principal federada antes de reenviar las solicitudes a tu instancia de procesamiento de varias partes y propaga la identidad federada (principalSubject) para los Registros de auditoría de Cloud.
Separación de obligaciones y aprobación criptográfica: Los roles de IAM separan el aprovisionamiento administrativo (roles/mpc.admin), la participación operativa (roles/mpc.editor) y la supervisión de solo lectura (roles/mpc.viewer). Dentro de tu instancia, los administradores, los autores de políticas y los firmantes también necesitan un usuario cuyo rol (ADMIN, POLICY_AUTHOR o SIGNER) verifique la instancia en busca de métodos que actúen en nombre de un usuario, y las aprobaciones deben firmarse con la clave de autorización registrada en ese usuario. Para obtener más información, consulta Cómo se autoriza una solicitud.

Según el tipo de emisor, puedes usar dos mecanismos de federación de identidades:

Federación de identidades de personal (locations/global/workforcePools/...): Autentica a los usuarios humanos (administradores, autores de políticas, firmantes y encargados de cumplimiento) con grupos de personal a nivel de la organización asignados a tu IdP corporativo. En esta guía, se explica cómo configurar la federación de identidades de personal de extremo a extremo.
Federación de identidades para cargas de trabajo (projects/.../locations/global/workloadIdentityPools/...): Autentica cargas de trabajo automatizadas (como daemons de cofirmantes sin interfaz gráfica que se ejecutan en AWS, Azure o Kubernetes) con grupos de identidades para cargas de trabajo a nivel del proyecto.

Para obtener más información sobre cómo se asignan los roles de IAM a los roles de computación multipartita, consulta Seguridad y autorización.

Antes de comenzar

Antes de comenzar, asegúrate de tener lo siguiente:

Una organización de Google Cloud y un proyecto de consumidor incorporado a la computación multipartita.
La CLI de gcloud y jq instalados, y gcloud autenticado con una cuenta de administrador que tenga los siguientes roles:
- Administrador de grupos de trabajadores (roles/iam.workforcePoolAdmin) en tu organización de Google Cloud (si creas un grupo de trabajadores nuevo en el paso 1).
- Administrador de IAM del proyecto (roles/resourcemanager.projectIamAdmin) y Administrador de Service Usage (roles/serviceusage.serviceUsageAdmin) en tu proyecto de consumidor.

Las APIs necesarias habilitadas en tu proyecto de consumidor:

gcloud services enable mpc.googleapis.com iam.googleapis.com sts.googleapis.com \
  --project="my-project"

Una aplicación externa de OIDC o SAML 2.0 configurada en tu IdP corporativo. Si planeas usar el acceso interactivo al navegador con la CLI de gcloud, configura el URI de redireccionamiento de Google Cloud en tu aplicación de IdP (consulta las guías de configuración para Okta y Microsoft Entra ID).

Configuración

Actualiza las siguientes variables para propagar los comandos en esta guía.

Parámetros de configuración obligatorios

Personaliza estos parámetros para que coincidan con tu Google Cloud entorno y la configuración del IdP externo.

Parámetro	Valor	Descripción
ID de organización	`123456789012`	Es el ID de organización numérico de Google Cloud .
ID del proyecto	`my-project`	Es el ID del proyecto de consumidor registrado para tu instancia de procesamiento multipartita.
ID del dominio	`67317436-0f29-ba9e-9146-d11c0bd8df9b`	Es el ID de dominio único asignado a tu instancia de procesamiento de múltiples partes.
ID de la ruta de la instancia	`mpc-unit-bob-123`	Es el ID de la ruta de acceso de la instancia asignado a tu instancia de procesamiento multipartito.
Ubicación	`us-central1`	Ubicación de la Deployment (`us-central1`). Para obtener más información, consulta Ubicaciones de computación multipartita.
ID del grupo de personal	`mpc-workforce-pool`	Es el ID del grupo de identidades del personal a nivel de la organización.
ID del proveedor	`mpc-oidc-provider`	Es el ID del proveedor del grupo de identidades del personal.
URI de la entidad emisora del IdP	`https://idp.example.com`	Es el URI de la entidad emisora del IdP de OIDC externo.
ID de cliente del IdP	`mpc-client`	Es el ID de cliente de OAuth 2.0 configurado en tu IdP externo.

Paso 1: Configura un grupo y un proveedor de Workforce Identity

Los grupos de identidades de personal (locations/global/workforcePools/mpc-workforce-pool) son recursos a nivel de la organización que se asignan al usuario de IdP de tu empresa. No es necesario que crees grupos de personal independientes para cada proyecto o rol.

Crea un grupo de Workforce Identity en tu organización de Google Cloud :

gcloud iam workforce-pools create "mpc-workforce-pool" \
  --organization="123456789012" \
  --location="global" \
  --display-name="MPC Workforce Pool"

Crea un proveedor de grupos de personal de OIDC que confíe en tu IdP externo y asigne reclamaciones de sujetos y grupos:
```
gcloud iam workforce-pools providers create-oidc "mpc-oidc-provider" \
  --workforce-pool="mpc-workforce-pool" \
  --location="global" \
  --display-name="MPC Enterprise OIDC Provider" \
  --issuer-uri="https://idp.example.com" \
  --client-id="mpc-client" \
  --attribute-mapping="google.subject=assertion.sub,google.groups=assertion.groups" \
  --web-sso-response-type="id-token" \
  --web-sso-assertion-claims-behavior="only-id-token-claims"
```
Nota: De forma predeterminada, el Servicio de tokens de seguridad descubre y rota las claves de firma públicas del extremo /.well-known/openid-configuration de tu IdP. Si realizas pruebas con un emisor de OIDC sin conexión o sintético al que no se puede acceder de forma pública, pasa --jwk-json-path="<var>PATH_TO_JWK_FILE</var>" y reemplaza <var>PATH_TO_JWK_FILE</var> por la ruta de acceso local al archivo de conjunto de claves web JSON (JWKS) público de tu emisor. Para los proveedores de SAML 2.0, usa gcloud iam workforce-pools providers create-saml con --idp-metadata-path.

Paso 2: Otorga roles de IAM a las principales federadas

Para llamar a la API de MPC, las principales federadas requieren dos tipos de vinculaciones de roles de IAM en tu proyecto de consumidor (my-project):

Consumidor de Service Usage (roles/serviceusage.serviceUsageConsumer), que autoriza a la identidad federada a atribuir la cuota y la facturación de la API a tu proyecto de consumidor.
Un rol de Multi-party Compute (roles/mpc.admin, roles/mpc.editor o roles/mpc.viewer), que autoriza operaciones específicas de Multi-party Compute.

En producción, vincula roles de IAM a distintos grupos de IdP dentro de tu grupo de personal:

# 1. Allow members of the workforce pool to consume APIs through the consumer project
gcloud projects add-iam-policy-binding "my-project" \
  --role="roles/serviceusage.serviceUsageConsumer" \
  --member="principalSet://iam.googleapis.com/locations/global/workforcePools/mpc-workforce-pool/*"

# 2. Grant MPC Admin to the enterprise administrators group
gcloud projects add-iam-policy-binding "my-project" \
  --role="roles/mpc.admin" \
  --member="principalSet://iam.googleapis.com/locations/global/workforcePools/mpc-workforce-pool/group/mpc-admins"

# 3. Grant MPC Editor to Policy Authors and Signers groups
gcloud projects add-iam-policy-binding "my-project" \
  --role="roles/mpc.editor" \
  --member="principalSet://iam.googleapis.com/locations/global/workforcePools/mpc-workforce-pool/group/mpc-policy-authors"

gcloud projects add-iam-policy-binding "my-project" \
  --role="roles/mpc.editor" \
  --member="principalSet://iam.googleapis.com/locations/global/workforcePools/mpc-workforce-pool/group/mpc-signers"

# 4. Grant MPC Viewer to the Compliance group
gcloud projects add-iam-policy-binding "my-project" \
  --role="roles/mpc.viewer" \
  --member="principalSet://iam.googleapis.com/locations/global/workforcePools/mpc-workforce-pool/group/mpc-auditors"

Cargas de trabajo de firmantes automatizadas (federación de identidades para cargas de trabajo)

Si ejecutas daemons de cofirmante automatizados fuera de Google Cloud (por ejemplo, en AWS, Azure o Kubernetes), configura un grupo de identidades para cargas de trabajo y un proveedor con alcance de proyecto. Otorga roles/serviceusage.serviceUsageConsumer y roles/mpc.editor a la principal de la carga de trabajo (principal://iam.googleapis.com/projects/<var>PROJECT_NUMBER</var>/locations/global/workloadIdentityPools/<var>WORKLOAD_POOL_ID</var>/subject/<var>SIGNER_NODE_SUBJECT</var>, reemplazando <var>PROJECT_NUMBER</var>, <var>WORKLOAD_POOL_ID</var> y <var>SIGNER_NODE_SUBJECT</var> por tu número de proyecto, ID del grupo de cargas de trabajo y reclamación de sub de la carga de trabajo) y genera un archivo de credenciales predeterminadas de la aplicación con gcloud iam workload-identity-pools create-cred-config.

Agrega identidades federadas como usuarios de v1beta

En la API v1beta, los roles de IAM de este paso permiten que una identidad federada llame a tu instancia. Para actuar dentro de la instancia, como administrador, autor de políticas o firmante, la identidad también necesita un usuario. La instancia identifica al emisor haciendo coincidir su principal con el campo principal de cada usuario.

Para una identidad federada de Workforce Identity Federation, establece principal en el identificador principal del sujeto de la identidad:

principal://iam.googleapis.com/locations/global/workforcePools/mpc-workforce-pool/subject/SUBJECT_ID

Reemplaza SUBJECT_ID por el valor que tu proveedor asigna a google.subject. Con la asignación de atributos del paso 1, es la reclamación sub del token de ID del usuario.

Cuando configures principal, ten en cuenta lo siguiente:

Usa un identificador principal://, no un identificador principalSet://. Un usuario es una persona. Los identificadores de grupos y grupos, como principalSet://.../group/mpc-signers, funcionan en las vinculaciones de roles de IAM, pero nunca coinciden con un emisor, por lo que un usuario creado con uno no puede actuar en la instancia.
Coincidir exactamente con el asunto La instancia compara los sujetos de personal y de carga de trabajo distinguiendo mayúsculas de minúsculas, por lo que debes copiar el sujeto tal como lo emite tu IdP. Los correos electrónicos de la Cuenta de Google, como alice@example.com, se comparan sin distinguir mayúsculas de minúsculas.
No puedes cambiar principal más adelante. Para cambiar la identidad de un usuario, inhabilítalo y crea uno nuevo.

Paso 3: Autentica y obtén un token de acceso federado

La API de MPC no acepta tokens de OIDC ni aserciones de SAML directamente de tu IdP. Intercambia la credencial del IdP con el servicio de tokens de seguridad por un token de acceso federado de Google Cloud antes de llamar al extremo de la instancia de procesamiento de varias partes (*.mpc.goog).

Puedes obtener y administrar tokens de acceso federados automáticamente con las credenciales predeterminadas de la aplicación (ADC) y la CLI de gcloud, o de manera programática con la API de Security Token Service.

Credenciales predeterminadas de la aplicación y gcloud CLI

En las aplicaciones cliente de producción y las sesiones interactivas de la CLI, usa un archivo de configuración para que el SDK de Google Cloud y las bibliotecas cliente de Cloud controlen el intercambio, el almacenamiento en caché y las actualizaciones de tokens del Servicio de tokens de seguridad en segundo plano de forma automática.

Opción A: Acceso interactivo al navegador

Genera un archivo de configuración de acceso y autentica la CLI de gcloud y las credenciales predeterminadas de la aplicación (ADC) con tu IdP corporativo:

gcloud iam workforce-pools create-login-config \
  "locations/global/workforcePools/mpc-workforce-pool/providers/mpc-oidc-provider" \
  --activate \
  --output-file="login-config.json"

gcloud config set billing/quota_project "my-project"
gcloud auth login --login-config="login-config.json"
gcloud auth application-default login --login-config="login-config.json"

Opción B: Acceso no interactivo con un archivo de configuración de credenciales (ADC)

Si un proceso externo proporciona y actualiza un token de OIDC firmado en un archivo local (por ejemplo, /var/run/secrets/tokens/oidc-token) antes de que venza el token, genera un archivo de configuración de credenciales externas:

gcloud iam workforce-pools create-cred-config \
  "locations/global/workforcePools/mpc-workforce-pool/providers/mpc-oidc-provider" \
  --subject-token-type="urn:ietf:params:oauth:token-type:id_token" \
  --credential-source-file="/var/run/secrets/tokens/oidc-token" \
  --workforce-pool-user-project="my-project" \
  --output-file="credential-config.json"

export GOOGLE_APPLICATION_CREDENTIALS="$(pwd)/credential-config.json"

Exporta el token de acceso para las solicitudes de curl:

Después de completar la opción A o la opción B, exporta el token de acceso federado de ADC a ACCESS_TOKEN:

export ACCESS_TOKEN="$(gcloud auth application-default print-access-token)"

Intercambio directo de tokens de STS de REST

Si integras un cliente personalizado sin los SDK de Google Cloud , intercambia un token de ID de OIDC firmado (<var>IDP_ID_TOKEN</var>) directamente con el Servicio de tokens de seguridad. Incluye userProject en el campo options para que Google Cloud atribuya el token a tu proyecto de consumidor:

# Set IDP_ID_TOKEN to the signed OIDC JWT assertion from your external IdP
# export IDP_ID_TOKEN="eyJhbGciOiJSUzI1NiIs..."

STS_RESPONSE=$(curl -sS -X POST "https://sts.googleapis.com/v1/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data-urlencode "grant_type=urn:ietf:params:oauth:grant-type:token-exchange" \
  --data-urlencode "audience=//iam.googleapis.com/locations/global/workforcePools/mpc-workforce-pool/providers/mpc-oidc-provider" \
  --data-urlencode "scope=https://www.googleapis.com/auth/cloud-platform" \
  --data-urlencode "requested_token_type=urn:ietf:params:oauth:token-type:access_token" \
  --data-urlencode "subject_token_type=urn:ietf:params:oauth:token-type:id_token" \
  --data-urlencode "subject_token=${IDP_ID_TOKEN}" \
  --data-urlencode 'options={"userProject":"my-project"}')

export ACCESS_TOKEN=$(echo "${STS_RESPONSE}" | jq -er '.access_token') || echo "${STS_RESPONSE}" | jq .

Paso 4: Verifica el acceso federado a la API

Verifica que tus credenciales federadas, la atribución de userProject y las vinculaciones de roles de IAM funcionen. Para ello, enumera los usuarios en tu instancia de procesamiento multipartita. Debido a que mpc.googleapis.com/users.list se incluye en roles/mpc.viewer, roles/mpc.editor y roles/mpc.admin, cualquier persona federada autorizada puede ejecutar esta verificación:

curl -sS -X GET \
  -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  -H "X-Goog-User-Project: my-project" \
  "https://67317436-0f29-ba9e-9146-d11c0bd8df9b.us-central1.mpc.goog/v1beta/projects/my-project/locations/us-central1/instances/mpc-unit-bob-123/users" | jq .

Una respuesta JSON 200 OK (ya sea {} en una instancia nueva o una lista de users) confirma que tu identidad federada está autenticada y autorizada para llamar a tu instancia de procesamiento de varias partes.

Esta verificación solo usa IAM. Para confirmar que la instancia también reconoce tu identidad como usuario, verifica que uno de los usuarios devueltos tenga tu identificador de principal:// en su campo principal. Para obtener más información, consulta Agrega identidades federadas como usuarios de v1beta.

Soluciona problemas

Si encuentras errores de autenticación o permisos cuando llamas a la computación multipartita con credenciales federadas, verifica los siguientes requisitos:

Atribución del proyecto del usuario (`401 UNAUTHENTICATED: Unable to determine client project number`)

Causa: Las credenciales del grupo de personal a nivel de la organización no están vinculadas de forma intrínseca a un solo proyecto de Google Cloud , a menos que se especifique un proyecto de usuario durante el intercambio de tokens o en la solicitud.
Resolución: Incluye options: {"userProject": "<var>PROJECT_ID</var>"} en el cuerpo de la solicitud de intercambio de tokens del Servicio de tokens de seguridad (o --workforce-pool-user-project en gcloud iam workforce-pools create-cred-config) y el encabezado X-Goog-User-Project: <var>PROJECT_ID</var> en las llamadas a la API de MPC.

Falta el permiso de Service Usage (`403 PERMISSION_DENIED`)

Causa: El principal o grupo federado no tiene permiso para atribuir el uso de la API al proyecto de consumidor especificado en userProject o X-Goog-User-Project.
Resolución: Otorga roles/serviceusage.serviceUsageConsumer a tu miembro principal:// o principalSet:// en el proyecto de consumidor (consulta el paso 2).

No coincide el proyecto del consumidor (`403 PERMISSION_DENIED: Project is not allowed to call the API through this host`)

Causa: Cada extremo de instancia de procesamiento multipartita dedicado solo acepta solicitudes del proyecto de consumidor configurado para esa instancia.
Resolución: Verifica que <var>PROJECT_ID</var> en la ruta de URL de la solicitud y el encabezado userProject/X-Goog-User-Project coincidan con el proyecto de consumidor aprovisionado para tu instancia de procesamiento de varias partes.

Credencial no válida (`401 UNAUTHENTICATED: Request credential is invalid`)

Causa: Se envió un token de OIDC o una aserción de SAML de terceros directamente al extremo de computación multipartita sin intercambiarlo primero con el Servicio de tokens de seguridad.
Resolución: Intercambia tu credencial de IdP a través de https://sts.googleapis.com/v1/token (o usa las credenciales predeterminadas de la aplicación) y pasa el token de acceso de Google Cloud resultante en el encabezado Authorization: Bearer.

La política de uso compartido restringido al dominio bloquea las vinculaciones de roles (`400 FAILED_PRECONDITION`)

Causa: Tu organización de Google Cloud aplica la política de la organización constraints/iam.allowedPolicyMemberDomains, que restringe a qué dominios de principales se les pueden otorgar roles de IAM en los proyectos.
Resolución: Pídele al administrador de políticas de la organización que agregue el conjunto de principales de tu grupo de personal a los dominios de miembros de la política permitidos en tu proyecto o organización de consumidor, o que realice pruebas en un proyecto en el que constraints/iam.allowedPolicyMemberDomains permita tu grupo de personal.

¿Qué sigue?

Para crear usuarios, equipos, políticas de transacciones y claves, y para firmar transacciones con tu identidad federada, sigue la Guía del usuario de computación multipartita. Establece la principal de cada usuario en el identificador principal:// que se describe en Agrega identidades federadas como usuarios de v1beta.
La guía del usuario recupera el token de acceso de cada rol con gcloud auth print-access-token, que usa las credenciales de la CLI de gcloud, no las credenciales predeterminadas de la aplicación. Haz que cada usuario federado acceda con gcloud auth login --login-config, como se muestra en la opción A del paso 3.
Obtén más información sobre los roles de usuario, los permisos de IAM y las condiciones a nivel de recurso en Seguridad y autorización.