Configure o mTLS de front-end com uma AC privada

Um certificado de cliente válido tem de apresentar uma cadeia de fidedignidade que remeta para a âncora de fidedignidade no repositório fidedigno. Esta página fornece instruções para criar a sua própria cadeia de confiança através do certificado de raiz de uma AC (autoridade de certificação) privada, que está sob o seu controlo. Nesta configuração, a AC privada é criada através do serviço de autoridade de certificação.

Depois de obter o certificado de raiz da AC privada, este documento descreve o processo de carregamento do certificado para a loja fidedigna do recurso TrustConfig do Gestor de certificados. Segue-se a associação da configuração de confiança ao recurso de autenticação do cliente (ServerTLSPolicy) e, em seguida, a anexação do recurso de autenticação do cliente ao recurso de proxy HTTPS de destino do balanceador de carga.

Antes de começar

• Reveja a vista geral do TLS mútuo.
• Reveja o guia para gerir configurações de confiança.

• Instale a CLI do Google Cloud. Para uma vista geral completa da ferramenta, consulte a vista geral da CLI gcloud. Pode encontrar comandos relacionados com o equilíbrio de carga na referência da API e da CLI gcloud.

  Se não tiver executado a CLI gcloud anteriormente, execute primeiro o comando gcloud init para fazer a autenticação.

• Reveja o guia para criar um conjunto de ACs.

• Se estiver a usar o balanceador de carga de aplicações externo global ou o balanceador de carga de aplicações clássico, certifique-se de que configurou um balanceador de carga com qualquer um dos seguintes back-ends suportados:

  • Back-ends do grupo de instâncias de VM
  • Contentores do Cloud Storage (Suportados apenas se existir, pelo menos, um serviço de back-end também associado ao balanceador de carga, além do contentor de back-end)
  • Cloud Run, App Engine ou funções do Cloud Run
  • Conetividade híbrida

• Se estiver a usar um Application Load Balancer externo regional, um Application Load Balancer interno entre regiões ou um Application Load Balancer interno regional, certifique-se de que configurou um balanceador de carga com qualquer um dos seguintes back-ends suportados:

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

Autorizações

Para receber as autorizações de que precisa para concluir este guia, peça ao seu administrador para lhe conceder as seguintes funções da IAM no projeto:

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

Para mais informações sobre a atribuição de funções, consulte o artigo Faça a gestão do acesso a projetos, pastas e organizações.

Também pode conseguir as autorizações necessárias através de funções personalizadas ou outras funções predefinidas.

Nota: as funções básicas da IAM também podem conter autorizações para concluir este guia. Não deve conceder funções básicas num ambiente de produção, mas pode concedê-las num ambiente de desenvolvimento ou de teste.

Obtenha o certificado da CA de raiz

A CA de raiz tem um certificado autoassinado que tem de adicionar ao repositório de confiança. O certificado da CA de raiz está na parte superior da cadeia de certificados.

Para obter o certificado da AC raiz, primeiro tem de criar um conjunto de ACs, que está vazio no momento da criação. Em seguida, tem de criar uma CA de raiz e adicioná-la ao conjunto de CAs. A CA de raiz e o conjunto de CAs são criados através do Certificate Authority Service, conforme descrito nos passos seguintes.

1. Para criar um conjunto de ACs, use o comando gcloud privateca pools create:

   gcloud privateca pools create CA_POOL \
      --location=us-central1
   

   Substitua CA_POOL pelo ID ou nome do conjunto de AC principal.

2. Para criar uma CA de raiz e adicioná-la ao conjunto de CAs, use o comando gcloud privateca roots create:

   gcloud privateca roots create CA_ROOT \
      --pool=CA_POOL \
      --subject="CN=my-ca, O=Test LLC" \
      --location=us-central1
   

   Substitua o seguinte:

   • CA_ROOT: o ID ou o nome da AC raiz.
   • CA_POOL: o ID ou o nome do conjunto de CA principal.

3. Extraia o certificado com codificação PEM que identifica a CA de raiz.

   gcloud privateca roots describe CA_ROOT \
      --pool=CA_POOL \
      --location=us-central1 \
      --format='value(pemCaCertificates)' > root.cert
   

   Substitua o seguinte:

   • CA_ROOT: o ID ou o nome da AC privada.
   • CA_POOL: o ID ou o nome do conjunto de CA principal.

   O certificado de raiz (root.cert) tem de ser carregado na loja fidedigna. Este passo vai ser realizado na secção seguinte.

Para mais informações sobre a utilização do Certificate Authority Service para criar um conjunto de ACs e uma AC de raiz, consulte o seguinte:

