Configurar TLS mútuo com certificados fornecidos pelo usuário

Um certificado de cliente válido precisa mostrar uma cadeia de confiança de volta à âncora de confiança (certificado raiz) no repositório de confiança. Esta página fornece instruções para criar sua própria cadeia de confiança configurando seus próprios certificados raiz e intermediários usando a biblioteca OpenSSL.

Depois de criar as raízes de confiança, este documento descreve o processo de upload delas para o repositório de confiança do recurso TrustConfig do Gerenciador de certificados. Em seguida, associe a configuração de confiança ao recurso de autenticação do cliente (ServerTLSPolicy) e anexe o recurso de autenticação do cliente ao recurso de proxy HTTPS de destino do balanceador de carga.

Antes de começar

• Leia a Visão geral do TLS mútuo.
• Consulte o guia Gerenciar configurações de confiança.

• Instale a Google Cloud CLI. Para uma visão geral completa da ferramenta, consulte Visão geral da CLI gcloud. Encontre os comandos relacionados ao balanceamento de carga na referência da CLI gcloud e da API.

  Se você não executou a gcloud CLI anteriormente, primeiro execute o comando gcloud init para autenticar.

• Ative as seguintes APIs: API Compute Engine, Certificate Manager, Network Security e Network Services. Para saber mais, consulte Como ativar APIs.

• Se você estiver usando o balanceador de carga de aplicativo externo global ou o balanceador de carga de aplicativo clássico, verifique se configurou um balanceador de carga com um dos seguintes back-ends compatíveis:

  • Back-ends de grupo de instâncias de VM
  • Buckets do Cloud Storage (compatíveis somente se houver pelo menos um serviço de back-end também anexado ao balanceador de carga, além do bucket de back-end)
  • Funções do Cloud Run, App Engine ou Cloud Run functions
  • Conectividade híbrida

• Se você estiver usando o balanceador de carga de aplicativo externo regional, o balanceador de carga de aplicativo interno entre regiões ou o balanceador de carga de aplicativo interno regional, verifique se configurou um balanceador de carga com um dos seguintes back-ends compatíveis:

  • Back-ends de grupo de instâncias de VM
  • Cloud Run
  • Conectividade híbrida

• Definir o projeto.

  gcloud

  gcloud config set project PROJECT_ID
  

Permissões

Para ter as permissões necessárias para concluir este guia, peça ao administrador para conceder a você os papéis do IAM a seguir no projeto:

• Para criar recursos do balanceador de carga, como TargetHTTPSProxy: Administrador do balanceador de carga do Compute (roles/compute.loadBalancerAdmin)
• Para usar os recursos do Gerenciador de certificados: Proprietário do Gerenciador de certificados (roles/certificatemanager.owner)
• Para criar componentes de segurança e rede: Administrador de rede do Compute (roles/compute.networkAdmin) e Administrador de segurança do Compute (roles/compute.securityAdmin)
• Para criar um projeto (opcional): Criador de projetos (roles/resourcemanager.projectCreator)

Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Também é possível conseguir as permissões necessárias por meio de papéis personalizados ou de outros papéis predefinidos.

Observação: os papéis básicos do IAM também podem conter permissões para concluir este guia. Não conceda papéis básicos em um ambiente de produção, mas é possível fazer isso em um ambiente de desenvolvimento ou teste.

Criar os certificados raiz e intermediários

Observação:

Se você já tem certificados para fazer upload para o repositório de confiança, pule esta etapa e vá para Formatar os certificados.

Se você precisar usar um certificado autoassinado, expirado ou inválido ou se os certificados raiz e intermediário estiverem indisponíveis, crie um certificado autoassinado e adicione-o a uma lista de permissões na configuração de confiança.

Esta seção usa a biblioteca OpenSSL para criar o certificado raiz (âncora de confiança) e o certificado intermediário.

Um certificado raiz está no topo da cadeia de certificados. Um certificado intermediário faz parte da cadeia de confiança de volta ao certificado raiz. O certificado intermediário é assinado criptograficamente pelo certificado raiz. Quando o balanceador de carga recebe um certificado do cliente, ele o valida estabelecendo uma cadeia de confiança do certificado do cliente de volta à âncora de confiança configurada.

