Descripción general de mTLS de backend con identidad para cargas de trabajo administrada

En este documento, se proporciona una descripción general del uso de la identidad para cargas de trabajo administrada para lograr la TLS mutua (mTLS) entre un balanceador de cargas de aplicaciones y sus servidores de backend. La identidad para cargas de trabajo administrada aprovisiona y administra automáticamente los certificados X.509 desde Certificate Authority Service.

También puedes lograr mTLS de backend sin una 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 la Descripción general de la TLS con autenticación de backend y la mTLS de backend.

La información de este documento se basa en los conceptos que se presentan en los siguientes documentos:

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.

Para 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.

mTLS de backend con identidades para cargas de trabajo administradas
mTLS de backend con identidad para cargas de trabajo administrada (haz clic para ampliar).

El siguiente es un ejemplo de un X.509-SVID que funciona como un 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 trabajo
  • PROJECT_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 administradas

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 Google Cloud y sus servidores de backend pasan a formar parte de un dominio de confianza. 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 controlar qué cargas de trabajo pueden recibir un certificado X.509 para la identidad administrada.

Requisitos del certificado

Cuando configures los certificados, asegúrate de que cumplan con estos requisitos:

  • Las herramientas de criptografía modernas son la base de la autenticación de mTLS. Los certificados deben usar algoritmos RSA o ECDSA para el intercambio de claves. Los algoritmos de hash deben usar SHA-256 o una función hash criptográfica más potente. No se admiten algoritmos de hash como MD4, MD5 y SHA-1.

  • Los certificados de servidor hoja que proporciona el backend tienen los siguientes requisitos:

  • Los certificados de cliente hoja (balanceador de cargas) que se usan en la mTLS de backend son los certificados de identidad administrados por el Administrador de certificados creados automáticamente y deben cumplir automáticamente con los siguientes requisitos:

  • Para autenticar los certificados de servidor que tu backend presenta al balanceador de cargas, los certificados raíz e intermedios que se encuentran en la configuración de confianza deben cumplir con los siguientes requisitos:

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 de forma automática.

  1. Configura un grupo de AC de Certificate Authority Service para emitir certificados a identidades para cargas de trabajo administradas.
  2. 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.
  3. Configura el servicio de backend del balanceador de cargas con la identidad administrada.

  4. 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 administrada de Certificate Manager 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 Administrador de certificados está sincronizada con la configuración de confianza intercalada del grupo de identidades para cargas de trabajo.

  5. 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.

mTLS de backend con identidad para cargas de trabajo administrada
Arquitectura de mTLS de backend con identidad para cargas de trabajo administrada (haz clic para ampliar).

Recursos creados durante la 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 del backend, la configuración de confianza de Administrador de certificados ni el certificado de Administrador de certificados. Estos recursos se crean automáticamente con la identidad para cargas de trabajo administrada.

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.

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 las demás.

Para usar identidades administradas, debes configurar el grupo de identidades para cargas de trabajo en 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 las identidades para cargas de trabajo relacionadas.

Workload Identity administrada

La identidad de carga de trabajo administrada se basa en el estándar de SPIFFE, que proporciona un framework para identificar, autenticar y proteger las comunicaciones entre cargas de trabajo con un ID de SPIFFE único.

Una identidad para cargas de trabajo administrada 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 recursoGoogle Cloud . 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 la 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 que Google Cloud IAM verifique si el servicio de backend es apto para recibir un certificado X.509 para la identidad administrada.

Si la verificación de la política de certificación supera, IAM solicita un certificado X.509 para la identidad administrada al Certificate Authority Service. 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 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 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 del Administrador de certificados 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 la CA del grupo a la configuración de confianza intercalada, ya que 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.

Es la jerarquía de recursos de la identidad para cargas de trabajo administrada.
Jerarquía de recursos de identidad de cargas de trabajo administrada (haz clic para ampliar).

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 atributo tlsSettings:

    • tlsSettings.sni
    • tlsSettings.subjectAltNames
    • tlsSettings.authenticationConfig

  • El campo identity solo se puede asignar durante la creación del servicio de backend.

  • El campo identity es 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 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 campo additionalTrustBundles en la configuración de confianza intercalada del grupo de identidades para cargas de trabajo. Para obtener más información, consulta Verifica que la configuración de confianza del Administrador de certificados contenga el campo spiffeTrustStores.

Para obtener más información sobre cómo el campo spiffeTrustStores en la configuración de confianza del Administrador de certificados permite la validación de certificados SPIFFE, consulta Pasos para la validación de certificados de servidor.

Certificado de identidad administrada de Certificate Manager (API de Certificate Manager)

La identidad administrada crea automáticamente el certificado de identidad administrada de Certificate Manager. El certificado de identidad administrado por 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 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 SVID X.509 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.

Pasos para la validación del certificado del servidor

