Gegenseitiges TLS mit privater CA einrichten

Ein gültiges Clientzertifikat muss eine Vertrauenskette zum Trust Anchor im Trust Store aufweisen. Auf dieser Seite finden Sie eine Anleitung zum Erstellen einer eigenen Vertrauenskette mit dem Stammzertifikat einer privaten Zertifizierungsstelle, die sich in Ihrer Kontrolle befindet. Bei dieser Konfiguration wird die private Zertifizierungsstelle mit dem Certificate Authority Service erstellt.

Nachdem Sie das Root-Zertifikat der privaten Zertifizierungsstelle erhalten haben, wird in diesem Dokument beschrieben, wie Sie das Zertifikat in den Truststore der TrustConfig-Ressource von Zertifikatmanager hochladen. Anschließend wird die Vertrauensstellung mit der Ressource „Client Authentication“ (ServerTLSPolicy) verknüpft und die Ressource „Client Authentication“ an die Ziel-HTTPS-Proxy-Ressource des Load Balancers angehängt.

Hinweise

  • Lesen Sie die Übersicht zu gegenseitigem TLS.
  • Weitere Informationen finden Sie im Leitfaden Vertrauenskonfigurationen verwalten.
  • Installieren Sie die Google Cloud CLI. Eine vollständige Übersicht über das Tool finden Sie im Leitfaden zur gcloud CLI. Befehle für das Load-Balancing finden Sie im Referenzhandbuch für die API und gcloud.

    Wenn Sie die gcloud CLI noch nicht ausgeführt haben, führen Sie zuerst gcloud init zur Authentifizierung aus.

  • Lesen Sie die Anleitung zum Erstellen eines CA-Pools.

  • Wenn Sie einen globalen externen Application Load Balancer oder einen klassischen Application Load Balancer verwenden, müssen Sie einen Load Balancer mit einem der folgenden unterstützten Back-Ends eingerichtet haben:

    • Back-Ends von VM-Instanzgruppen
    • Cloud Storage-Buckets (nur unterstützt, wenn zusätzlich zum Backend-Bucket mindestens ein Backend-Dienst mit dem Load Balancer verknüpft ist)
    • Cloud Run, App Engine oder Cloud Run Functions
    • Hybridkonnektivität
  • Wenn Sie einen regionalen externen Application Load Balancer, einen regionenübergreifenden internen Application Load Balancer oder einen regionalen internen Application Load Balancer verwenden, müssen Sie einen Load Balancer mit einem der folgenden unterstützten Backends einrichten:

    • Back-Ends von VM-Instanzgruppen
    • Cloud Run
    • Hybridkonnektivität

Berechtigungen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für Ihr Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Ausführen dieser Anleitung benötigen:

  • Zum Erstellen von Load-Balancer-Ressourcen wie TargetHTTPProxy: Compute Load Balancer Admin (roles/compute.loadBalancerAdmin)
  • So verwenden Sie Zertifikatmanager-Ressourcen: Zertifikatmanager-Inhaber (roles/certificatemanager.owner)
  • So erstellen Sie Sicherheits- und Netzwerkkomponenten: Compute-Netzwerkadministrator (roles/compute.networkAdmin) und Compute-Sicherheitsadministrator (roles/compute.securityAdmin)
  • Zum Erstellen eines Projekts (optional): Project Creator (roles/resourcemanager.projectCreator)

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

Zertifikat der Root-CA abrufen

Die Stamm-CA hat ein selbst signiertes Zertifikat, das Sie dem Truststore hinzufügen müssen. Das Zertifikat der Stamm-CA steht ganz oben in der Zertifikatskette.

Wenn Sie das Zertifikat der Stammzertifizierungsstelle abrufen möchten, müssen Sie zuerst einen CA-Pool erstellen, der beim Erstellen leer ist. Sie müssen dann eine Root-CA erstellen und dem CA-Pool hinzufügen. Die Stamm-CA und der CA-Pool werden mit dem Certificate Authority Service erstellt, wie in den folgenden Schritten beschrieben.

  1. Verwenden Sie den Befehl gcloud privateca pools create, um einen CA-Pool zu erstellen:

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

    Ersetzen Sie CA_POOL durch die ID oder den Namen des übergeordneten CA-Pools.

  2. Verwenden Sie den Befehl gcloud privateca roots create, um eine Stamm-CA zu erstellen und dem CA-Pool hinzuzufügen:

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

    Ersetzen Sie Folgendes:

    • CA_ROOT: die ID oder der Name der Stammzertifizierungsstelle.
    • CA_POOL: die ID oder der Name des übergeordneten CA-Pools.
  3. Extrahieren Sie das PEM-codierte Zertifikat, das die Stamm-CA identifiziert.

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

    Ersetzen Sie Folgendes:

    • CA_ROOT: die ID oder der Name der privaten Zertifizierungsstelle.
    • CA_POOL: die ID oder der Name des übergeordneten CA-Pools.

    Das Stammzertifikat (root.cert) muss in den Trust Store hochgeladen werden. Dieser Schritt wird im nächsten Abschnitt ausgeführt.

