Gegenseitiges TLS für regionalen externen Application Load Balancer einrichten

Auf dieser Seite werden Beispiele für die Konfiguration von gegenseitigem TLS (mTLS) für einen regionalen externen Anwendungs-Load-Balancer gezeigt.

Hinweise

mTLS für den Load Balancer einrichten

Damit die gegenseitige TLS-Authentifizierung funktioniert, müssen Sie nach dem Einrichten eines Load-Balancers den Ziel-HTTPS-Proxy mithilfe der Ressource ServerTLSPolicy aktualisieren.

  1. Prüfen Sie, ob Sie die Ressource ServerTLSPolicy bereits erstellt haben. Eine Anleitung finden Sie unter Netzwerksicherheitsressourcen erstellen.

  2. Verwenden Sie den Befehl gcloud compute target-https-proxies list, um alle Ziel-HTTPS-Proxys in Ihrem Projekt aufzulisten:

    gcloud compute target-https-proxies list

    Notieren Sie sich den Namen des HTTPS-Ziel-Proxys, um die ServerTLSPolicy-Ressource anzuhängen. Dieser Name wird in den folgenden Schritten als TARGET_HTTPS_PROXY_NAME bezeichnet.

  3. Verwenden Sie den Befehl gcloud beta compute target-https-proxies export, um die Konfiguration eines Ziel-HTTPS-Proxys in eine Datei zu exportieren:

    regional

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

    Ersetzen Sie Folgendes:

    • TARGET_HTTPS_PROXY_NAME: der Name des Zielproxys.
    • TARGET_PROXY_FILENAME: der Name einer YAML-Datei. z. B. mtls_target_proxy.yaml.
    • REGION: die Region, in der Sie den Load Balancer konfiguriert haben.

  4. Listet alle ServerTlsPolicies-Ressourcen am angegebenen Speicherort des aktuellen Projekts auf.

    Console

    1. Rufen Sie in der Google Cloud Console die Seite Clientauthentifizierung auf.

      Zu „Clientauthentifizierung“

    2. Es werden alle ServerTlsPolicies-Ressourcen angezeigt.

    gcloud

    Verwenden Sie den Befehl gcloud network-security server-tls-policies list, um alle Ressourcen der Clientauthentifizierung (ServerTlsPolicies) aufzulisten:

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

    Ersetzen Sie Folgendes:

    REGION: die Region, in der Sie den Load Balancer konfiguriert haben. Verwenden Sie für regionenübergreifende interne Application Load Balancer global.

    Notieren Sie sich den Namen der ServerTlsPolicies-Ressource, um mTLS zu konfigurieren. Dieser Name wird im nächsten Schritt als SERVER_TLS_POLICY_NAME bezeichnet.

  5. Um die ServerTlsPolicy-Ressourcendatei TARGET_PROXY_FILENAME anzuhängen, verwenden Sie den folgenden Befehl. Ersetzen Sie PROJECT_ID durch die ID Ihres Google Cloud-Projekts.

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

  6. Verwenden Sie den Befehl gcloud beta compute target-https-proxies import, um die Konfiguration eines Ziel-HTTPS-Proxys aus einer Datei zu importieren.

    regional

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

    Ersetzen Sie Folgendes:

    • TARGET_HTTPS_PROXY_NAME: der Name des Zielproxys.
    • TARGET_PROXY_FILENAME: der Name einer YAML-Datei. z. B. mtls_target_proxy.yaml.
    • REGION: die Region, in der Sie den Load Balancer konfiguriert haben.

Benutzerdefinierte mTLS-Header hinzufügen

Wenn mTLS aktiviert ist, können Sie benutzerdefinierte Header verwenden, um Informationen über die mTLS-Verbindung an die URL-Zuordnung zu übergeben. Sie können auch das Logging aktivieren, damit mTLS-Verbindungsfehler in den Logs erfasst werden.

Verwenden Sie den Befehl gcloud beta compute url-maps list, um alle URL-Zuordnungen im Projekt aufzulisten:

   gcloud beta compute url-maps list

Notieren Sie sich den Namen der URL-Zuordnung, um benutzerdefinierte Header und Logging zu aktivieren. Dieser Name wird im folgenden Schritt als URL_MAP_NAME bezeichnet.

regional

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

Im Folgenden finden Sie eine YAML-Beispieldatei, die zeigt, wie Variablen in benutzerdefinierten Anfrageheadern (requestHeadersToAdd) verwendet werden. Sie können dieselben Variablen verwenden, um benutzerdefinierte Antwortheader (responseHeadersToAdd) zu senden.

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

Nächste Schritte