• Crie um grupo de ACs
• Crie uma AC de raiz

Formate o certificado da AC de raiz

Para incluir o certificado de raiz num armazenamento fidedigno, formate o certificado numa única linha e armazene-o numa variável de ambiente, para que possa ser referenciado pelo ficheiro YAML de configuração fidedigna.

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

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

Uma configuração de confiança é um recurso que representa a configuração da sua infraestrutura de chave pública (PKI) no Certificate Manager.

Para criar um recurso de configuração de confiança, conclua os seguintes passos:

Consola

1. Na Google Cloud consola, aceda à página Gestor de certificados.

   Aceda ao Gestor de certificados

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

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

4. Para Localização, selecione Global ou Regional.

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

   Se selecionou Regional, selecione a região.

5. Na secção Armazenamento fidedigno, clique em Adicionar âncora fidedigna e carregue o ficheiro de certificado com codificação PEM ou copie o conteúdo do certificado.

6. Clique em Adicionar.

7. Clique em Criar.

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

gcloud

1. Crie um ficheiro YAML de configuração de confiança (trust_config.yaml) que especifique os parâmetros de configuração de confiança. Neste exemplo, o recurso de configuração de fidedignidade é um repositório de fidedignidade com uma única âncora de fidedignidade que representa um certificado de raiz. Este certificado de raiz é gerado através da AC privada.

   cat << EOF > trust_config.yaml
   name: TRUST_CONFIG_NAME
   trustStores:
   - trustAnchors:
       - pemCertificate: "${ROOT?}"
   EOF
   

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

   Global

   Para balanceadores de carga de aplicações externos globais, balanceadores de carga de aplicações clássicos e balanceadores de carga de aplicações internos entre regiões, especifique global como a localização onde o recurso de configuração de fidedignidade está armazenado.

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

   Substitua o seguinte:

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

   regional

   Para balanceadores de carga de aplicações externos regionais e balanceadores de carga de aplicações internos regionais, especifique a região onde 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 o seguinte:

   • TRUST_CONFIG_NAME: o nome do recurso de configuração de confiança.
   • LOCATION: a região onde o recurso de configuração de confiança está armazenado. A localização predefinida é global.

Crie um recurso de autenticação de cliente

Um recurso de autenticação do cliente (também denominado ServerTLSPolicy) permite-lhe especificar o modo TLS do lado do servidor e o recurso de configuração fidedigna a usar quando valida certificados de cliente. Quando o cliente apresenta um certificado inválido ou nenhum certificado ao equilibrador de carga, o clientValidationMode especifica como a ligação do cliente é processada. Para mais informações, consulte os modos de validação do cliente mTLS.

• Quando o clientValidationMode está definido como ALLOW_INVALID_OR_MISSING_CLIENT_CERT, todos os pedidos são transmitidos ao back-end, mesmo que a validação falhe ou o certificado do cliente esteja em falta.
• Quando clientValidationMode está definido como REJECT_INVALID, apenas os pedidos que fornecem um certificado de cliente que pode ser validado em relação a um recurso TrustConfig são transmitidos ao back-end.

Para criar um recurso de autenticação de cliente (ServerTlsPolicy), conclua os seguintes passos:

Consola

1. Na Google Cloud consola, aceda à página Configuração de autenticação.

   Aceda à configuração de autenticação

2. No separador Autenticação de cliente, clique em Criar.

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

4. Para Localização, selecione Global ou Regional.

   Para balanceadores de carga de aplicações externos globais, balanceadores de carga de aplicações clássicos e balanceadores de carga de aplicações internos entre regiões, defina a localização como global. Para balanceadores de carga de aplicações externos regionais e balanceadores de carga de aplicações internos regionais, defina a localização para a região onde o balanceador de carga está configurado.

5. Para o Modo de autenticação de cliente, selecione Equilíbrio de carga.

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

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

8. Clique em Criar.

Verifique se a autenticação de cliente (ServerTlsPolicy) é apresentada.

gcloud