Weitere Informationen zum Erstellen eines CA-Pools und einer Root-CA mit Certificate Authority Service finden Sie unter den folgenden Links:

Zertifikat der Stammzertifizierungsstelle formatieren

Wenn Sie das Stammzertifikat in einen Trust Store aufnehmen möchten, formatieren Sie es in einer einzelnen Zeile und speichern Sie es in einer Umgebungsvariablen, damit es in der YAML-Datei der Trust-Konfiguration referenziert werden kann.

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

TrustConfig-Ressource erstellen

Eine Vertrauenskonfiguration ist eine Ressource, die Ihre Konfiguration der Public-Key-Infrastruktur (PKI) im Zertifikatmanager darstellt.

So erstellen Sie eine Vertrauenskonfiguratierungsressource:

Console

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

    Zum Zertifikatmanager

  2. Klicken Sie auf dem Tab Trust Configs (Vertrauenskonfigurationen) auf Add Trust Config (Vertrauenskonfiguration hinzufügen).

  3. Geben Sie einen Namen für die Konfiguration ein.

  4. Wählen Sie unter Standort die Option Global oder Regional aus.

    Der Speicherort gibt an, wo die Trust-Konfigurationsressource gespeichert ist. Erstellen Sie für globale externe Application Load Balancer, klassische Application Load Balancer und regionenübergreifende interne Application Load Balancer eine globale Trust-Konfigurationsressource. Erstellen Sie für regionale externe Application Load Balancer und regionale interne Application Load Balancer eine regionale Vertrauenskonfigurationsressource.

    Wenn Sie Regional ausgewählt haben, wählen Sie die Region aus.

  5. Klicken Sie im Bereich Trust Store auf Trust Anchor hinzufügen und laden Sie die PEM-codierte Zertifikatsdatei hoch oder kopieren Sie den Inhalt des Zertifikats.

  6. Klicken Sie auf Hinzufügen.

  7. Klicken Sie auf Erstellen.

Prüfen Sie, ob die neue Trust-Konfigurationsressource in der Liste der Konfigurationen angezeigt wird.

gcloud

  1. Erstellen Sie eine YAML-Datei für die Vertrauensstellung (trust_config.yaml), in der die Parameter für die Vertrauensstellung angegeben sind. In diesem Beispiel ist die Trust-Konfigurationsressource ein Trust Store mit einem einzelnen Trust Anchor, der ein Stammzertifikat darstellt. Dieses Root-Zertifikat wird mit der privaten Zertifizierungsstelle generiert.

    cat << EOF > trust_config.yaml
    name: TRUST_CONFIG_NAME
    trustStores:
    - trustAnchors:
        - pemCertificate: "${ROOT?}"
    EOF
    
  2. Verwenden Sie den Befehl gcloud certificate-manager trust-configs import, um die YAML-Datei mit der Vertrauensstellung zu importieren:

    global

    Geben Sie für globale externe Application Load Balancer, klassische Application Load Balancer und regionenübergreifende interne Application Load Balancer global als Speicherort der Trust-Konfigurationsressource an.

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

    Ersetzen Sie Folgendes:

    • TRUST_CONFIG_NAME: der Name der Vertrauenskonfigurationsressource.

    regional

    Geben Sie für regionale externe Application Load Balancer und regionale interne Application Load Balancer die Region an, in der die Trust-Konfigurationsressource gespeichert ist.

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

    Ersetzen Sie Folgendes:

    • TRUST_CONFIG_NAME: der Name der Vertrauenskonfigurationsressource.
    • LOCATION: die Region, in der die Vertrauenskonfigurationsressource gespeichert ist. Der Standardspeicherort ist global.

Clientauthentifizierungsressource erstellen

