Visão geral do mTLS de back-end com identidade gerenciada da carga de trabalho

Visualizar

Este recurso está sujeito aos Termos das Soluções Pré-GA na seção Termos Gerais de Serviço dos Termos Específicos de Serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Este documento oferece uma visão geral do uso da identidade gerenciada da carga de trabalho para conseguir o TLS mútuo (mTLS) entre um balanceador de carga de aplicativo e os back-ends dele. A identidade da carga de trabalho gerenciada provisiona e gerencia automaticamente certificados X.509 do Certificate Authority Service.

Também é possível usar o mTLS de back-end sem a identidade gerenciada da carga de trabalho. Para saber mais sobre o mTLS de back-end sem a identidade gerenciada da carga de trabalho, consulte a visão geral da autenticação TLS e do mTLS de back-end.

Observação: na Visualização, a identidade gerenciada de carga de trabalho só pode ser atribuída ao serviço de back-end de um balanceador de carga de aplicativo externo global.

As informações neste documento se baseiam em conceitos apresentados nos seguintes documentos:

• Visão geral das identidades de cargas de trabalho gerenciadas
• Secure Production Identity Framework For Everyone (SPIFFE)
• Certificate Authority Service
• Visão geral do TLS autenticado de back-end e do mTLS de back-end

Introdução à identidade de carga de trabalho gerenciada para balanceadores de carga

Sem a identidade gerenciada da carga de trabalho, a configuração do mTLS de back-end exige a configuração de vários recursos. Ao atribuir uma identidade gerenciada ao serviço de back-end de um balanceador de carga, a identidade gerenciada da carga de trabalho cria automaticamente os recursos necessários para o mTLS, como o certificado do cliente, a configuração de confiança e a configuração de autenticação de back-end.

Para o mTLS de back-end, o recurso de serviço de back-end do balanceador de carga atua como uma carga de trabalho de origem que se autentica no back-end, que é a carga de trabalho de destino.

É possível atribuir uma identidade gerenciada, representada por um ID do SPIFFE, ao serviço de back-end de um balanceador de carga. Google Cloud O Certificate Authority Service provisiona automaticamente um certificado X.509 para o ID do SPIFFE. Esse certificado X.509 para o ID do SPIFFE também é conhecido como um documento de identidade verificável do SPIFFE (SVID, na sigla em inglês). O serviço de back-end do balanceador de carga e os back-ends dele usam os SVIDs para se autenticarem mutuamente com a autenticação mTLS.

O diagrama a seguir mostra o balanceador de carga (carga de trabalho de origem) e o back-end (carga de trabalho de destino) se autenticando mutuamente usando a identidade gerenciada da carga de trabalho.

mTLS de back-end usando identidade de carga de trabalho gerenciada (clique para ampliar).

Confira a seguir um exemplo de um X.509-SVID que serve como um wrapper para o ID SPIFFE. O ID do SPIFFE, representado como um URI, é codificado no nome alternativo do assunto (SAN) de um 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

Esta saída inclui os seguintes valores:

• WORKLOAD_IDENTITY_POOL_ID: o ID do pool de identidade da carga de trabalho
• PROJECT_NUMBER: o número do projetoGoogle Cloud
• NAMESPACE_ID: o ID do namespace
• MANAGED_IDENTITY_ID: o ID da identidade gerenciada

Benefícios de usar a identidade de carga de trabalho gerenciada

Confira alguns dos benefícios de usar a identidade gerenciada da carga de trabalho para mTLS de back-end:

• Segurança reforçada: ao participar de um pool de Identidade da carga de trabalho, um balanceador de carga Google Cloud e os back-ends dele passam a fazer parte de um domínio de confiança. Quando usado em conjunto com o mTLS de back-end, o balanceador de carga e as cargas de trabalho de back-end se autenticam mutuamente. Essa autenticação mútua impede que cargas de trabalho não autorizadas acessem seus serviços e criptografa dados em trânsito.

• Gerenciamento automatizado de certificados: após a atestação bem-sucedida da carga de trabalho, o Google Cloud provisiona e alterna automaticamente os certificados X.509 para cargas de trabalho que participam do domínio de confiança do pool de identidades da carga de trabalho. Esse gerenciamento automático de certificados X.509 elimina o processo complexo e propenso a erros do gerenciamento manual de certificados.

• Identidade interoperável: os pools de identidades de carga de trabalho usam o framework SPIFFE, um padrão para gerenciar identidades em sistemas distribuídos, permitindo autenticação e autorização em arquiteturas modernas baseadas em microsserviços.