1. Com base na forma como quer processar a ligação, selecione uma das seguintes opções para definir o recurso de autenticação de cliente (ServerTlsPolicy) no formato YAML.

   • Opção 1: a definição de clientValidationMode é ALLOW_INVALID_OR_MISSING_CLIENT_CERT.

     Global

     Para balanceadores de carga de aplicações externos globais, balanceadores de carga de aplicações clássicos e balanceadores de carga de aplicações internos entre regiões, crie um ficheiro YAML que especifique declarativamente o modo de validação do cliente e um recurso de configuração fidedigna 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 aplicações externos regionais e balanceadores de carga de aplicações internos regionais, crie um ficheiro YAML que especifique declarativamente o modo de validação do cliente e um recurso de configuração de fidedignidade 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 aplicações externos globais, balanceadores de carga de aplicações clássicos e balanceadores de carga de aplicações internos entre regiões, crie um ficheiro YAML que especifique declarativamente o modo de validação do cliente e um recurso de configuração fidedigna 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 aplicações externos regionais e balanceadores de carga de aplicações internos regionais, crie um ficheiro YAML que especifique declarativamente o modo de validação do cliente e um recurso de configuração de fidedignidade 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 o seguinte:

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

     PROJECT_ID: o ID do seu projeto Google Cloud .

     LOCATION: para balanceadores de carga de aplicações externos globais, balanceadores de carga de aplicações clássicos e balanceadores de carga de aplicações internos entre regiões, use global. Para o Application Load Balancer externo regional ou o Application Load Balancer interno regional, use a região onde configurou o balanceador de carga.

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

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

   Global

   Para balanceadores de carga de aplicações externos globais, balanceadores de carga de aplicações clássicos e balanceadores de carga de aplicações 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 o seguinte:

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

   regional

   Para balanceadores de carga de aplicações externos regionais e balanceadores de carga de aplicações internos regionais, defina a flag --location para a região onde 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 o seguinte:

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

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

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

   Substitua o seguinte:

   LOCATION: para balanceadores de carga de aplicações externos globais, balanceadores de carga de aplicações clássicos e balanceadores de carga de aplicações internos entre regiões, use global. Para o balanceador de carga de aplicações externo regional ou o balanceador de carga de aplicações interno regional, use a região onde configurou o balanceador de carga.

Nota: para modificar o recurso de autenticação do cliente (ServerTlsPolicy), tem de eliminar primeiro o recurso de autenticação do cliente existente e, em seguida, criar um novo recurso de autenticação do cliente. Em seguida, pode anexar o recurso de autenticação do cliente ao proxy HTTPS de destino do balanceador de carga.

Anexe o recurso de autenticação de cliente ao balanceador de carga

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

Consola

1. Na Google Cloud consola, aceda à página Equilíbrio de carga.

   Aceda a Balanceamento de carga

2. Na lista de balanceadores de carga, selecione o balanceador de carga ao qual tem de anexar o recurso de autenticação de clientes (ServerTLSPolicy).

3. Clique em Editar.

4. Na secção Configuração do front-end para um front-end HTTPS, expanda a secção Mostrar funcionalidades avançadas.

5. Na lista Client Authentication (Autenticação de cliente), selecione o recurso Client Authentication.

6. Clique em Concluído.

7. Clique em Atualizar.

gcloud

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

   gcloud compute target-https-proxies list
   

   Tenha em atenção o nome do proxy HTTPS de destino ao qual anexar o recurso ServerTLSPolicy. Este nome é denominado TARGET_HTTPS_PROXY_NAME nos passos seguintes.

2. Para exportar a configuração de um proxy HTTPS de destino para um ficheiro, 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 o seguinte:

   • TARGET_HTTPS_PROXY_NAME: o nome do proxy de destino.
   • TARGET_PROXY_FILENAME: o nome do ficheiro de configuração do proxy de destino no 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 o seguinte:

   • TARGET_HTTPS_PROXY_NAME: o nome do proxy de destino.
   • TARGET_PROXY_FILENAME: o nome do ficheiro de configuração do proxy de destino no formato YAML. Por exemplo, mtls_target_proxy.yaml
   • REGION: a região onde configurou o balanceador de carga.

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

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

   Substitua o seguinte:

   LOCATION: para o balanceador de carga de aplicações interno entre regiões, o balanceador de carga de aplicações externo global ou o balanceador de carga de aplicações clássico, use global. Para o Application Load Balancer externo regional ou o Application Load Balancer interno regional, use a região onde configurou o balanceador de carga.

   Tenha em atenção o nome do recurso de autenticação de cliente (ServerTLSPolicy) para configurar o mTLS. Este nome é designado como SERVER_TLS_POLICY_NAME no passo seguinte.

4. Anexe a autenticação de 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 o seguinte:

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

5. Para importar a configuração de um proxy HTTPS de destino a partir de um ficheiro, 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 o seguinte:

   • TARGET_HTTPS_PROXY_NAME: o nome do proxy de destino.
   • TARGET_PROXY_FILENAME: o nome do ficheiro de configuração do proxy de destino no 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 o seguinte:

   • TARGET_HTTPS_PROXY_NAME: o nome do proxy de destino.
   • TARGET_PROXY_FILENAME: o nome do ficheiro de configuração do proxy de destino no formato YAML. Por exemplo, mtls_target_proxy.yaml
   • REGION: a região onde configurou o balanceador de carga.