Mit einer Clientauthentifizierungsressource (auch ServerTLSPolicy genannt) können Sie den serverseitigen TLS-Modus und die Trust-Konfigurationsressource angeben, die bei der Validierung von Clientzertifikaten verwendet werden soll. Wenn der Client dem Load Balancer ein ungültiges oder kein Zertifikat vorlegt, gibt der clientValidationMode an, wie mit der Clientverbindung umgegangen wird. Weitere Informationen finden Sie unter mTLS-Client-Validierungsmodi.

  • Wenn clientValidationMode auf ALLOW_INVALID_OR_MISSING_CLIENT_CERT festgelegt ist, werden alle Anfragen an das Backend übergeben, auch wenn die Validierung fehlschlägt oder das Clientzertifikat fehlt.
  • Wenn clientValidationMode auf REJECT_INVALID festgelegt ist, werden nur Anfragen an das Backend weitergeleitet, die ein Clientzertifikat enthalten, das anhand einer TrustConfig-Ressource validiert werden kann.

So erstellen Sie eine Ressource für die Clientauthentifizierung (ServerTlsPolicy):

Console

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

    Zu „Clientauthentifizierung“

  2. Klicken Sie auf Clientauthentifizierung erstellen.

  3. Geben Sie einen Namen für die Clientauthentifizierungsressource ein.

  4. Wählen Sie unter Standort die Option Global oder Regional aus.

    Legen Sie für globale externe Application Load Balancer, klassische Application Load Balancer und regionenübergreifende interne Application Load Balancer den Standort auf „global“ fest. Legen Sie für regionale externe Application Load Balancer und regionale interne Application Load Balancer die Region fest, in der der Load Balancer konfiguriert ist.

  5. Wählen Sie für den Clientauthentifizierungsmodus die Option Load Balancing aus.

  6. Wählen Sie einen Clientvalidierungsmodus aus.

  7. Wählen Sie die zuvor erstellte Konfigurationsressource für die Vertrauensstellung aus.

  8. Klicken Sie auf Erstellen.

Prüfen Sie, ob die Clientauthentifizierung (ServerTlsPolicy) angezeigt wird.

gcloud

  1. Wählen Sie je nach gewünschter Vorgehensweise eine der folgenden Optionen aus, um die Clientauthentifizierungsressource (ServerTlsPolicy) im YAML-Format zu definieren.

    • Option 1: clientValidationMode ist auf ALLOW_INVALID_OR_MISSING_CLIENT_CERT festgelegt.

      global

      Erstellen Sie für globale externe, klassische und regionenübergreifende interne Application Load Balancer eine YAML-Datei, in der der Client-Validierungsmodus und eine globale Vertrauens-Konfigurationsressource deklarativ angegeben werden:

      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

      Erstellen Sie für regionale externe Application Load Balancer und regionale interne Application Load Balancer eine YAML-Datei, in der der Modus für die Clientüberprüfung und eine regionale Trust-Konfigurationsressource deklarativ angegeben werden:

      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
      
    • Option 2: clientValidationMode ist auf REJECT_INVALID festgelegt.

      global

      Erstellen Sie für globale externe Application Load Balancer, klassische Application Load Balancer und regionenübergreifende interne Application Load Balancer eine YAML-Datei, in der der Client-Validierungsmodus und eine globale Trust-Konfigurationsressource deklarativ angegeben werden:

      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

      Erstellen Sie für regionale externe Application Load Balancer und regionale interne Application Load Balancer eine YAML-Datei, in der der Modus für die Clientüberprüfung und eine regionale Trust-Konfigurationsressource deklarativ angegeben werden:

      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
      

      Ersetzen Sie Folgendes:

      SERVER_TLS_POLICY_NAME: der Name der Ressource „Client Authentication“ (ServerTlsPolicy).

      PROJECT_ID: die ID Ihres Google Cloud -Projekts.

      LOCATION: Verwenden Sie global für globale externe Application Load Balancer, klassische Application Load Balancer und regionenübergreifende interne Application Load Balancer. Verwenden Sie für regionale externe oder regionale interne Application Load Balancer die Region, in der Sie den Load Balancer konfiguriert haben.

      TRUST_CONFIG_NAME: der Name der Vertrauenskonfigurationsressource, die Sie zuvor erstellt haben.

  2. Verwenden Sie den Befehl gcloud network-security server-tls-policies import, um die Ressource „Client Authentication“ (ServerTlsPolicy) zu importieren:

    global

    Legen Sie für globale externe Application Load Balancer, klassische Application Load Balancer und regionenübergreifende interne Application Load Balancer das Flag --location auf global fest.

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

    Ersetzen Sie Folgendes:

    SERVER_TLS_POLICY_NAME: der Name der Ressource „Client Authentication“ (ServerTlsPolicy).

    regional

    Legen Sie für regionale externe Application Load Balancer und regionale interne Application Load Balancer das Flag --location auf die Region fest, in der der Load Balancer konfiguriert ist.

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

    Ersetzen Sie Folgendes:

    SERVER_TLS_POLICY_NAME: der Name der Ressource „Client Authentication“ (ServerTlsPolicy).

  3. Optional: 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=LOCATION
    

    Ersetzen Sie Folgendes:

    LOCATION: Verwenden Sie global für globale externe Application Load Balancer, klassische Application Load Balancer und regionenübergreifende interne Application Load Balancer. Verwenden Sie für regionale externe oder regionale interne Application Load Balancer die Region, in der Sie den Load Balancer konfiguriert haben.