Use os comandos abaixo para criar os certificados raiz e intermediários. A criação do certificado intermediário é opcional. No entanto, nesta configuração, usamos o certificado intermediário para assinar o certificado do cliente.

1. Crie um arquivo de configuração OpenSSL.

   No exemplo abaixo, o arquivo de configuração (example.cnf) contém a seção [ca_exts], que especifica extensões X.509 que marcam o certificado como adequado para uma AC. Para saber mais sobre os requisitos para certificados raiz e intermediários, consulte Requisitos de certificados.

   cat > example.cnf << EOF
   [req]
   distinguished_name = empty_distinguished_name
   
   [empty_distinguished_name]
   # Kept empty to allow setting via -subj command line arg.
   
   [ca_exts]
   basicConstraints=critical,CA:TRUE
   keyUsage=keyCertSign
   extendedKeyUsage=clientAuth
   
   EOF
   

2. Crie um certificado raiz X.509 autoassinado (root.cert). O certificado raiz é autoassinado com a própria chave privada (root.key).

   openssl req -x509 \
       -new -sha256 -newkey rsa:2048 -nodes \
       -days 3650 -subj '/CN=root' \
       -config example.cnf \
       -extensions ca_exts \
       -keyout root.key -out root.cert
   

3. Crie a solicitação de assinatura de certificado (int.req) para o certificado intermediário.

   openssl req -new \
       -sha256 -newkey rsa:2048 -nodes \
       -subj '/CN=int' \
       -config example.cnf \
       -extensions ca_exts \
       -keyout int.key -out int.req
   

4. Assine a CSR para criar o certificado intermediário X.509 (int.cert). A CSR é assinada usando o certificado raiz.

   openssl x509 -req \
       -CAkey root.key -CA root.cert \
       -set_serial 1 \
       -days 3650 \
       -extfile example.cnf \
       -extensions ca_exts \
       -in int.req -out int.cert
   

Criar um certificado autoassinado que possa ser adicionado a uma lista de permissões

Observação:

Se você já tem certificados para fazer upload para o repositório de confiança, pule esta etapa e vá para Formatar os certificados.

É possível criar um certificado autoassinado e adicioná-lo a uma lista de permissões na configuração de confiança.

Use o comando OpenSSL a seguir para criar um certificado X.509 autoassinado.

   openssl req -x509 \
       -new -sha256 -newkey rsa:2048 -nodes \
       -days 3650 -subj '/CN=localhost' \
       -keyout allowlisted.key -out allowlisted.cert

Esse certificado é adicionado a um campo allowlistedCertificates na configuração de confiança.

Formatar os certificados

Para incluir certificados novos ou atuais em um TrustStore, formate os certificados em uma única linha e armazene-os em variáveis de ambiente para que possam ser referenciados pelo arquivo YAML da configuração de confiança.