Adicione cabeçalhos personalizados mTLS

Quando ativa o mTLS, pode transmitir informações sobre a ligação mTLS através de cabeçalhos personalizados. Também pode ativar o registo para que as falhas de ligação mTLS sejam capturadas nos registos.

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

Para equilibradores de carga de aplicações externos globais ou equilibradores de carga de aplicações clássicos, pode usar cabeçalhos personalizados para transmitir informações sobre a ligação mTLS a 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
   

   Tenha em atenção o nome do serviço de back-end para ativar os cabeçalhos personalizados e o registo. Este nome é referido como BACKEND_SERVICE no passo seguinte.

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}'
   

Nota:

Pode fornecer os seus próprios nomes de cabeçalhos personalizados. Os nomes usados nas opções --custom-request-header são apenas exemplos.

Pode ativar alguns ou todos os cabeçalhos personalizados de mTLS.

Adicione cabeçalhos personalizados mTLS ao mapa de URLs

Para o balanceador de carga de aplicações interno entre regiões, o balanceador de carga de aplicações externo regional ou o balanceador de carga de aplicações interno regional, pode usar cabeçalhos personalizados para transmitir informações sobre a ligação mTLS para o mapa de URLs.

Para apresentar uma lista de todos os mapas de URLs no projeto, use o comando gcloud compute url-maps list:

   gcloud compute url-maps list
   

Tenha em atenção o nome do mapa de URLs para ativar os cabeçalhos personalizados e o registo. Este nome é denominado URL_MAP_NAME no passo seguinte.

Global

Para editar o mapa de URLs de um Application Load Balancer interno entre regiões, use o comando gcloud compute url-maps edit:

   gcloud compute url-maps edit URL_MAP_NAME --global
   

Segue-se um ficheiro YAML de exemplo que mostra como usar variáveis em cabeçalhos de pedidos personalizados (requestHeadersToAdd). Pode usar as mesmas variáveis para enviar cabeçalhos de respostas 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 URLs de um balanceador de carga de aplicações externo regional ou de um balanceador de carga de aplicações interno regional, use o comando gcloud compute url-maps edit:

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

Segue-se um ficheiro YAML de exemplo que mostra como usar variáveis em cabeçalhos de pedidos personalizados (requestHeadersToAdd). Pode usar as mesmas variáveis para enviar cabeçalhos de respostas 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}"
   

Obtenha um certificado de cliente através de um CSR

Esta secção oferece uma opção de configuração adicional para gerar um certificado de cliente (folha) assinado pelo certificado da AC de raiz.

Para obter um certificado de cliente, gere um pedido de assinatura de certificado (CSR) e envie-o para o conjunto de ACs.

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

   O seguinte ficheiro de configuração (client.config) contém a secção [extension_requirements], que especifica as extensões X.509 a incluir no CSR. Para saber mais acerca dos requisitos dos certificados de cliente, consulte a secção Requisitos de certificados.

   Nota: se a chave for usada num servidor, pode 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
   

2. Execute o seguinte comando openssl para gerar um CSR (csr.pem) e uma chave privada correspondente (key.pem).

   openssl req -newkey rsa:2048 -nodes \
       -config client.config \
       -keyout key.pem \
       -out csr.pem
   

3. Execute o seguinte comando gcloud privateca certificates create para enviar o CSR e pedir o certificado de cliente X.509 à AC no conjunto de ACs.

   gcloud privateca certificates create \
        --issuer-pool CA_POOL \
        --issuer-location=us-central1 \
        --csr csr.pem \
        --cert-output-file CERT_FILENAME
   

   Substitua o seguinte:

   • CA_POOL: o ID ou o nome do conjunto de ACs.
   • CERT_FILENAME: o ficheiro da cadeia de certificados codificado em PEM, ordenado da entidade final à raiz.

4. Envie um pedido HTTPS seguro para o endereço IP do equilibrador de carga através do certificado SSL do lado do cliente. O cliente apresenta o respetivo certificado para se autenticar no equilibrador de carga.

   curl -v --key key.pem --cert CERT_FILENAME https://IP_ADDRESS
   
   

   Substitua o seguinte:

   • CERT_FILENAME: o ficheiro da cadeia de certificados codificado em PEM que é ordenado da entidade final para a raiz.
   • IP_ADDRESS: o endereço IP do balanceador de carga.

O que se segue?

• Configure o TLS mútuo com certificados fornecidos pelo utilizador