Clientauthentifizierungsressource an den Load Balancer anhängen

Damit die gegenseitige TLS-Authentifizierung funktioniert, müssen Sie nach dem Einrichten des Load Balancers die Ressource „Client Authentication“ (ServerTLSPolicy) an die Ziel-HTTPS-Proxy-Ressource des Load Balancers anhängen.

Console

  1. Rufen Sie in der Google Cloud -Konsole die Seite Load Balancing auf.

    Load-Balancing aufrufen

  2. Wählen Sie in der Liste der Load Balancer den Load Balancer aus, an den Sie die Ressource „Client Authentication“ (ServerTLSPolicy) anhängen möchten.

  3. Klicken Sie auf Bearbeiten.

  4. Maximieren Sie im Bereich Frontend-Konfiguration für ein HTTPS-Frontend den Bereich Erweiterte Funktionen anzeigen.

  5. Wählen Sie in der Liste Client Authentication (Clientauthentifizierung) die Ressource für die Clientauthentifizierung aus.

  6. Klicken Sie auf Fertig.

  7. Klicken Sie auf Aktualisieren.

gcloud

  1. Verwenden Sie den Befehl gcloud compute target-https-proxies list, um alle Ziel-HTTPS-Proxy-Ressourcen 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.

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

    global

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

    Ersetzen Sie Folgendes:

    • TARGET_HTTPS_PROXY_NAME: der Name des Zielproxys.
    • TARGET_PROXY_FILENAME: der Name der Konfigurationsdatei des Zielproxies im YAML-Format. Beispiel: mtls_target_proxy.yaml.

    regional

    gcloud 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 der Konfigurationsdatei des Zielproxies im YAML-Format. z. B. mtls_target_proxy.yaml.
    • REGION: die Region, in der Sie den Load Balancer konfiguriert haben.
  3. Verwenden Sie den Befehl gcloud network-security server-tls-policies list, um alle Ressourcen der Clientauthentifizierung (ServerTlsPolicy) aufzulisten:

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

    Ersetzen Sie Folgendes:

    LOCATION: Verwenden Sie global für den regionenübergreifenden internen Application Load Balancer, den globalen externen Application Load Balancer oder den klassischen Application Load Balancer. Verwenden Sie für regionale externe oder regionale interne Application Load Balancer die Region, in der Sie den Load Balancer konfiguriert haben.

    Notieren Sie sich den Namen der Clientauthentifizierungsressource (ServerTLSPolicy), um mTLS zu konfigurieren. Dieser Name wird im nächsten Schritt als SERVER_TLS_POLICY_NAME bezeichnet.

  4. Fügen Sie die Clientauthentifizierung (ServerTlsPolicy) dem Ziel-HTTPS-Proxy an.

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

    Ersetzen Sie Folgendes:

    • PROJECT_ID: die ID Ihres Google Cloud -Projekts.
    • LOCATION: Verwenden Sie global für globale externe Application Load Balancer oder klassische Application Load Balancer sowie regionenübergreifende interne Application Load Balancer. Verwenden Sie für regionale externe oder regionale interne Application Load Balancer die Region, in der Sie den Load Balancer konfiguriert haben.
    • SERVER_TLS_POLICY_NAME: der Name der Ressource „Client Authentication“ (ServerTLSPolicy).
    • TARGET_PROXY_FILENAME: der Name der Konfigurationsdatei des Zielproxies im YAML-Format.
  5. Verwenden Sie den Befehl gcloud compute target-https-proxies import, um die Konfiguration eines Ziel-HTTPS-Proxys aus einer Datei zu importieren.

    global

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

    Ersetzen Sie Folgendes:

    • TARGET_HTTPS_PROXY_NAME: der Name des Zielproxys.
    • TARGET_PROXY_FILENAME: der Name der Konfigurationsdatei des Zielproxies im YAML-Format. Beispiel: mtls_target_proxy.yaml.

    regional

      gcloud 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 der Konfigurationsdatei des Zielproxies im YAML-Format. z. B. mtls_target_proxy.yaml.
    • REGION: die Region, in der Sie den Load Balancer konfiguriert haben.