• Governança centralizada: os pools de identidade da carga de trabalho oferecem um ponto central de controle. Os administradores podem definir domínios de confiança e estabelecer políticas de atestado para governar quais cargas de trabalho podem receber um certificado X.509 para a identidade gerenciada.

Requisitos de certificado

Ao configurar certificados, verifique se eles atendem a estes requisitos:

• As ferramentas de criptografia moderna formam a base da autenticação mTLS. Os certificados precisam usar algoritmos RSA ou ECDSA para troca de chaves. Os algoritmos de hash precisam usar SHA-256 ou uma função de hash criptográfico mais forte. Algoritmos de hash, como MD4, MD5 e SHA-1, não são compatíveis.

• Os certificados de servidor folha fornecidos pelo back-end têm os seguintes requisitos:

  • A extensão restrições básicas não pode conter CA=true.
  • A extensão uso estendido de chave precisa conter serverAuth.
  • A extensão extended key usage não pode conter os campos codeSigning, timeStamping ou OCSPSigning.
  • O certificado não pode estar vencido.

• Os certificados de cliente folha (balanceador de carga) usados no mTLS de back-end são os certificados de identidade gerenciados pelo Certificate Manager criados automaticamente e atendem aos seguintes requisitos:

  • A extensão restrições básicas não pode conter CA=true.
  • A extensão uso estendido de chave precisa conter clientAuth.
  • A extensão extended key usage não pode conter os campos codeSigning, timeStamping ou OCSPSigning.
  • O certificado não pode estar vencido.

• Para autenticar os certificados de servidor que seu back-end apresenta ao balanceador de carga, os certificados raiz e intermediários localizados na configuração de confiança precisam atender aos seguintes requisitos:

  • A extensão restrições básicas precisa conter CA=true.
  • A extensão uso de chave precisa ser definida como keyCertSign.
  • A extensão uso estendido de chave precisa conter o campo serverAuth.
  • O certificado não pode estar vencido.

Arquitetura do mTLS de back-end usando a identidade gerenciada da carga de trabalho

Os componentes a seguir trabalham juntos para alcançar o mTLS de back-end usando a identidade gerenciada da carga de trabalho:

• Serviço de back-end do balanceador de carga (API Compute Engine)
• Domínio de confiança do Identity and Access Management (API Identity and Access Management)
• Pool de autoridades certificadoras (API Certificate Authority Service)
• Configuração de autenticação de back-end (API Network Security)
• Configuração de confiança do Certificate Manager (API Certificate Manager)
• Certificado de identidade gerenciada do Certificate Manager (API Certificate Manager)

O diagrama a seguir mostra uma identidade gerenciada no serviço de back-end do balanceador de carga, que permite que ele se autentique no back-end. No diagrama, as etapas 1 a 3 representam recursos criados explicitamente, enquanto as etapas 4 e 5 representam recursos criados automaticamente.

1. Configure um pool de ACs do Certificate Authority Service para emitir certificados para identidades de cargas de trabalho gerenciadas.
2. Configure um domínio de confiança criando um pool de identidades da carga de trabalho. Esse pool exige um namespace, uma identidade gerenciada, uma política de atestação, um recurso de configuração de emissão de certificado inline e um recurso de configuração de confiança inline.
3. Configure o serviço de back-end do balanceador de carga com a identidade gerenciada.

4. A identidade gerenciada da carga de trabalho cria automaticamente o certificado de identidade gerenciada do Certificate Manager e a configuração de confiança do Certificate Manager.

   O certificado de identidade gerenciada do Certificate Manager é criado com base na configuração de emissão de certificados no pool de identidades da carga de trabalho. A configuração de confiança do Certificate Manager está sincronizada com a configuração de confiança inline do pool de Identidade da carga de trabalho.

5. A identidade gerenciada da carga de trabalho cria automaticamente a configuração de autenticação de back-end.

   A configuração de confiança do Certificate Manager é anexada à configuração de autenticação de back-end. O certificado de identidade gerenciada do Certificate Manager (X.509-SVID) também é anexado à configuração de autenticação de back-end, que é usada para autenticar no back-end.

Para saber mais sobre a configuração do mTLS de back-end usando a identidade gerenciada, consulte Configurar o mTLS de back-end usando a identidade gerenciada da carga de trabalho.

Arquitetura do mTLS de back-end usando a identidade gerenciada da carga de trabalho (clique para ampliar).

