Puedes lograr mTLS de backend con o sin identidad de carga de trabajo administrada. Para obtener más información sobre la mTLS de backend sin identidad para cargas de trabajo administrada, 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 administrada para lograr la autenticación TLS mutua (mTLS) entre un balanceador de cargas de aplicaciones y sus servidores de backend. La identidad para cargas de trabajo administradas aprovisiona y administra automáticamente los certificados X.509 desde Certificate Authority Service.
La información de este documento se basa en los conceptos que se presentan 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 administrada para balanceadores de cargas
Sin la identidad de carga de trabajo administrada, 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 de carga de trabajo administrada crea automáticamente los recursos necesarios para la mTLS, como el certificado de cliente, la configuración de confianza y la configuración de autenticación de backend.
En el caso de la 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 muestran el balanceador de cargas (carga de trabajo de origen) y el backend (carga de trabajo de destino) que se autentican mutuamente con la identidad de carga de trabajo administrada.
El siguiente es un ejemplo de un X.509-SVID que funciona 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: Es el número de tu proyecto deGoogle Cloud .NAMESPACE_ID: Es el ID del espacio de nombres.MANAGED_IDENTITY_ID: El ID de la identidad administrada
Beneficios de usar la identidad para cargas de trabajo administrada
A continuación, se indican algunos beneficios de usar la identidad de carga de trabajo administrada para mTLS de backend:
Seguridad mejorada: Cuando se une a un grupo de identidades para cargas de trabajo, un balanceador de cargas y sus servidores de backend pasan a formar parte de un dominio de confianza. Google Cloud Cuando se usa en conjunto con la 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 de SPIFFE, un estándar para administrar identidades en sistemas distribuidos que permite la autenticación y la autorización en arquitecturas modernas basadas en microservicios.
Gobernanza 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 regir qué cargas de trabajo pueden recibir un certificado X.509 para la identidad administrada.
Arquitectura de mTLS de backend con identidad de carga de trabajo administrada
Los siguientes componentes trabajan en conjunto para lograr la autenticación mTLS de backend con la identidad de carga de trabajo administrada:
- 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 de Certificate Manager (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 del 1 al 3 representan recursos creados de forma explícita, mientras que los pasos del 4 al 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 creando 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 de carga de trabajo administrada crea automáticamente el certificado de identidad administrada de Certificate Manager y la configuración de confianza de Certificate Manager.
El certificado de identidad administrado por el Administrador de certificados se crea según la configuración de emisión de certificados en el grupo de identidades para cargas de trabajo. La configuración de confianza de Certificate Manager está sincronizada con la configuración de confianza intercalada del grupo de identidades para cargas de trabajo.
La identidad para cargas de trabajo administrada 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 administrado por Certificate Manager (X.509-SVID) también se adjunta a la configuración de autenticación de backend, que luego se usa para autenticarse en el backend.
Para obtener más información sobre la configuración de mTLS de backend con identidad administrada, consulta Configura la mTLS de backend con identidad de carga de trabajo administrada.
Recursos creados durante la autenticación mutua de TLS 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 del backend, la configuración de confianza de Certificate Manager ni el certificado de Certificate Manager. La identidad para cargas de trabajo administrada crea estos recursos automáticamente.
En esta sección, se analiza con mayor detalle el proceso de configuración de la identidad administrada, y se hace hincapié 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 cuando se configura mTLS de backend con la identidad de carga de trabajo administrada.
Grupo de autoridades certificadoras
Para configurar identidades para cargas de trabajo administradas para el balanceador de cargas, primero debes configurar una entidad certificadora y, de manera opcional, una o más EC subordinadas. Esta configuración se conoce como jerarquía de CA.
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.
Workload Identity administrada
Debes crear una identidad para cargas de trabajo administradas en el espacio de nombres del grupo de identidades para cargas de trabajo. La identidad administrada es un ID de SPIFFE completamente especificado que se usa en el SVID presentado por la carga de trabajo del balanceador de cargas.
Política de certificación
Una política de certificación contiene reglas para que Google Cloud IAM verifique si el servicio de backend es apto para recibir un certificado X.509 para la identidad administrada que se le asignó.
Si se supera la verificación de la política de certificación, IAM solicita un certificado X.509 para la identidad administrada al servicio de autoridad certificadora. El certificado X.509 se crea en el grupo de CA que está vinculado a la identidad administrada. El servicio de CA 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 intercalada de emisión de certificados
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 la clave.
El grupo de AC emite certificados X.509 a las 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 crear 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 administrada usa para validar certificados de intercambio de tráfico. La configuración de confianza de Certificate Manager encapsula un almacén de confianza de SPIFFE, que permanece sincronizado con la configuración de confianza intercalada del grupo de identidades para cargas de trabajo.
Dado 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 CA del grupo a la configuración de confianza intercalada, ya que esa confianza ya está integrada.
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 atributo tlsSettings apunte a la nueva propiedad identity (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 establecer 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 configurar la propiedad identity (backendService.tlsSettings.identity) en el servicio de backend del balanceador de cargas, la identidad de cargas de trabajo administrada 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 de Certificate Manager 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 campo additionalTrustBundles en la configuración de confianza intercalada del grupo de identidades para cargas de trabajo.
Para validar los certificados de SPIFFE, el campo spiffeTrustStores en la configuración de confianza de Certificate Manager se habilita automáticamente cuando se usa la identidad de carga de trabajo administrada. 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 los certificados de SPIFFE de ese dominio de confianza específico.
Básicamente, este mapa permite configurar el balanceador de cargas para que confíe en los almacenes 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 que se necesita para validar ese certificado.
Certificado de identidad administrada de Certificate Manager (API de Certificate Manager)
La identidad administrada de Certificate Manager crea automáticamente el certificado de identidad administrada. El certificado de identidad administrado por Certificate Manager es de solo lectura y no se puede editar ni borrar directamente con la API de Certificate Manager. El certificado de identidad administrado por Certificate Manager 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 de Certificate Manager tiene una propiedad managedIdentity, que lo identifica como un certificado de identidad administrada. El recurso de certificado de identidad administrada de Certificate Manager almacena el X.509-SVID en formato codificado con PEM. Este SVID X.509 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 administrado por el 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 configuración de autenticación de backend se crea automáticamente con la identidad para cargas de trabajo administrada. 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 administrado por el 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
La mTLS de backend con identidad de carga de trabajo administrada solo se puede configurar para los balanceadores de cargas de aplicaciones externos globales. Los balanceadores de cargas de aplicaciones clásicos no admiten mTLS de backend.
No se admite mTLS de backend para los backends de NEG de Internet globales.
Si asignas una identidad administrada al servicio de backend (
backendService.tlsSettings.identity), no puedes establecer manualmente los siguientes campos en la propiedadtlsSettingsdel 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.