Cuando valida el certificado del servidor durante la mTLS de backend, el balanceador de cargas hace lo siguiente:

  1. Verifica que el servidor posea la clave privada del certificado.

    El servidor demuestra que posee la clave privada asociada al certificado que presenta al balanceador de cargas firmando un fragmento de información con su clave privada y enviándolo al balanceador de cargas como parte del mensaje CertificateVerify. Luego, el balanceador de cargas verifica esta firma con la clave pública del certificado del servidor. Si falla la verificación de la firma, significa que el servidor de backend no posee la clave privada correspondiente al certificado. En esos casos, el balanceador de cargas finaliza el protocolo de enlace TLS sin registrar ningún error.

  2. Verifica la cadena de confianza.

    El campo spiffeTrustStores en la configuración de confianza de Administrador de certificados permite la validación de certificados SPIFFE. El campo spiffeTrustStores en la configuración de confianza del Administrador de certificados 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 con almacenes de confianza de varios dominios de seguridad distintos. Cuando un backend presenta su certificado SPIFFE, el balanceador de cargas extrae el ID de SPIFFE, identifica el dominio de confianza y usa el mapa de spiffeTrustStores para buscar el almacén de confianza correcto para verificar la cadena de confianza y validar el certificado.

    Las verificaciones incluyen lo siguiente:

    • El certificado del servidor, los certificados intermedios (si se proporcionan) y el certificado raíz configurado del backend cumplen con los requisitos de certificado.
    • Para todos los certificados de la cadena de confianza, el campo de asunto del certificado principal coincide con el campo de emisor del certificado secundario. Esta verificación ayuda a garantizar que la identidad (sujeto) del certificado principal sea la misma que la identidad que aparece como emisor en el certificado secundario.
    • Para todos los certificados de la cadena de confianza, el identificador de clave de asunto (SKID) del certificado principal coincide con el identificador de clave de autoridad (AKID) del certificado secundario. Esta coincidencia confirma que la autoridad raíz correcta emitió el certificado secundario y que se puede confiar en él porque se hace referencia a la clave pública de la raíz en el AKID para verificar la validez del certificado.

  3. Establece una conexión con el backend.

    Si la validación del certificado se realiza correctamente, el balanceador de cargas continúa con la conexión al backend.

    Sin embargo, si falla la validación del certificado, el balanceador de cargas finaliza la conexión con el backend, envía un código de estado HTTP 502 al cliente y registra el motivo de la finalización en Cloud Logging. En caso de un error de validación del certificado, las solicitudes entrantes posteriores hacen que el balanceador de cargas reinicie la conexión de backend.

    La conexión de backend también puede fallar si el servidor de backend rechaza la conexión. Con la mTLS de backend, esto puede ocurrir porque el certificado de cliente se considera no válido. Cuando falla la conexión al backend, el balanceador de cargas responde a las solicitudes proxy con un código de estado HTTP 502 y registra un motivo de error genérico en Cloud Logging.

Manejo de errores y registro

Los balanceadores de cargas de aplicaciones proporcionan capacidades de registro detalladas que te permiten supervisar la validación de certificados del servidor, identificar posibles problemas y solucionar problemas de conexión. En esta sección, se describen los diferentes tipos de errores que pueden ocurrir durante la validación de mTLS y cómo se registran.

Si falla la validación del certificado del servidor, se finaliza la conexión y los errores se registran en Cloud Logging. Estos errores se describen en la siguiente tabla.

Estado del certificado del servidor Error registrado
La cadena de certificados del servidor es demasiado larga (se incluyen más de 10 certificados intermedios con el certificado del servidor). server_cert_chain_exceeded_limit

Un cliente o certificado intermedio tienen un tamaño de clave RSA no válido.

No se realiza ninguna validación.

Las claves RSA pueden ser de 2,048 a 4,096 bits.

 server_cert_invalid_rsa_key_size

Un servidor o un certificado intermedio usan una curva elíptica no compatible.

No se realiza ninguna validación.

Las curvas válidas son P-256 y P-384.

 server_cert_unsupported_elliptic_curve_key

Un cliente o un certificado intermedio usan un algoritmo que no es RSA ni ECDSA.

No se realiza ninguna validación.

 server_cert_unsupported_key_algorithm

La PKI que se usará para la validación tiene más de diez certificados intermedios que comparten la misma información de la entidad y la clave pública de la entidad.

No se realiza ninguna validación.

 server_cert_pki_too_large

Un certificado intermedio proporcionado para la validación tenía más de 10 restricciones de nombres.

server_cert_chain_max_name_constraints_exceeded

El certificado del servidor tiene un campo de extensión Extended Key Usage (EKU), pero ese campo no incluye serverAuth.

server_cert_chain_invalid_eku
Se excede el límite de tiempo mientras se intenta validar la cadena de certificados. server_cert_validation_timed_out

Se alcanza el límite de iteración o profundidad mientras se intenta validar la cadena de certificados.

La profundidad máxima de una cadena de certificados es de diez, incluidos los certificados raíz y de cliente. La cantidad máxima de iteraciones es 100 (certificados examinados para validar la cadena del certificado de cliente).

 server_cert_validation_search_limit_exceeded

Configuraste mTLS sin establecer un recurso TrustConfig.

 server_cert_validation_not_performed

El servidor no proporcionó el certificado solicitado durante el protocolo de enlace.

 server_cert_not_provided

No se pudo verificar el certificado del servidor con el recurso TrustConfig.

 ssl_certificate_verification_failed

El servicio no puede realizar la validación de la cadena de certificados.

 server_cert_validation_unavailable
Cadena de certificados de validación de errores internos. server_cert_validation_internal_error

No se encontró la TrustConfig coincidente.

 server_cert_trust_config_not_found
La carga útil del certificado de cliente (incluidos los certificados intermedios) es demasiado grande (más de 16 KB). server_cert_exceeded_size_limit

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 configurar manualmente los siguientes campos en la propiedad tlsSettings del servicio de backend:

    • backendService.tlsSettings.sni
    • backendService.tlsSettings.subjectAltNames
    • backendService.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.

¿Qué sigue?