Puedes lograr mTLS de backend con o sin identidad para cargas de trabajo administradas. Para obtener más información sobre mTLS de backend sin identidad para cargas de trabajo administradas, consulta Descripción general de la TLS con autenticación de backend y la mTLS de backend.
En este documento, se proporciona una descripción general del uso de la identidad para cargas de trabajo administradas para lograr TLS mutua (mTLS) entre un balanceador de cargas de aplicaciones y sus backends. La identidad para cargas de trabajo administradas aprovisiona y administra automáticamente los certificados X.509 de Certificate Authority Service.
La información de este documento se basa en los conceptos introducidos en los siguientes documentos:
- Descripción general de las identidades para cargas de trabajo administradas
- Secure Production Identity Framework For Everyone (SPIFFE)
- Certificate Authority Service
- Descripción general de la TLS con autenticación de backend y la mTLS de backend
Introducción a la identidad para cargas de trabajo administradas para balanceadores de cargas
Sin la identidad para cargas de trabajo administradas, la configuración de mTLS de backend requiere la configuración de varios recursos. Cuando asignas una identidad administrada al servicio de backend de un balanceador de cargas, la identidad para cargas de trabajo administradas crea automáticamente los recursos necesarios para mTLS, como el certificado de cliente, la configuración de confianza y la configuración de autenticación de backend.
Para mTLS de backend, el recurso de servicio de backend del balanceador de cargas actúa como una carga de trabajo de origen que se autentica en el backend, que es la carga de trabajo de destino.
Puedes asignar una identidad administrada, representada por un ID de SPIFFE, al servicio de backend de un balanceador de cargas. Google Cloud Certificate Authority Service aprovisiona automáticamente un certificado X.509 para el ID de SPIFFE. Este certificado X.509 para el ID de SPIFFE también se conoce como documento de identidad verificable de SPIFFE (SVID). El servicio de backend del balanceador de cargas y sus backends usan los SVID para autenticarse entre sí a través de la autenticación mTLS.
En el siguiente diagrama, se muestra el balanceador de cargas (carga de trabajo de origen) y el backend (carga de trabajo de destino) que se autentican mutuamente con la identidad para cargas de trabajo administradas.
El siguiente es un ejemplo de un X.509-SVID que sirve como wrapper para el ID de SPIFFE. El ID de SPIFFE, representado como un URI, está codificado en el nombre alternativo del sujeto (SAN) de un certificado X.509.
Issuer:
C=US
O=Example Inc.
CN=Example CA
Validity:
Not Before: Jun 14 00:00:00 2025 GMT
Not After : Jun 16 00:00:00 2025 GMT
Subject (Distinguished Name):
C=US
O=Example Inc.
OU=Production
CN=api.example.com
Subject Public Key Info:
Public Key Algorithm: RSA Encryption
RSA Public-Key: (2048 bit)
X.509v3 Extensions:
Subject Alternative Name (SAN):
DNS: api.example.com
URI: spiffe://WORKLOAD_IDENTITY_POOL_ID.global.PROJECT_NUMBER.workload.id.goog/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID
En esta salida, se incluyen los siguientes valores:
WORKLOAD_IDENTITY_POOL_ID: el ID del grupo de identidades para cargas de trabajoPROJECT_NUMBER: el número de proyecto de tu Google Cloud proyectoNAMESPACE_ID: el ID del espacio de nombresMANAGED_IDENTITY_ID: el ID de identidad administrada
Beneficios de usar la identidad para cargas de trabajo administradas
Estos son algunos de los beneficios de usar la identidad para cargas de trabajo administradas para mTLS de backend:
Seguridad mejorada: Cuando se une a un grupo de identidades para cargas de trabajo, un Google Cloud balanceador de cargas y sus backends forman parte de un dominio de confianza. Cuando se usa en conjunto con mTLS de backend, el balanceador de cargas y las cargas de trabajo de backend se autentican mutuamente. Esta autenticación mutua evita que las cargas de trabajo no autorizadas accedan a tus servicios y encripta los datos en tránsito.
Administración automatizada de certificados: Después de la certificación exitosa de la carga de trabajo, Google Cloud aprovisiona y rota automáticamente los certificados X.509 para las cargas de trabajo que participan en el dominio de confianza del grupo de identidades para cargas de trabajo. Esta administración automática de certificados X.509 elimina el proceso complejo y propenso a errores de la administración manual de certificados.
Identidad interoperable: Los grupos de identidades para cargas de trabajo usan el framework SPIFFE, un estándar para administrar identidades en sistemas distribuidos, lo que permite la autenticación y la autorización en arquitecturas modernas basadas en microservicios.
Administración centralizada: Los grupos de identidades para cargas de trabajo proporcionan un punto de control central. Los administradores pueden definir dominios de confianza y establecer políticas de certificación para determinar qué cargas de trabajo pueden recibir un certificado X.509 para la identidad administrada.
Arquitectura de mTLS de backend con identidad para cargas de trabajo administradas
Los siguientes componentes funcionan en conjunto para lograr mTLS de backend con identidad para cargas de trabajo administradas:
- Servicio de backend del balanceador de cargas (API de Compute Engine)
- Dominio de confianza de Identity and Access Management (API de Identity and Access Management)
- Grupo de autoridades certificadoras (API de Certificate Authority Service)
- Configuración de autenticación de backend (API de Network Security)
- Configuración de confianza del Administrador de certificados (API de Certificate Manager)
- Certificado de identidad administrada del Administrador de certificados (API de Certificate Manager)
En el siguiente diagrama, se muestra una identidad administrada en el servicio de backend del balanceador de cargas, lo que permite que el balanceador de cargas se autentique en el backend. En el diagrama, los pasos 1 a 3 representan recursos creados de forma explícita, mientras que los pasos 4 y 5 representan recursos creados automáticamente.
- Configura un grupo de AC de Certificate Authority Service para emitir certificados a identidades para cargas de trabajo administradas.
- Configura un dominio de confianza mediante la creación de un grupo de identidades para cargas de trabajo. Este grupo requiere un espacio de nombres, una identidad administrada, una política de certificación, un recurso de configuración de emisión de certificados intercalado y un recurso de configuración de confianza intercalado.
- Configura el servicio de backend del balanceador de cargas con la identidad administrada.
La identidad para cargas de trabajo administradas crea automáticamente el certificado de identidad administrada del Administrador de certificados y la configuración de confianza del Administrador de certificados.
El certificado de identidad administrada del Administrador de certificados se crea en función de la configuración de emisión de certificados en el grupo de identidades para cargas de trabajo. La configuración de confianza del Administrador de certificados está sincronizada con la configuración de confianza intercalada del grupo de identidades para cargas de trabajo.
La identidad para cargas de trabajo administradas crea automáticamente la configuración de autenticación de backend.
La configuración de confianza del Administrador de certificados se adjunta a la configuración de autenticación de backend. El certificado de identidad administrada del Administrador de certificados (X.509-SVID) también se adjunta a la configuración de autenticación de backend, que luego se usa para autenticar en el backend.
Para obtener más información sobre la configuración de mTLS de backend con identidad administrada, consulta Configura mTLS de backend con identidad para cargas de trabajo administradas.
Recursos creados durante mTLS de backend con identidad administrada
Como se muestra en el diagrama de arquitectura anterior, cuando asignas una identidad administrada al servicio de backend, no necesitas configurar la configuración de autenticación de backend, la configuración de confianza del Administrador de certificados ni el certificado del Administrador de certificados. La identidad para cargas de trabajo administradas crea estos recursos automáticamente.
En esta sección, se analizan en detalle las diferentes partes del proceso de configuración de identidad administrada, enfocándose en los recursos que se crean de forma explícita y los que se crean automáticamente.
Recursos creados de forma explícita
Los siguientes recursos deben crearse de forma explícita mientras se configura mTLS de backend con identidad para cargas de trabajo administradas.
Grupo de autoridades certificadoras
Para configurar identidades para cargas de trabajo administradas para el balanceador de cargas, primero debes configurar una autoridad certificadora y, de manera opcional, una o más AC subordinadas. Esta configuración se conoce como jerarquía de AC.
Puedes usar grupos de CA Service para configurar esta jerarquía.
El grupo de identidades para cargas de trabajo se vincula al grupo de AC actualizando el grupo de identidades para cargas de trabajo con la configuración de emisión de certificados intercalada.
Grupo de identidades para cargas de trabajo
Las identidades para cargas de trabajo administradas se definen dentro de un grupo de identidades para cargas de trabajo, que actúa como un dominio de confianza.
El dominio de confianza representa un límite de seguridad lógico dentro del cual las cargas de trabajo pueden autenticarse y autorizarse entre sí con sus IDs de SPIFFE. Todas las cargas de trabajo dentro del mismo dominio de confianza comparten una raíz de confianza común, lo que permite que las cargas de trabajo verifiquen las identidades de los demás.
Para usar identidades administradas, debes configurar el grupo de identidades para cargas de trabajo en un modo TRUST_DOMAIN. Todas las identidades dentro de un grupo constan de un solo espacio de nombres y un identificador de carga de trabajo individual.
Espacio de nombres
Dentro de un grupo de identidades para cargas de trabajo, las identidades de cargas de trabajo administradas se organizan en límites administrativos llamados espacios de nombres. Los espacios de nombres te ayudan a organizar y otorgar acceso a identidades para cargas de trabajo relacionadas.
Identidad para cargas de trabajo administradas
La identidad para cargas de trabajo administradas se basa en el estándar SPIFFE, que proporciona un framework para identificar, autenticar y proteger las comunicaciones entre cargas de trabajo con un ID de SPIFFE único.
La identidad para cargas de trabajo administradas o una identidad administrada es un identificador de carga de trabajo que se configura en un grupo de identidades para cargas de trabajo. Se adjunta a un Google Cloud recurso. Cada identidad administrada se identifica de forma única con un espacio de nombres y un identificador de carga de trabajo individual.
En el contexto de lograr mTLS de backend, la identidad administrada se adjunta al recurso de servicio de backend del balanceador de cargas.
El valor de una identidad administrada es un ID de SPIFFE completamente especificado que debe cumplir con el siguiente formato:
spiffe://TRUST_DOMAIN_NAME/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID
Un TRUST_DOMAIN_NAME se expande aún más de la siguiente manera:
WORKLOAD_IDENTITY_POOL_ID.global.PROJECT_NUMBER.workload.id.goog
Para unir todo, las cargas de trabajo de Compute Engine, como el recurso de servicio de backend de un balanceador de cargas, pueden tener una identidad administrada de la siguiente manera:
spiffe://WORKLOAD_IDENTITY_POOL_ID.global.PROJECT_NUMBER.workload.id.goog/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID
Política de certificación
Una política de certificación contiene reglas para Google Cloud IAM que verifique si el servicio de backend es apto para recibir un certificado X.509 para la identidad administrada.
Si pasa la verificación de la política de certificación, IAM solicita un certificado X.509 para la identidad administrada de Certificate Authority Service. El certificado X.509 se crea en el grupo de AC que está vinculado a la identidad administrada. CA Service aprovisiona el certificado a través de la reflexión de identidad, en la que el ID de SPIFFE configurado se refleja en un certificado X.509.
Configuración de emisión de certificados intercalada
Cuando configuras un grupo de identidades para cargas de trabajo, configuras una configuración de emisión de certificados intercalada. Esta configuración especifica qué grupo de AC de tu instancia de Certificate Authority Service se usa para generar certificados X.509 para las identidades dentro del grupo de identidades para cargas de trabajo. El archivo de configuración también especifica la vida útil del certificado, el porcentaje de la ventana de rotación y el algoritmo de clave.
El grupo de AC emite certificados X.509 a identidades para cargas de trabajo administradas después de que se aplica correctamente la política de certificación.
Configuración de confianza intercalada del grupo de identidades para cargas de trabajo
De forma predeterminada, tus cargas de trabajo dentro del mismo dominio de confianza pueden autenticarse mutuamente con identidades para cargas de trabajo administradas. Si deseas que las cargas de trabajo que se encuentran en diferentes dominios de confianza se autentiquen mutuamente, debes declarar explícitamente la relación de confianza en el grupo de identidades para cargas de trabajo. Para ello, crea una configuración de confianza intercalada que reconozca y acepte certificados de otros dominios de confianza. Estos certificados se usan para compilar una cadena de confianza y verificar la identidad de las cargas de trabajo de otros dominios.
La configuración de confianza intercalada contiene un conjunto de anclas de confianza que la identidad para cargas de trabajo administradas usa para validar certificados de intercambio de tráfico. La configuración de confianza del Administrador de certificados encapsula un almacén de confianza SPIFFE, que permanece sincronizado con la configuración de confianza intercalada del grupo de identidades para cargas de trabajo.
Debido a que el grupo de identidades para cargas de trabajo está vinculado al grupo de AC, el grupo de identidades para cargas de trabajo confía automáticamente en los certificados raíz de ese mismo grupo de AC. No es necesario que agregues las raíces de AC del grupo a la configuración de confianza intercalada porque esa confianza ya está integrada.
En el siguiente diagrama, el balanceador de cargas y el backend forman parte del mismo dominio de confianza y comparten el mismo certificado raíz. El certificado raíz se usa para compilar una cadena de confianza y verificar la identidad de las cargas de trabajo dentro del dominio de confianza.
Servicio de backend (API de Compute Engine)
Para asignar una identidad administrada al balanceador de cargas,
debes configurar el servicio de backend del balanceador de cargas de modo que su
tlsSettings atributo apunte a la nueva identity propiedad
(backendService.tlsSettings.identity).
Ten en cuenta las siguientes restricciones que se aplican cuando se usa el campo identity en el servicio de backend del balanceador de cargas:
Si estableces la propiedad
identity, no puedes configurar manualmente los siguientes campos en el atributotlsSettings:tlsSettings.snitlsSettings.subjectAltNamestlsSettings.authenticationConfig
El campo
identitysolo se puede asignar durante la creación del servicio de backend.El campo
identityes inmutable. Después de asignar uno al servicio de backend del balanceador de cargas, no se puede actualizar ni borrar.
Recursos creados automáticamente
Después de establecer la propiedad identity (backendService.tlsSettings.identity)
en el servicio de backend del balanceador de cargas, la identidad para cargas de trabajo administradas crea automáticamente los siguientes recursos en la
API de Certificate Manager y la API de Network Security.
Los recursos creados automáticamente se crean en el mismo proyecto que el servicio de backend y usan las cuotas estándar de ese proyecto.
Configuración de confianza del Administrador de certificados (API de Certificate Manager)
La configuración de confianza del Administrador de certificados se crea automáticamente y no se puede editar ni borrar directamente.
La configuración de confianza del Administrador de certificados contiene un campo llamado spiffeTrustStores. El campo spiffeTrustStores contiene el paquete de confianza
asociado con el dominio de confianza del grupo de identidades para cargas de trabajo
y cualquier paquete de confianza adicional
especificado por el additionalTrustBundles campo
en la configuración de confianza intercalada del grupo de identidades para cargas de trabajo.
Para validar los certificados SPIFFE, el campo spiffeTrustStores en la configuración de confianza del Administrador de certificados se habilita automáticamente cuando se usa la identidad para cargas de trabajo administradas. Con el campo spiffeTrustStores habilitado, el campo trustStores permanece vacío.
El campo spiffeTrustStores es una estructura de datos de mapa en la que el par clave-valor es el siguiente:
- La clave puede ser un dominio de confianza relacionado con un grupo de identidades para cargas de trabajo (en el formato que termina con
.workload.id.goog) o un dominio de confianza adicional. - El valor es un objeto
TrustStore. Este objeto contiene una colección de certificados raíz de confianza (conocidos como paquete de confianza) que se usan para validar certificados SPIFFE de ese dominio de confianza específico.
En esencia, este mapa permite configurar el balanceador de cargas para que confíe en los almacenes de confianza de varios dominios de seguridad distintos. Cuando un backend presenta su certificado, el balanceador de cargas extrae el ID de SPIFFE, identifica el dominio de confianza y usa el mapa para buscar el almacén de confianza correcto necesario para validar ese certificado.
Certificado de identidad administrada del Administrador de certificados (API de Certificate Manager)
La identidad para cargas de trabajo administradas crea automáticamente el certificado de identidad administrada del Administrador de certificados. El certificado de identidad administrada del Administrador de certificados es de solo lectura y no se puede editar ni borrar directamente con la API de Certificate Manager. El certificado de identidad administrada del Administrador de certificados se basa en la configuración de emisión de certificados intercalada, que se define en el grupo de identidades para cargas de trabajo.
El certificado de identidad administrada del Administrador de certificados tiene una propiedad managedIdentity, que lo identifica como un certificado de identidad administrada. El recurso de certificado de identidad administrada del Administrador de certificados almacena el X.509-SVID en formato codificado con PEM. Este X.509-SVID contiene el ID de SPIFFE codificado como un URI en el campo SAN.
Este ID de SPIFFE corresponde a la identidad administrada en el grupo de identidades para cargas de trabajo.
El alcance del certificado de identidad administrada del Administrador de certificados es CLIENT_AUTH, lo que indica que este certificado se usa como certificado de cliente en mTLS de backend.
Configuración de autenticación de backend (API de Network Security)
La identidad para cargas de trabajo administradas crea automáticamente la configuración de autenticación de backend. La configuración de autenticación de backend es de solo lectura y no se puede editar ni borrar directamente con la API de Network Security.
La configuración de confianza del Administrador de certificados se adjunta a la configuración de autenticación de backend.
El certificado de identidad administrada del Administrador de certificados también se adjunta a la configuración de autenticación de backend y se usa como un X.509-SVID en las solicitudes de mTLS de backend entre el balanceador de cargas y las cargas de trabajo de destino.
Limitaciones
mTLS de backend con identidad para cargas de trabajo administradas solo se puede configurar para balanceadores de cargas de aplicaciones externos globales. Los balanceadores de cargas de aplicaciones clásicos no admiten mTLS de backend.
mTLS de backend no es compatible con los backends de NEG de Internet globales.
Si asignas una identidad administrada al servicio de backend (
backendService.tlsSettings.identity), no puedes configurar manualmente los siguientes campos en latlsSettingspropiedad del servicio de backend:backendService.tlsSettings.snibackendService.tlsSettings.subjectAltNamesbackendService.tlsSettings.authenticationConfig
La identidad administrada solo se puede asignar en el momento de la creación del servicio de backend.
La identidad administrada es inmutable. Después de asignar una identidad administrada al servicio de backend del balanceador de cargas, no se puede actualizar ni borrar.