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

Pré-lançamento

Este recurso está sujeito aos "Termos da Oferta 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 assistência limitada. Para mais informações, consulte as descrições das fases de lançamento.

É possível alcançar o mTLS de back-end com ou sem identidade gerenciada da carga de trabalho. Para saber mais sobre o mTLS de back-end sem a identidade gerenciada da carga de trabalho, consulte Visão geral da autenticação TLS e do mTLS de back-end.

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.

Observação: na prévia, 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
• Framework de identidade de produção segura para todos (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 de carga de trabalho gerenciada, 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 SPIFFE, ao serviço de back-end de um balanceador de carga. OGoogle Cloud serviço de autoridade de certificação 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 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 identidades 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 identidades de 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 comprovaçã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 identidade da 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.

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 Gerenciador de certificados (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 Gerenciador de certificados e a configuração de confiança do Gerenciador de certificados.

   O certificado de identidade gerenciada do Gerenciador de certificados é criado com base na configuração de emissão de certificados no pool de identidades de 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 Gerenciador de certificados é 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 o 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 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 ao atualizar o pool de identidade da carga de trabalho com a configuração de emissão de certificado inline.

Identidade da carga de trabalho gerenciada

É preciso criar uma identidade de carga de trabalho gerenciada no namespace do pool de identidades de carga de trabalho. A identidade gerenciada é um ID SPIFFE totalmente especificado usado no SVID apresentado pela carga de trabalho do balanceador de carga.

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 atribuída a ele.

Se a verificação da política de atestado for aprovada, o IAM vai solicitar um certificado X.509 para a identidade gerenciada do serviço de autoridade de certificação. O certificado X.509 é criado no pool de AC 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 CA 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 gerenciadas de carga de trabalho. 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 identidades de 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 identidades de carga de trabalho está vinculado ao pool de CAs, ele confia automaticamente nos certificados raiz desse mesmo pool de CAs. 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.

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

Para atribuir uma identidade gerenciada ao balanceador de carga, configure o serviço de back-end do balanceador de carga 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 atribuído ao serviço de back-end do balanceador de carga, ele não pode 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 do 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 Gerenciador de certificados 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 identidades da carga de trabalho e outros pacotes de confiança especificados pelo campo additionalTrustBundles na configuração de confiança inline do pool de identidades da carga de trabalho.

Para validar certificados SPIFFE, o campo spiffeTrustStores na configuração de confiança do Certificate Manager é ativado automaticamente ao usar a identidade de carga de trabalho gerenciada. 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 identidades de carga de trabalho (no formato que termina com .workload.id.goog) ou um domínio de confiança adicional.
• O valor é um objeto TrustStore. Esse objeto contém uma coleção de certificados raiz confiáveis (conhecidos como um 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 para confiar em repositórios de vários domínios de segurança distintos. Quando um back-end apresenta o certificado, o balanceador de carga extrai o ID do SPIFFE, identifica o domínio de confiança e usa o mapa para pesquisar o repositório de confiança correto necessário para validar esse certificado.

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

O certificado de identidade gerenciada do Gerenciador de certificados é 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 identidades 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 X.509-SVID 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 identidades de 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 Gerenciador de certificados está anexada à configuração de autenticação de back-end.

O certificado de identidade gerenciada do Gerenciador de certificados 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.

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 o mTLS de back-end.

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

• 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