Recursos criados durante a mTLS de back-end usando a identidade gerenciada

Conforme mostrado no diagrama de arquitetura anterior, ao atribuir uma identidade gerenciada ao serviço de back-end, não é necessário configurar a autenticação de back-end, a configuração de confiança do Certificate Manager e o certificado do Certificate Manager. Esses recursos são criados automaticamente pela identidade de carga de trabalho gerenciada.

Esta seção analisa mais de perto as diferentes partes do processo de configuração da identidade gerenciada, com foco nos recursos criados explicitamente e nos que são criados automaticamente.

Recursos criados explicitamente

Os recursos a seguir precisam ser criados explicitamente ao configurar o mTLS de back-end usando a identidade gerenciada da carga de trabalho.

Pool de autoridades certificadoras

Para configurar identidades de carga de trabalho gerenciadas para o balanceador de carga, primeiro configure uma autoridade certificadora e, opcionalmente, uma ou mais ACs subordinadas. Essa configuração é chamada de hierarquia de CA.

É possível usar pools do serviço de CA para configurar essa hierarquia.

O pool de identidade da carga de trabalho é vinculado ao pool de AC atualizando o pool de identidade da carga de trabalho com a configuração de emissão de certificado inline.

Pool de identidade da carga de trabalho

As identidades de carga de trabalho gerenciadas são definidas em um pool de Identidade da carga de trabalho, que serve como um domínio de confiança.

O domínio de confiança representa um limite de segurança lógico em que as cargas de trabalho podem se autenticar e se autorizar usando os IDs do SPIFFE. Todas as cargas de trabalho no mesmo domínio de confiança compartilham uma raiz de confiança comum, o que permite que as cargas de trabalho verifiquem as identidades umas das outras.

Para usar identidades gerenciadas, configure o pool de Identidade da carga de trabalho no modo TRUST_DOMAIN. Todas as identidades em um pool consistem em um namespace único e um identificador de carga de trabalho individual.

Namespace

Em um pool de Identidade da carga de trabalho, as identidades de cargas de trabalho gerenciadas são organizadas em limites administrativos chamados namespaces. Eles ajudam a organizar e conceder acesso às identidades de carga de trabalho relacionadas.

Identidade da carga de trabalho gerenciada

A identidade gerenciada da carga de trabalho é baseada no padrão SPIFFE, que fornece um framework para identificar, autenticar e proteger as comunicações entre cargas de trabalho usando um ID SPIFFE exclusivo.

Uma identidade da carga de trabalho gerenciada ou uma identidade gerenciada é um identificador de carga de trabalho configurado em um pool de identidades da carga de trabalho. Ela é anexada a um recursoGoogle Cloud . Cada identidade gerenciada é identificada de maneira exclusiva por um namespace e um identificador de carga de trabalho individual.

No contexto da conquista do mTLS de back-end, a identidade gerenciada é anexada ao recurso de serviço de back-end do balanceador de carga.

O valor de uma identidade gerenciada é um ID SPIFFE totalmente especificado que precisa obedecer ao seguinte formato:

spiffe://TRUST_DOMAIN_NAME/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID

Um TRUST_DOMAIN_NAME é expandido da seguinte maneira:

WORKLOAD_IDENTITY_POOL_ID.global.PROJECT_NUMBER.workload.id.goog

Para juntar tudo, as cargas de trabalho do Compute Engine, como o recurso de serviço de back-end de um balanceador de carga, podem ter uma identidade gerenciada da seguinte maneira:

spiffe://WORKLOAD_IDENTITY_POOL_ID.global.PROJECT_NUMBER.workload.id.goog/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID

Observação: o prefixo spiffe não é usado no campo identity do serviço de back-end (backendService.tlsSettings.identity). No entanto, o prefixo spiffe é usado quando representado como um URI no nome alternativo do sujeito (SAN, na sigla em inglês) de um certificado X.509.

Política de atestado

Uma política de atestado contém regras para o Google Cloud IAM verificar se o serviço de back-end está qualificado para receber um certificado X.509 para a identidade gerenciada.

Se a verificação da política de atestado for aprovada, o IAM vai solicitar um certificado X.509 para a identidade gerenciada do Certificate Authority Service. O certificado X.509 é criado no pool de ACs vinculado à identidade gerenciada. O serviço de CA provisiona o certificado por reflexão de identidade, em que o ID SPIFFE configurado é refletido em um certificado X.509.

