Configurar o TLS mútuo para um balanceador de carga de aplicativo externo regional

Nesta página, mostramos exemplos de como configurar o TLS mútuo (mTLS) para um balanceador de carga de aplicativo externo regional.

Antes de começar

Configurar o mTLS para o balanceador de carga

Para que a autenticação TLS mútua funcione, depois de configurar um balanceador de carga, você precisa atualizar o proxy HTTPS de destino usando o recurso ServerTLSPolicy.

  1. Verifique se você já criou o recurso ServerTLSPolicy. Para instruções, consulte Criar os recursos de segurança de rede.

  2. Para listar todos os proxies 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.

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

    regional

     gcloud beta 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 de um arquivo yaml. Por exemplo, mtls_target_proxy.yaml
    • REGION: a região em que você configurou o balanceador de carga.

  4. Liste todos os recursos ServerTlsPolicies no local especificado do projeto atual.

    Console

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

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

    2. Todos os recursos ServerTlsPolicies serão exibidos.

    gcloud

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

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

    Substitua:

    REGION: a região em que você configurou o balanceador de carga. Para balanceadores de carga de aplicativo internos entre regiões, use global.

    Anote o nome do recurso ServerTlsPolicies para configurar o mTLS. Esse nome será chamado de SERVER_TLS_POLICY_NAME na próxima etapa.

  5. Para anexar o arquivo de recurso ServerTlsPolicy TARGET_PROXY_FILENAME, use o comando a seguir. Substitua PROJECT_ID pelo ID do projeto do Google Cloud.

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

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

    regional

       gcloud beta 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 de um arquivo yaml. Por exemplo, mtls_target_proxy.yaml
    • REGION: a região em que você configurou o balanceador de carga.

Adicionar cabeçalhos personalizados mTLS

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

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

   gcloud beta 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.

regional

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

A seguir