export ROOT_CERT=$(cat root.cert | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')

export INTERMEDIATE_CERT=$(cat int.cert | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')

Para incluir certificados novos ou atuais adicionados a uma lista de permissões em uma configuração de confiança, formate os certificados em uma única linha e armazene-os em variáveis de ambiente para que possam ser lidos no arquivo YAML. Para certificados que estão em uma lista de permissões, use o comando abaixo para formatar os certificados em uma única linha e armazená-los na variável de ambiente ALLOWLISTED_CERT.

export ALLOWLISTED_CERT=$(cat allowlisted.cert | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')

Criar um recurso de configuração de confiança

Uma configuração de confiança é um recurso que representa a configuração da infraestrutura de chave pública (ICP) no Gerenciador de certificados.

Para criar um recurso de configuração de confiança, siga estas etapas:

Console

1. No console do Google Cloud, acesse a página Gerenciador de certificados.

   Acessar o Gerenciador de certificados

2. Na guia Configurações de confiança, clique em Adicionar configuração de confiança.

3. Insira um nome para a configuração.

4. Em Local, selecione Global ou Regional.

   O local indica onde o recurso de configuração de confiança é armazenado. Para balanceadores de carga de aplicativo externos globais, balanceadores de carga de aplicativo clássicos e balanceadores de carga de aplicativo internos entre regiões, crie um recurso de configuração de confiança global. Para balanceadores de carga de aplicativo externos regionais e balanceadores de carga de aplicativo internos regionais, crie um recurso de configuração de confiança regional.

   Se você tiver selecionado Regional, escolha a região.

5. Na seção Repositório de confiança, clique em Adicionar âncora de confiança e faça upload do arquivo de certificado codificado em PEM ou copie o conteúdo do certificado.

6. Clique em Adicionar.

7. Na seção Repositório de confiança, clique em Adicionar AC intermediária e faça upload do arquivo de certificado codificado em PEM ou copie o conteúdo do certificado.

   Essa etapa permite adicionar outro nível de confiança entre o certificado raiz e o certificado do servidor.

8. Clique em Adicionar para adicionar a AC intermediária.

9. Opcional: na seção Certificados na lista de permissões, clique em Adicionar certificado e faça upload do arquivo de certificado codificado em PEM ou copie o conteúdo do certificado.

10. Clique em Adicionar para incluir o certificado na lista de permissões.

11. Clique em Criar.

Verifique se o novo recurso de configuração de confiança aparece na lista de configurações.

gcloud

1. Crie um arquivo YAML de configuração de confiança (trust_config.yaml) que especifique os parâmetros de configuração de confiança. Este exemplo de recurso de configuração de confiança contém um repositório de confiança com uma âncora de confiança e um certificado intermediário. Ele lê o conteúdo do certificado das variáveis de ambiente criadas na etapa anterior Formatar os certificados.

   cat << EOF > trust_config.yaml
   trustStores:
   - trustAnchors:
     - pemCertificate: "${ROOT_CERT?}"
     intermediateCas:
     - pemCertificate: "${INTERMEDIATE_CERT?}"
   EOF
   

   Para criar um repositório de confiança com âncoras de confiança ou certificados intermediários adicionais, adicione linhas de pemCertificate na seção apropriada.

2. Opcional: especifique o certificado que é adicionado ao arquivo YAML de configuração de confiança no campo allowlistedCertificates. Não é necessário ter uma loja de certificados de confiança para adicionar um certificado a uma lista de permissões.

   cat << EOF >> trust_config.yaml
   allowlistedCertificates:
   - pemCertificate: "${ALLOWLISTED_CERT?}"
   EOF
   

   Um certificado adicionado a uma lista de permissões representa qualquer certificado que possa ser encapsulado na configuração de confiança para que seja sempre considerado válido. É possível especificar vários certificados em uma lista de permissões usando várias instâncias do campo pemCertificate.

3. Para importar o arquivo YAML de configuração de confiança, use o comando gcloud certificate-manager trust-configs import:

   global

   Para balanceadores de carga de aplicativo externos globais, balanceadores de carga de aplicativo clássicos e balanceadores de carga de aplicativo internos entre regiões, especifique global como o local em que o recurso de configuração de confiança é armazenado.

   gcloud certificate-manager trust-configs import TRUST_CONFIG_NAME  \
       --source=trust_config.yaml \
       --location=global
   

   Substitua:

   • TRUST_CONFIG_NAME: o nome do recurso de configuração de confiança.

   regional

   Para balanceadores de carga de aplicativo externos e internos regionais, especifique a região em que o recurso de configuração de confiança está armazenado.

   gcloud certificate-manager trust-configs import TRUST_CONFIG_NAME  \
       --source=trust_config.yaml \
       --location=LOCATION
   

   Substitua:

   • TRUST_CONFIG_NAME: o nome do recurso de configuração de confiança.
   • LOCATION: a região em que o recurso de configuração de confiança é armazenado. O local padrão é global.

Criar um recurso de autenticação do cliente

Um recurso de autenticação do cliente (também chamado de ServerTLSPolicy) permite especificar o modo TLS do lado do servidor e o recurso de configuração de confiança a ser usado ao validar certificados do cliente. Quando o cliente apresenta um certificado inválido ou nenhum certificado para o balanceador de carga, o clientValidationMode especifica como a conexão do cliente é processada. Para mais informações, consulte Modos de validação do cliente mTLS.

• Quando clientValidationMode é definido como ALLOW_INVALID_OR_MISSING_CLIENT_CERT, todas as solicitações são transmitidas para o back-end, mesmo que a validação falhe ou o certificado do cliente esteja ausente.
• Quando clientValidationMode for definido como REJECT_INVALID, somente as solicitações que fornecerem um certificado de cliente que possa ser validado por um recurso TrustConfig serão transmitidas para o back-end.

Para criar um recurso de autenticação do cliente (ServerTlsPolicy), siga estas etapas:

Console

1. No console do Google Cloud, acesse a página Autenticação do cliente.

   Acesse a página "Autenticação do cliente"

2. Clique em Criar autenticação de cliente.

3. Insira um nome para o recurso de autenticação do cliente.

4. Em Local, selecione Global ou Regional.

   Para balanceadores de carga de aplicativo externos globais, balanceadores de carga de aplicativo clássicos e balanceadores de carga de aplicativo internos entre regiões, defina o local como global. Para balanceadores de carga de aplicativo externos regionais e balanceadores de carga de aplicativo regionais internos, defina o local como a região em que o balanceador de carga está configurado.

5. Em Modo de autenticação do cliente, selecione Balanceamento de carga.

6. Selecione um modo de validação do cliente.

7. Selecione o recurso de configuração de confiança criado anteriormente.

8. Clique em Criar.

Verifique se a autenticação do cliente (ServerTlsPolicy) aparece.

gcloud

1. Com base em como você quer lidar com a conexão, selecione uma das seguintes opções para definir o recurso de autenticação do cliente (ServerTlsPolicy) no formato YAML.

   • Opção 1: clientValidationMode está definido como ALLOW_INVALID_OR_MISSING_CLIENT_CERT.

     global

     Para balanceadores de carga de aplicativo externos globais, balanceadores de carga de aplicativo clássicos e balanceadores de carga de aplicativo internos entre regiões, crie um arquivo YAML que especifique de forma declarativa o modo de validação do cliente e um recurso de configuração de confiança global:

     cat << EOF > server_tls_policy.yaml
     name: SERVER_TLS_POLICY_NAME
     mtlsPolicy:
         clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT
         clientValidationTrustConfig: projects/PROJECT_ID/locations/global/trustConfigs/TRUST_CONFIG_NAME
     EOF
     

     regional

     Para balanceadores de carga de aplicativo externos e internos regionais, crie um arquivo YAML que especifique de forma declarativa o modo de validação do cliente e um recurso de configuração de confiança regional:

     cat << EOF > server_tls_policy.yaml
     name: SERVER_TLS_POLICY_NAME
     mtlsPolicy:
         clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT
         clientValidationTrustConfig: projects/PROJECT_ID/locations/REGION/trustConfigs/TRUST_CONFIG_NAME
     EOF
     

   • Opção 2: clientValidationMode está definido como REJECT_INVALID.

     global

     Para balanceadores de carga de aplicativo externos globais, balanceadores de carga de aplicativo clássicos e balanceadores de carga de aplicativo internos entre regiões, crie um arquivo YAML que especifique de forma declarativa o modo de validação do cliente e um recurso de configuração de confiança global:

     cat << EOF > server_tls_policy.yaml
     name: SERVER_TLS_POLICY_NAME
     mtlsPolicy:
         clientValidationMode: REJECT_INVALID
         clientValidationTrustConfig: projects/PROJECT_ID/locations/global/trustConfigs/TRUST_CONFIG_NAME
     EOF
     

     regional

     Para balanceadores de carga de aplicativo externos e internos regionais, crie um arquivo YAML que especifique de forma declarativa o modo de validação do cliente e um recurso de configuração de confiança regional:

     cat << EOF > server_tls_policy.yaml
     name: SERVER_TLS_POLICY_NAME
     mtlsPolicy:
           clientValidationMode: REJECT_INVALID
           clientValidationTrustConfig: projects/PROJECT_ID/locations/REGION/trustConfigs/TRUST_CONFIG_NAME
     EOF
     

     Substitua:

     SERVER_TLS_POLICY_NAME: o nome do recurso de autenticação do cliente (ServerTlsPolicy).

     PROJECT_ID: o ID do seu projeto do Google Cloud.

     LOCATION: para balanceadores de carga de aplicativo externos globais, balanceadores de carga de aplicativo clássicos e balanceadores de carga de aplicativo internos entre regiões, use global. Para o balanceador de carga de aplicativo externo regional ou o balanceador de carga de aplicativo interno regional, use a região em que você configurou o balanceador de carga

     TRUST_CONFIG_NAME: o nome do recurso de configuração de confiança criado anteriormente.

2. Para importar o recurso ServerTlsPolicy de autenticação do cliente, use o comando gcloud network-security server-tls-policies import:

   global

   Para balanceadores de carga de aplicativo externos globais, balanceadores de carga de aplicativo clássicos e balanceadores de carga de aplicativo internos entre regiões, defina a flag --location como global.

   gcloud network-security server-tls-policies import SERVER_TLS_POLICY_NAME \
     --source=server_tls_policy.yaml \
     --location=global
   

   Substitua:

   SERVER_TLS_POLICY_NAME: o nome do recurso de autenticação do cliente (ServerTlsPolicy).

   regional

   Para balanceadores de carga de aplicativo externos regionais e balanceadores de carga de aplicativo internos regionais, defina a flag --location para a região em que o balanceador de carga está configurado.

   gcloud network-security server-tls-policies import SERVER_TLS_POLICY_NAME \
     --source=server_tls_policy.yaml \
     --location=LOCATION
   

   Substitua:

   SERVER_TLS_POLICY_NAME: o nome do recurso de autenticação do cliente (ServerTlsPolicy).

3. Opcional: para listar todos os recursos de autenticação do cliente (ServerTlsPolicies), use o comando gcloud network-security server-tls-policies list:

   gcloud network-security server-tls-policies list \
     --location=LOCATION
   

   Substitua:

   LOCATION: para balanceadores de carga de aplicativo externos globais, clássicos e internos entre regiões, use global. Para o balanceador de carga de aplicativo externo regional ou o balanceador de carga de aplicativo interno regional, use a região em que você configurou o balanceador de carga.

Observação: para modificar o recurso de autenticação do cliente (ServerTlsPolicy), primeiro é necessário excluir o recurso de autenticação do cliente e criar um novo. Em seguida, anexe o recurso de autenticação do cliente ao proxy HTTPS de destino do balanceador de carga.

Anexar o recurso de autenticação do cliente ao balanceador de carga

Para que a autenticação TLS mútua funcione, depois de configurar o balanceador de carga, você precisa anexar o recurso de autenticação do cliente (ServerTLSPolicy) ao recurso de proxy HTTPS de destino do balanceador de carga.

Console

1. No Console do Google Cloud, acesse a página Balanceamento de carga.

   Acessar o "Balanceamento de carga"

2. Na lista de balanceadores de carga, selecione o balanceador de carga ao qual você precisa anexar o recurso de autenticação do cliente (ServerTLSPolicy).

3. Clique em Editar.

4. Na seção Configuração de front-end de um front-end HTTPS, expanda a seção Mostrar recursos avançados.

5. Na lista Autenticação do cliente, selecione o recurso de autenticação do cliente.

6. Clique em Concluído.

7. Clique em Atualizar.

gcloud

1. Para listar todos os recursos de proxy HTTPS de destino no projeto, use o comando gcloud compute target-https-proxies list:

   gcloud compute target-https-proxies list
   

   Anote o nome do proxy HTTPS de destino para anexar o recurso ServerTLSPolicy. Esse nome é chamado de TARGET_HTTPS_PROXY_NAME nas etapas a seguir.

2. Para exportar a configuração de um proxy HTTPS de destino para um arquivo, use o comando gcloud compute target-https-proxies export.

   global

     gcloud compute target-https-proxies export TARGET_HTTPS_PROXY_NAME \
         --destination=TARGET_PROXY_FILENAME \
         --global
     

   Substitua:

   • TARGET_HTTPS_PROXY_NAME: o nome do proxy de destino.
   • TARGET_PROXY_FILENAME: o nome do arquivo de configuração do proxy de destino em formato YAML. Por exemplo, mtls_target_proxy.yaml.

   regional

   gcloud compute target-https-proxies export TARGET_HTTPS_PROXY_NAME \
       --destination=TARGET_PROXY_FILENAME \
       --region=REGION
   

   Substitua:

   • TARGET_HTTPS_PROXY_NAME: o nome do proxy de destino.
   • TARGET_PROXY_FILENAME: o nome do arquivo de configuração do proxy de destino em formato YAML. Por exemplo, mtls_target_proxy.yaml
   • REGION: a região em que você configurou o balanceador de carga.

3. Para listar todos os recursos de autenticação do cliente (ServerTlsPolicy), use o comando gcloud network-security server-tls-policies list:

   gcloud network-security server-tls-policies list \
       --location=LOCATION
   

   Substitua:

   LOCATION: para o balanceador de carga de aplicativo interno entre regiões, o balanceador de carga de aplicativo externo global ou o balanceador de carga de aplicativo clássico, use global. Para o balanceador de carga de aplicativo externo regional ou o balanceador de carga de aplicativo interno regional, use a região em que você configurou o balanceador de carga.

   Anote o nome do recurso de autenticação do cliente (ServerTLSPolicy) para configurar o mTLS. Esse nome será chamado de SERVER_TLS_POLICY_NAME na próxima etapa.

4. Anexe a autenticação do cliente (ServerTlsPolicy) ao proxy HTTPS de destino.

   echo "serverTlsPolicy: //networksecurity.googleapis.com/projects/PROJECT_ID/locations/LOCATION/serverTlsPolicies/SERVER_TLS_POLICY_NAME" >> TARGET_PROXY_FILENAME

   Substitua:

   • PROJECT_ID: o ID do seu projeto do Google Cloud.
   • LOCATION: para balanceadores de carga de aplicativo externos globais ou clássicos e balanceadores de carga de aplicativo internos entre regiões, use global. Para o balanceador de carga de aplicativo externo regional ou o balanceador de carga de aplicativo interno regional, use a região em que você configurou o balanceador de carga.
   • SERVER_TLS_POLICY_NAME: o nome do recurso de autenticação do cliente (ServerTLSPolicy).
   • TARGET_PROXY_FILENAME: o nome do arquivo de configuração do proxy de destino em formato YAML.

5. Para importar a configuração de um proxy HTTPS de destino de um arquivo, use o comando gcloud compute target-https-proxies import.

   global

     gcloud compute target-https-proxies import TARGET_HTTPS_PROXY_NAME \
         --source=TARGET_PROXY_FILENAME \
         --global
     

   Substitua:

   • TARGET_HTTPS_PROXY_NAME: o nome do proxy de destino.
   • TARGET_PROXY_FILENAME: o nome do arquivo de configuração do proxy de destino em formato YAML. Por exemplo, mtls_target_proxy.yaml.

   regional

     gcloud compute target-https-proxies import TARGET_HTTPS_PROXY_NAME \
         --source=TARGET_PROXY_FILENAME \
         --region=REGION
     

   Substitua:

   • TARGET_HTTPS_PROXY_NAME: o nome do proxy de destino.
   • TARGET_PROXY_FILENAME: o nome do arquivo de configuração do proxy de destino em formato YAML. Por exemplo, mtls_target_proxy.yaml
   • REGION: a região em que você configurou o balanceador de carga.

Adicionar cabeçalhos personalizados mTLS

Ao ativar o mTLS, é possível transmitir informações sobre a conexão mTLS usando cabeçalhos personalizados. Você também pode ativar o registro para que as falhas de conexão do mTLS sejam capturadas nos registros.

Adicionar cabeçalhos personalizados do mTLS aos serviços de back-end

Para balanceadores de carga de aplicativo externos globais ou clássicos, use cabeçalhos personalizados para transmitir informações sobre a conexão do mTLS para os serviços de back-end.

1. Para listar todos os serviços de back-end no projeto, use o comando gcloud compute backend-services list:

   gcloud compute backend-services list
   

   Anote o nome do serviço de back-end para ativar os cabeçalhos e a geração de registros personalizados. Esse nome é chamado de BACKEND_SERVICE na etapa a seguir.

2. Para atualizar o serviço de back-end, use o comando gcloud compute backend-services update:

   gcloud compute backend-services update BACKEND_SERVICE \
     --global \
     --enable-logging \
     --logging-sample-rate=1 \
     --custom-request-header='X-Client-Cert-Present:{client_cert_present}' \
     --custom-request-header='X-Client-Cert-Chain-Verified:{client_cert_chain_verified}' \
     --custom-request-header='X-Client-Cert-Error:{client_cert_error}' \
     --custom-request-header='X-Client-Cert-Hash:{client_cert_sha256_fingerprint}' \
     --custom-request-header='X-Client-Cert-Serial-Number:{client_cert_serial_number}' \
     --custom-request-header='X-Client-Cert-SPIFFE:{client_cert_spiffe_id}' \
     --custom-request-header='X-Client-Cert-URI-SANs:{client_cert_uri_sans}' \
     --custom-request-header='X-Client-Cert-DNSName-SANs:{client_cert_dnsname_sans}' \
     --custom-request-header='X-Client-Cert-Valid-Not-Before:{client_cert_valid_not_before}' \
     --custom-request-header='X-Client-Cert-Valid-Not-After:{client_cert_valid_not_after}'
   

Observação:

É possível colocar seus próprios nomes de cabeçalho personalizados. Os nomes usados nas opções --custom-request-header são apenas exemplos.

É possível ativar alguns ou todos os cabeçalhos personalizados mTLS.

Adicionar cabeçalhos personalizados do mTLS ao mapa de URL

Para balanceadores de carga de aplicativo internos entre regiões, balanceadores de carga de aplicativo externos regionais ou balanceadores de carga de aplicativo internos regionais, é possível usar cabeçalhos personalizados para transmitir informações sobre a conexão do mTLS para o mapa de URL.

Para listar todos os mapas de URL no projeto, use o comando gcloud compute url-maps list:

   gcloud compute url-maps list
   

Anote o nome do mapa de URL para ativar cabeçalhos personalizados e geração de registros. Esse nome é chamado de URL_MAP_NAME na etapa a seguir.

global

Para editar o mapa de URL de um balanceador de carga de aplicativo interno entre regiões, use o comando gcloud compute url-maps edit:

   gcloud compute url-maps edit URL_MAP_NAME --global
   

Veja a seguir um exemplo de arquivo YAML que mostra como usar variáveis em cabeçalhos de solicitações personalizadas (requestHeadersToAdd). É possível usar as mesmas variáveis para enviar cabeçalhos de resposta personalizados (responseHeadersToAdd).

   headerAction:
      requestHeadersToAdd:
      - headerName: "X-Client-Cert-Present"
        headerValue: "{client_cert_present}"
      - headerName: "X-Client-Cert-Chain-Verified"
        headerValue: "{client_cert_chain_verified}"
      - headerName: "X-Client-Cert-Error"
        headerValue: "{client_cert_error}"
      - headerName: "X-Client-Cert-Hash"
        headerValue: "{client_cert_sha256_fingerprint}"
      - headerName: "X-Client-Cert-Serial-Number"
        headerValue: "{client_cert_serial_number}"
      - headerName: "X-Client-Cert-SPIFFE"
        headerValue: "{client_cert_spiffe_id}"
      - headerName: "X-Client-Cert-URI-SANs"
        headerValue: "{client_cert_uri_sans}"
      - headerName: "X-Client-Cert-DNSName-SANs"
        headerValue: "{client_cert_dnsname_sans}"
      - headerName: "X-Client-Cert-Valid-Not-Before"
        headerValue: "{client_cert_valid_not_before}"
      - headerName: "X-Client-Cert-Valid-Not-After"
        headerValue: "{client_cert_valid_not_after}"
      - headerName: "X-Client-Cert-Issuer-Dn"
        headerValue: "{client_cert_issuer_dn}"
      - headerName: "X-Client-Cert-Subject-Dn"
        headerValue: "{client_cert_subject_dn}"
      - headerName: "X-Client-Cert-Leaf"
        headerValue: "{client_cert_leaf}"
      - headerName: "X-Client-Cert-Chain"
        headerValue: "{client_cert_chain}"
   

regional

Para editar o mapa de URL de um balanceador de carga de aplicativo externo regional ou um balanceador de carga de aplicativo interno regional, use o comando gcloud compute url-maps edit:

   gcloud compute url-maps edit URL_MAP_NAME --region=REGION
   

Veja a seguir um exemplo de arquivo YAML que mostra como usar variáveis em cabeçalhos de solicitações personalizadas (requestHeadersToAdd). É possível usar as mesmas variáveis para enviar cabeçalhos de resposta personalizados (responseHeadersToAdd).

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
      name: regional-lb-map
      region: region/REGION
   headerAction:
      requestHeadersToAdd:
      - headerName: "X-Client-Cert-Present"
        headerValue: "{client_cert_present}"
      - headerName: "X-Client-Cert-Chain-Verified"
        headerValue: "{client_cert_chain_verified}"
      - headerName: "X-Client-Cert-Error"
        headerValue: "{client_cert_error}"
      - headerName: "X-Client-Cert-Hash"
        headerValue: "{client_cert_sha256_fingerprint}"
      - headerName: "X-Client-Cert-Serial-Number"
        headerValue: "{client_cert_serial_number}"
      - headerName: "X-Client-Cert-SPIFFE"
        headerValue: "{client_cert_spiffe_id}"
      - headerName: "X-Client-Cert-URI-SANs"
        headerValue: "{client_cert_uri_sans}"
      - headerName: "X-Client-Cert-DNSName-SANs"
        headerValue: "{client_cert_dnsname_sans}"
      - headerName: "X-Client-Cert-Valid-Not-Before"
        headerValue: "{client_cert_valid_not_before}"
      - headerName: "X-Client-Cert-Valid-Not-After"
        headerValue: "{client_cert_valid_not_after}"
      - headerName: "X-Client-Cert-Issuer-Dn"
        headerValue: "{client_cert_issuer_dn}"
      - headerName: "X-Client-Cert-Subject-Dn"
        headerValue: "{client_cert_subject_dn}"
      - headerName: "X-Client-Cert-Leaf"
        headerValue: "{client_cert_leaf}"
      - headerName: "X-Client-Cert-Chain"
        headerValue: "{client_cert_chain}"
   

Assinar o certificado do cliente com o certificado intermediário

Esta seção fornece uma opção de configuração adicional para gerar um certificado de cliente (folha). Se você já criou um recurso TrustConfig que contém um certificado intermediário, faça o seguinte:

1. Crie um arquivo de configuração para gerar o CSR do certificado do cliente.

   O arquivo de configuração a seguir (client.config) contém a seção [extension_requirements], que especifica as extensões X.509 a serem incluídas no CSR. Para saber mais sobre os requisitos de certificados do cliente, consulte Requisitos de certificado.

   Observação: se a chave for usada em um servidor, será possível adicionar serverAuth ao campo extendedKeyUsage.

   cat > client.config << EOF
   [req]
   default_bits              = 2048
   req_extensions            = extension_requirements
   distinguished_name        = dn_requirements
   prompt                    = no
   
   [extension_requirements]
   basicConstraints          = critical, CA:FALSE
   keyUsage                  = critical, nonRepudiation, digitalSignature, keyEncipherment
   extendedKeyUsage          = clientAuth
   
   [dn_requirements]
   countryName               = US
   stateOrProvinceName       = California
   localityName              = San Francisco
   0.organizationName        = example
   organizationalUnitName    = test
   commonName                = test.example.com
   emailAddress              = [e-mail]
   
   EOF
   

   Se você quiser anexar uma identidade SPIFFE ao arquivo de configuração, faça o seguinte:

   • Adicione um campo subjectAltName à seção [extension_requirements] da seguinte forma:

     subjectAltName            = @sans_list
     

   • Adicione uma nova seção ([sans_list]) na parte de baixo do arquivo client.config da seguinte maneira:

     [sans_list]
     URI.1                     = spiffe://example.com/test-identity
     

2. Crie a CSR (client.csr) para o certificado do cliente.

   openssl req -new \
       -config client.config \
       -keyout client.key -out client.csr
   

3. Assine o CSR para emitir o certificado de cliente X.509 (client.cert). O CSR é assinado pelo certificado intermediário.

   openssl x509 -req \
       -CAkey int.key -CA int.cert \
       -days 365 \
       -extfile client.config \
       -extensions extension_requirements \
       -in client.csr -out client.cert
   

4. Envie uma solicitação HTTPS segura para o endereço IP do balanceador de carga usando o certificado SSL do lado do cliente. O cliente apresenta o certificado (client.cert) para se autenticar no balanceador de carga.

   curl -v --key client.key --cert client.cert https://IP_ADDRESS
   

   Substitua IP_ADDRESS pelo endereço IP do balanceador de carga.

A seguir

• Configurar o TLS mútuo com uma CA particular