Configuração inline de emissão de certificados

Ao configurar um pool de identidade da carga de trabalho, você configura uma configuração de emissão de certificado inline. Essa configuração especifica qual pool de AC da sua instância do Certificate Authority Service é usado para gerar certificados X.509 para as identidades no pool de identidade da carga de trabalho. O arquivo de configuração também especifica o tempo de vida, a porcentagem da janela de rotação e o algoritmo de chave do certificado.

O pool de AC emite certificados X.509 para identidades de carga de trabalho gerenciadas depois que a aplicação da política de atestado é concluída.

Configuração de confiança inline do pool de identidade da carga de trabalho

Por padrão, as cargas de trabalho no mesmo domínio de confiança podem se autenticar mutuamente usando identidades de carga de trabalho gerenciadas. Se você quiser que cargas de trabalho em domínios de confiança diferentes se autentiquem mutuamente, declare explicitamente a relação de confiança no pool de Identidade da carga de trabalho. Para isso, crie uma configuração de confiança inline que reconheça e aceite certificados de outros domínios de confiança. Esses certificados são usados para criar uma cadeia de confiança e verificar a identidade das cargas de trabalho de outros domínios.

A configuração de confiança inline contém um conjunto de âncoras de confiança que a identidade gerenciada da carga de trabalho usa para validar certificados de peering. A configuração de confiança do Certificate Manager encapsula um repositório de confiança SPIFFE, que permanece sincronizado com a configuração de confiança inline do pool de identidade da carga de trabalho.

Como o pool de Identidade da carga de trabalho está vinculado ao pool de CAs, o pool de Identidade da carga de trabalho confia automaticamente nos certificados raiz desse mesmo pool. Não é necessário adicionar as raízes da CA do pool à configuração de confiança inline porque essa confiança já está integrada.

No diagrama a seguir, o balanceador de carga e o back-end fazem parte do mesmo domínio de confiança, compartilhando o mesmo certificado raiz. O certificado raiz é usado para criar uma cadeia de confiança e verificar a identidade das cargas de trabalho no domínio de confiança.

Hierarquia de recursos de identidade gerenciada da carga de trabalho (clique para ampliar).

Serviço de back-end (API Compute Engine)

Para atribuir uma identidade gerenciada ao balanceador de carga, configure o serviço de back-end dele para que o atributo tlsSettings aponte para a nova propriedade identity (backendService.tlsSettings.identity).

Observe as seguintes restrições que se aplicam ao usar o campo identity no serviço de back-end do balanceador de carga:

• Se você definir a propriedade identity, não poderá definir manualmente os seguintes campos no atributo tlsSettings:

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

• O campo identity só pode ser atribuído durante a criação do serviço de back-end.

• O campo identity é imutável. Depois de atribuir um ao serviço de back-end do balanceador de carga, ele não poderá ser atualizado ou excluído.

Recursos criados automaticamente

Depois de definir a propriedade identity (backendService.tlsSettings.identity) no serviço de back-end do balanceador de carga, os seguintes recursos na API Certificate Manager e na API Network Security serão criados automaticamente pela identidade gerenciada da carga de trabalho.

Os recursos criados automaticamente são criados no mesmo projeto que o serviço de back-end e usam as cotas padrão desse projeto.

Configuração de confiança do Certificate Manager (API Certificate Manager)

A configuração de confiança do Certificate Manager é criada automaticamente e não pode ser editada ou excluída diretamente.

A configuração de confiança do Certificate Manager contém um campo chamado spiffeTrustStores. O campo spiffeTrustStores contém o pacote de confiança associado ao domínio de confiança do pool de Identidade da carga de trabalho e outros pacotes de confiança especificados pelo campo additionalTrustBundles na configuração de confiança inline do pool de Identidade da carga de trabalho. Para saber mais, consulte Verificar se a configuração de confiança do Certificate Manager contém o campo spiffeTrustStores.

Para saber mais sobre como o campo spiffeTrustStores na configuração de confiança do Certificate Manager permite a validação de certificados SPIFFE, consulte Etapas de validação de certificado do servidor.

Certificado de identidade gerenciada do Gerenciador de certificados (API Certificate Manager)

O certificado de identidade gerenciada do Certificate Manager é criado automaticamente pela identidade da carga de trabalho gerenciada. O certificado de identidade gerenciada do Certificate Manager é somente leitura e não pode ser editado ou excluído diretamente usando a API Certificate Manager. O certificado de identidade gerenciada do Certificate Manager é baseado na configuração de emissão de certificado inline, que é definida no pool de Identidade da carga de trabalho.