Benutzerdefinierte mTLS-Header hinzufügen

Wenn Sie mTLS aktivieren, können Sie Informationen über die mTLS-Verbindung mithilfe von benutzerdefinierten Headern übergeben. Sie können auch das Logging aktivieren, damit mTLS-Verbindungsfehler in den Logs erfasst werden.

Backend-Diensten benutzerdefinierte mTLS-Header hinzufügen

Für globale externe Application Load Balancer oder klassische Application Load Balancer können Sie benutzerdefinierte Header verwenden, um Informationen über die mTLS-Verbindung an Backend-Dienste zu übergeben.

  1. Verwenden Sie den Befehl gcloud compute backend-services list, um alle Backend-Dienste im Projekt aufzulisten:

    gcloud compute backend-services list
    

    Notieren Sie sich den Namen des Backend-Dienstes, um benutzerdefinierte Header und Logging zu aktivieren. Dieser Name wird im folgenden Schritt als BACKEND_SERVICE bezeichnet.

  2. Verwenden Sie den Befehl gcloud compute backend-services update, um den Backend-Dienst zu aktualisieren:

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

Benutzerdefinierte mTLS-Header zur URL-Zuordnung hinzufügen

Für den regionenübergreifenden internen Application Load Balancer, den regionalen externen Application Load Balancer oder den regionalen internen Application Load Balancer können Sie benutzerdefinierte Header verwenden, um Informationen zur mTLS-Verbindung zu übergeben an die URL-Zuordnung.

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

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

global

Verwenden Sie den Befehl gcloud compute url-maps edit, um die URL-Zuordnung für einen regionsübergreifenden internen Application Load Balancer zu bearbeiten:

   gcloud compute url-maps edit URL_MAP_NAME --global
   

Im Folgenden finden Sie eine YAML-Beispieldatei, die zeigt, wie Variablen in benutzerdefinierten Anfrageheadern (requestHeadersToAdd) verwendet werden. Sie können dieselben Variablen auch zum Senden benutzerdefinierter Antwortheader (responseHeadersToAdd) verwenden.

   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

Verwenden Sie den Befehl gcloud compute url-maps edit, um die URL-Zuordnung für einen regionalen externen Application Load Balancer oder einen regionalen internen Application Load Balancer zu bearbeiten:

   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 auch zum Senden benutzerdefinierter Antwortheader (responseHeadersToAdd) verwenden.

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

Clientzertifikat mit einer CSR abrufen

Dieser Abschnitt bietet eine zusätzliche Konfigurationsoption zum Generieren eines untergeordneten Clientzertifikats, das vom Zertifikat der Stammzertifizierungsstelle signiert wird.

Wenn Sie ein Clientzertifikat erhalten möchten, generieren Sie eine CSR (Certificate Signing Request) und reichen Sie sie beim CA-Pool ein.

  1. Erstellen Sie eine OpenSSL-Konfigurationsdatei, um den CSR für das Clientzertifikat zu generieren.

    Die folgende Konfigurationsdatei (client.config) enthält den Abschnitt [extension_requirements], in dem die X.509-Erweiterungen angegeben sind, die in die CSR aufgenommen werden sollen. Weitere Informationen zu den Anforderungen an Clientzertifikate finden Sie unter Zertifikatsanforderungen.

    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              = test@example.com
    
    EOF
    
  2. Führen Sie den folgenden openssl-Befehl aus, um eine CSR (csr.pem) und einen entsprechenden privaten Schlüssel (key.pem) zu generieren.

    openssl req -newkey \
        -rsa:2048 \
        -config client.config \
        -keyout key.pem \
        -out csr.pem
    
  3. Führen Sie den folgenden gcloud privateca certificates create-Befehl aus, um den CSR einzureichen und das X.509-Clientzertifikat von der Zertifizierungsstelle im CA-Pool anzufordern.

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

    Ersetzen Sie Folgendes:

    • CA_POOL: die ID oder der Name des CA-Pools.
    • CERT_FILENAME: die PEM-codierte Zertifikatskettendatei, die vom Blatt zum Stamm sortiert ist.
  4. Senden Sie eine sichere HTTPS-Anfrage an die IP-Adresse des Load Balancers mit dem clientseitigen SSL-Zertifikat. Der Client stellt sein Zertifikat zur Authentifizierung beim Load Balancer vor.

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

    Ersetzen Sie Folgendes:

    • CERT_FILENAME: die PEM-codierte Zertifikatskettendatei, die vom Blatt zum Stamm sortiert ist.
    • IP_ADDRESS: die IP-Adresse des Load Balancers.

Nächste Schritte