O certificado de identidade gerenciada do Certificate Manager tem uma propriedade managedIdentity, que o identifica como um certificado de identidade gerenciada. O recurso de certificado de identidade gerenciada do Certificate Manager armazena o SVID X.509 no formato codificado em PEM. O X.509-SVID contém o ID do SPIFFE codificado como um URI no campo SAN. Esse ID SPIFFE corresponde à identidade gerenciada no pool de Identidade da carga de trabalho.

O escopo do certificado de identidade gerenciada do Certificate Manager é CLIENT_AUTH, o que indica que ele é usado como um certificado de cliente no mTLS de back-end.

Configuração de autenticação de back-end (API Network Security)

A configuração de autenticação de back-end é criada automaticamente pela identidade da carga de trabalho gerenciada. A configuração de autenticação de back-end é somente leitura e não pode ser editada ou excluída diretamente usando a API Network Security.

A configuração de confiança do Certificate Manager está anexada à configuração de autenticação de back-end.

O certificado de identidade gerenciada do Certificate Manager também é anexado à configuração de autenticação de back-end e usado como um X.509-SVID em solicitações mTLS de back-end entre o balanceador de carga e as cargas de trabalho de destino.

Etapas de validação do certificado do servidor

Ao validar o certificado do servidor durante o mTLS de back-end, o balanceador de carga faz o seguinte:

1. Verifique se o servidor tem a chave privada do certificado.

   O servidor prova a posse da chave privada associada ao certificado que apresenta ao balanceador de carga assinando uma informação com a chave privada e enviando-a ao balanceador de carga como parte da mensagem CertificateVerify. Em seguida, o balanceador de carga verifica essa assinatura usando a chave pública do certificado do servidor. Se a verificação de assinatura falhar, isso indica que o servidor de back-end não tem a chave privada correspondente ao certificado. Nesses casos, o balanceador de carga encerra o handshake de TLS sem registrar erros.

2. Verifique a cadeia de confiança.

   O campo spiffeTrustStores na configuração de confiança do Certificate Manager permite a validação de certificados SPIFFE. O campo spiffeTrustStores na configuração de confiança do Certificate Manager é ativado automaticamente ao usar a identidade gerenciada da carga de trabalho. Com o campo spiffeTrustStores ativado, o campo trustStores permanece vazio.

   O campo spiffeTrustStores é uma estrutura de dados de mapa em que o par de chave-valor é o seguinte:

   • A chave pode ser um domínio de confiança relacionado a um pool de Identidade da carga de trabalho (no formato que termina com .workload.id.goog) ou um domínio de confiança adicional.
   • O value é um objeto TrustStore. Esse objeto contém uma coleção de certificados raiz confiáveis (conhecidos como pacote de confiança) usados para validar certificados SPIFFE desse domínio de confiança específico.

   Essencialmente, esse mapa permite que o balanceador de carga seja configurado com repositórios de confiança de vários domínios de segurança distintos. Quando um back-end apresenta o certificado SPIFFE, o balanceador de carga extrai o ID SPIFFE, identifica o domínio de confiança e usa o mapa spiffeTrustStores para pesquisar o repositório de confiança correto para verificar a cadeia de confiança e validar o certificado.

   As verificações incluem o seguinte:

   • O certificado do servidor do back-end, os certificados intermediários (se fornecidos) e o certificado raiz configurado estão em conformidade com os requisitos de certificado.
   • Para todos os certificados na cadeia de confiança, o campo de assunto no certificado pai corresponde ao campo de emissor no certificado filho. Essa verificação ajuda a garantir que a identidade (assunto) do certificado principal seja a mesma listada como emissor no certificado filho.
   • Para todos os certificados na cadeia de confiança, o identificador de chave de assunto (SKID) do certificado pai corresponde ao identificador de chave de autoridade (AKID) no certificado filho. Essa correspondência confirma que o certificado filho foi emitido pela autoridade raiz correta e que ele é confiável porque a chave pública da raiz está sendo referenciada no AKID para verificar a validade do certificado.
   Observação: os certificados do cliente autoassinados não formam uma cadeia de confiança válida e são sempre rejeitados.

3. Estabeleça uma conexão com o back-end.

   Se a validação do certificado for bem-sucedida, o balanceador de carga vai continuar com a conexão com o back-end.

   No entanto, se a validação do certificado falhar, o balanceador de carga vai encerrar a conexão com o back-end, enviar um código de status HTTP 502 ao cliente e registrar o motivo do encerramento no Cloud Logging. Em caso de erro de validação de certificado, as solicitações de entrada subsequentes acionam o balanceador de carga para reiniciar a conexão de back-end.

   A conexão de back-end também pode falhar se o servidor de back-end recusar a conexão. Com o mTLS de back-end, isso pode acontecer porque o certificado do cliente é considerado inválido. Quando a conexão com o back-end falha, o balanceador de carga responde às solicitações de proxy com um código de status HTTP 502 e registra um motivo de erro genérico no Cloud Logging.

Tratamento de erros e geração de registros

Os balanceadores de carga de aplicativos oferecem recursos detalhados de geração de registros que permitem monitorar a validação de certificados do servidor, identificar possíveis problemas e solucionar problemas de conexão. Esta seção descreve os diferentes tipos de erros que podem ocorrer durante a validação do mTLS e como eles são registrados.

Se a validação do certificado do servidor falhar, a conexão será encerrada e os erros serão registrados no Cloud Logging. Esses erros são descritos na tabela a seguir.

Status do certificado do servidor	Erro registrado
A cadeia de certificados do servidor é muito longa (mais de 10 certificados intermediários incluídos no certificado do servidor).	server_cert_chain_exceeded_limit
Um servidor ou um certificado intermediário tem um tamanho da chave RSA inválido. Nenhuma validação é executada. As chaves RSA podem ter entre 2.048 e 4.096 bits.	server_cert_invalid_rsa_key_size
Um servidor ou um certificado intermediário está usando uma curva elíptica não compatível. Nenhuma validação é executada. As curvas válidas são P-256 e P-384.	server_cert_unsupported_elliptic_curve_key
Um servidor ou certificado intermediário está usando um algoritmo não RSA ou não ECDSA. Nenhuma validação é executada.	server_cert_unsupported_key_algorithm
A ICP a ser usada para validação tem mais de dez certificados intermediários que compartilham as mesmas informações sobre o sujeito e sobre a chave pública do sujeito. Nenhuma validação é executada.	server_cert_pki_too_large
Um certificado intermediário fornecido para validação tinha mais de 10 restrições de nome.	server_cert_chain_max_name_constraints_exceeded
O certificado do servidor tem um campo de extensão Extended Key Usage (EKU) que não inclui serverAuth.	server_cert_chain_invalid_eku
O limite de tempo é excedido ao tentar validar a cadeia de certificados.	server_cert_validation_timed_out
O limite de profundidade ou de iteração é alcançado na tentativa de validação da cadeia de certificados. A profundidade máxima de uma cadeia de certificados é dez, incluindo os certificados raiz e do servidor. O número máximo de iterações é 100 (certificados examinados para validar a cadeia de certificados do servidor).	server_cert_validation_search_limit_exceeded
O mTLS foi configurado sem a configuração de um recurso TrustConfig.	server_cert_validation_not_performed
O servidor não forneceu o certificado solicitado durante o handshake.	server_cert_not_provided
A verificação do certificado do servidor falhou com o recurso TrustConfig.	ssl_certificate_verification_failed
O serviço não pode realizar a validação da cadeia de certificados.	server_cert_validation_unavailable
Erro interno ao validar a cadeia de certificados.	server_cert_validation_internal_error
TrustConfig não encontrado.	server_cert_trust_config_not_found
O payload do certificado do servidor (incluindo certificados intermediários) é muito grande (mais de 16 KB).	server_cert_exceeded_size_limit

Limitações

• O mTLS de back-end com identidade gerenciada da carga de trabalho só pode ser configurado para balanceadores de carga de aplicativo externos globais. Os balanceadores de carga de aplicativo clássicos não são compatíveis com mTLS de back-end.

• O mTLS de back-end não é compatível com back-ends de NEG global da Internet.

• Se você atribuir uma identidade gerenciada ao serviço de back-end (backendService.tlsSettings.identity), não será possível definir manualmente os seguintes campos na propriedade tlsSettings do serviço de back-end:

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

• A identidade gerenciada só pode ser atribuída no momento da criação do serviço de back-end.

• A identidade gerenciada é imutável. Depois de atribuir uma identidade gerenciada ao serviço de back-end do balanceador de carga, não é possível atualizar ou excluir essa identidade.

A seguir

• Configurar o mTLS de back-end usando a identidade da carga de trabalho gerenciada