Frontend-mTLS mit vom Nutzer bereitgestellten Zertifikaten einrichten

Ein gültiges Clientzertifikat muss eine Vertrauenskette zurück zum Trust-Anchor (Root-Zertifikat) im Trust Store aufweisen. Auf dieser Seite finden Sie eine Anleitung zum Erstellen einer eigenen Vertrauenskette. Dazu konfigurieren Sie Ihre eigenen Root- und Zwischenzertifikate mit der OpenSSL-Bibliothek.

Nachdem Sie die Roots of Trust erstellt haben, wird in diesem Dokument beschrieben, wie Sie sie in den Trust Store der Zertifikatmanager-Ressource TrustConfig hochladen. Anschließend wird die Vertrauenskonfiguration mit der Clientauthentifizierungsressource (ServerTLSPolicy) verknüpft und die Clientauthentifizierungsressource an die Ziel-HTTPS-Proxy-Ressource des Load Balancers angehängt.

Hinweis

  • Lesen Sie die Übersicht zu gegenseitigem TLS.
  • Lesen Sie den Leitfaden zum Verwalten von Vertrauenskonfigurationen.

  • 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 in der Referenz für die API und gcloud CLI.

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

  • Aktivieren Sie die folgenden APIs: Compute Engine API, Certificate Manager API, Netzwerksicherheit und Network Services API. Weitere Informationen finden Sie unter APIs aktivieren.

  • 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 Backends eingerichtet haben:

    • Back-Ends von VM-Instanzgruppen
    • Cloud Storage-Buckets (nur unterstützt, wenn zusätzlich zum Backend-Bucket mindestens ein Backend-Dienst an den Load Balancer angehängt ist)
    • Cloud Run, App Engine oder Cloud Run Functions
    • Hybridkonnektivität
    • Private Service Connect-Backends

  • 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 eingerichtet haben:

    • Back-Ends von VM-Instanzgruppen
    • Cloud Run
    • Hybridkonnektivität
    • Private Service Connect-Backends

  • Projekt festlegen

    gcloud 

    gcloud config set project PROJECT_ID

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 TargetHTTPSProxy: 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.

Root- und Zwischenzertifikate erstellen

In diesem Abschnitt wird die OpenSSL-Bibliothek verwendet, um das Root-Zertifikat (Trust-Anchor) und das Zwischenzertifikat zu erstellen.

Ein Root-Zertifikat befindet sich am Anfang der Zertifikatskette. Ein Zwischenzertifikat ist Teil der Vertrauenskette, die zum Root-Zertifikat zurückführt. Das Zwischenzertifikat wird vom Root-Zertifikat kryptografisch signiert. Wenn der Load Balancer ein Clientzertifikat empfängt, validiert er es, indem er eine Vertrauenskette vom Clientzertifikat zurück zum konfigurierten Trust-Anchor herstellt.

Verwenden Sie die folgenden Befehle, um die Root- und Zwischenzertifikate zu erstellen. Das Erstellen des Zwischenzertifikats ist optional. In dieser Konfiguration verwenden wir jedoch das Zwischenzertifikat, um das Clientzertifikat zu signieren.

  1. Erstellen Sie eine OpenSSL-Konfigurationsdatei.

    Im folgenden Beispiel enthält die Konfigurationsdatei (example.cnf) den Abschnitt [ca_exts], in dem X.509-Erweiterungen angegeben sind, die das Zertifikat als für eine Zertifizierungsstelle geeignet kennzeichnen. Weitere Informationen zu den Anforderungen für Stamm- und Zwischenzertifikate finden Sie unter Zertifikatsanforderungen.

    cat > example.cnf << EOF
[req]
distinguished_name = empty_distinguished_name

[empty_distinguished_name]
# Kept empty to allow setting via -subj command-line argument.

[ca_exts]
basicConstraints=critical,CA:TRUE
keyUsage=keyCertSign
extendedKeyUsage=clientAuth

EOF

  2. Generieren Sie einen neuen privaten RSA-Schlüssel (root.key) und erstellen Sie damit ein selbst signiertes X.509-Root-CA-Zertifikat (root.cert), das als Root-Zertifizierungsstelle (CA) dient.

    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. Erstellen Sie eine Anfrage für das Signieren des Zertifikats (Certificate Signing Request, CSR) (int.req) für das Zwischenzertifikat.

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

  4. Erstellen Sie das X.509-Zwischenzertifikat (int.cert) aus der CSR. Die Stamm-Zertifizierungsstelle verwendet ihren privaten Schlüssel (root.key) und ihr Zertifikat (root.cert), um das X.509-Zwischenzertifikat auszustellen und zu signieren.

    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

Selbst signiertes Zertifikat erstellen, das einer Zulassungsliste hinzugefügt werden kann

Sie können ein selbst signiertes Zertifikat erstellen und es einer Zulassungsliste in der Vertrauenskonfiguration hinzufügen.

Verwenden Sie den folgenden OpenSSL-Befehl, um ein selbst signiertes X.509-Zertifikat zu erstellen.

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

Dieses Zertifikat wird dann einem allowlistedCertificates-Feld in der Vertrauenskonfiguration hinzugefügt.

Zertifikate formatieren

Wenn Sie neue oder vorhandene Zertifikate in einen TrustStore aufnehmen möchten, formatieren Sie die Zertifikate in einer einzelnen Zeile und speichern Sie sie in Umgebungsvariablen, damit sie von der YAML-Datei der Trust-Konfiguration referenziert werden können.

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

Wenn Sie neue oder vorhandene Zertifikate, die einer Zulassungsliste hinzugefügt wurden, in eine Trust-Konfiguration aufnehmen möchten, formatieren Sie die Zertifikate in einer einzelnen Zeile und speichern Sie sie in Umgebungsvariablen, damit sie in die YAML-Datei gelesen werden können. Verwenden Sie für Zertifikate, die auf einer Zulassungsliste stehen, den folgenden Befehl, um die Zertifikate in einer einzelnen Zeile zu formatieren und in der Umgebungsvariable ALLOWLISTED_CERT zu speichern.

export ALLOWLISTED_CERT=$(cat allowlisted.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 Vertrauenskonfigurationsressource:

Console

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

    Zum Zertifikatmanager

  2. Klicken Sie auf dem Tab Vertrauenskonfigurationen auf 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 Standort gibt an, wo die Ressource für die Vertrauenskonfiguration gespeichert wird. Erstellen Sie für globale externe Application Load Balancer, klassische Application Load Balancer und regionenübergreifende interne Application Load Balancer eine globale TrustConfig-Ressource. Erstellen Sie für regionale externe Application Load Balancer und regionale interne Application Load Balancer eine regionale TrustConfig-Ressource.

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

  5. Klicken Sie im Abschnitt 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 im Abschnitt Trust Store auf Zwischen-CA hinzufügen und laden Sie die PEM-codierte Zertifikatsdatei hoch oder kopieren Sie den Inhalt des Zertifikats.

    Mit diesem Schritt können Sie eine weitere Vertrauensebene zwischen dem Root-Zertifikat und Ihrem Serverzertifikat hinzufügen.

  8. Klicken Sie auf Hinzufügen, um die Zwischenzertifizierungsstelle hinzuzufügen.

  9. Optional: Klicken Sie im Bereich Zugelassene Zertifikate auf Zertifikat hinzufügen und laden Sie die PEM-codierte Zertifikatsdatei hoch oder kopieren Sie den Inhalt des Zertifikats.

  10. Klicken Sie auf Hinzufügen, um das Zertifikat von der Zulassungsliste hinzuzufügen.

  11. Klicken Sie auf Erstellen.

Prüfen Sie, ob die neue Vertrauenskonfigurationsressource in der Liste der Konfigurationen angezeigt wird.

gcloud

  1. Erstellen Sie eine YAML-Datei für die Vertrauenskonfiguration (trust_config.yaml), in der die Parameter für die Vertrauenskonfiguration angegeben sind. Diese Beispielressource für die Vertrauenskonfiguration enthält einen Trust Store mit einem Trust-Anchor und einem Zwischenzertifikat. Der Zertifikatsinhalt wird aus den Umgebungsvariablen gelesen, die im vorherigen Schritt Zertifikate formatieren erstellt wurden.

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

    Fügen Sie im entsprechenden Abschnitt pemCertificate-Zeilen hinzu, um einen Trust Store mit zusätzlichen Trust-Anchors oder Zwischenzertifikaten zu erstellen.

  2. Optional: Geben Sie im Feld allowlistedCertificates das Zertifikat an, das der YAML-Datei für die Vertrauenskonfiguration hinzugefügt wird. Sie benötigen keinen Trust Store, um ein Zertifikat einer Zulassungsliste hinzuzufügen.

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

    Ein Zertifikat, das einer Zulassungsliste hinzugefügt wird, ist ein Zertifikat, das in der Vertrauenskonfiguration gekapselt werden kann, sodass es immer als gültig gilt. Sie können mehrere Zertifikate in einer Zulassungsliste angeben, indem Sie mehrere Instanzen des Felds pemCertificate verwenden.

  3. Verwenden Sie den Befehl gcloud certificate-manager trust-configs import, um die YAML-Datei für die Vertrauenskonfiguration 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 für die TrustConfig-Ressource 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 TrustConfig-Ressource 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 als ServerTLSPolicy bezeichnet) können Sie den serverseitigen TLS-Modus und die TrustConfig-Ressource angeben, die bei der Validierung von Clientzertifikaten verwendet werden soll. Wenn der Client dem Load Balancer ein ungültiges oder kein Zertifikat übergibt, gibt der clientValidationMode an, wie die Clientverbindung verarbeitet wird. Weitere Informationen finden Sie unter mTLS-Clientvalidierungsmodi.

  • Wenn clientValidationMode auf ALLOW_INVALID_OR_MISSING_CLIENT_CERT gesetzt ist, werden alle Anfragen an das Backend weitergeleitet, auch wenn die Validierung fehlschlägt oder das Clientzertifikat fehlt.
  • Wenn clientValidationMode auf REJECT_INVALID gesetzt ist, werden nur Anfragen an das Backend weitergeleitet, die ein Clientzertifikat enthalten, das anhand einer TrustConfig-Ressource validiert werden kann.
  • Wenn clientValidationMode auf ALLOW_VALIDATION_RELAXATIONS gesetzt ist, werden nur Anfragen an das Backend weitergeleitet, die ein Clientzertifikat enthalten, das anhand einer TrustConfig-Ressource validiert werden kann, wobei die angegebenen Validierungslockerungen (clientValidationRelaxations) angewendet werden.

Führen Sie die folgenden Schritte aus, um eine Clientauthentifizierungsressource (ServerTlsPolicy) zu erstellen:

Console

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

    Zur Authentifizierungskonfiguration

  2. Klicken Sie auf dem Tab Clientauthentifizierung auf 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 den Standort auf die Region fest, in der der Load Balancer konfiguriert ist.

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

  6. Wählen Sie für Clientvalidierungsmodus eine der folgenden Optionen aus:

    • Ungültiges ablehnen
    • Ungültiges oder fehlendes Clientzertifikat zulassen
    • Lockerungen der Validierung zulassen

    Weitere Informationen finden Sie unter Clientvalidierungsmodi.

    Wenn Sie Lockerungen der Validierung zulassen auswählen, wählen Sie eine oder mehrere der folgenden Lockerungen der Validierung aus:

    • Fehlende EKU zulassen
    • SHA-1-Hash-Technologie zulassen
    • Abgelaufenes untergeordnetes Zertifikat zulassen

  7. Wählen Sie die zuvor erstellte Ressource für die Konfiguration der Vertrauensstellung aus.

  8. Optional: Klicken Sie auf Entsprechender Code, um die Terraform-Konfiguration für diese Ressource aufzurufen.

  9. Klicken Sie auf Erstellen.

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

gcloud

  1. Wählen Sie je nachdem, wie Sie die Verbindung verarbeiten möchten, 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 Application Load Balancer, klassische Application Load Balancer und regionenübergreifende interne Application Load Balancer eine YAML-Datei, in der der Clientvalidierungsmodus und eine globale TrustConfig-Ressource 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 Clientvalidierungsmodus und eine regionale TrustConfig-Ressource 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 Clientvalidierungsmodus und eine globale TrustConfig-Ressource 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 Clientvalidierungsmodus und eine regionale TrustConfig-Ressource 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

    • Option 3: clientValidationMode ist auf ALLOW_VALIDATION_RELAXATIONS 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 Clientvalidierungsmodus, eine oder mehrere Validierungsentspannungen und eine globale TrustConfig-Ressource deklarativ angegeben werden:

      cat << EOF > server_tls_policy.yaml
name: SERVER_TLS_POLICY_NAME
mtlsPolicy:
    clientValidationMode: ALLOW_VALIDATION_RELAXATIONS
    clientValidationRelaxations:
    - VALIDATION_RELAXATION
    - VALIDATION_RELAXATION
    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 Clientvalidierungsmodus, eine oder mehrere Validierungslockerungen und eine regionale TrustConfig-Ressource deklarativ angegeben werden:

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

    Ersetzen Sie Folgendes:

    • SERVER_TLS_POLICY_NAME: der Name der Clientauthentifizierungsressource (ServerTlsPolicy).

    • VALIDATION_RELAXATION: einer oder mehrere der folgenden Werte: ALLOW_MISSING_EKU, ALLOW_SHA1_HASHING oder ALLOW_EXPIRED_LEAF_CERTIFICATE.

    • PROJECT_ID: die ID Ihres Projekts in Google Cloud .

    • REGION: Verwenden Sie für den regionalen externen Application Load Balancer oder den regionalen internen 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 Clientauthentifizierungsressource ServerTlsPolicy zu importieren:

    global

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

    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 Clientauthentifizierungsressource (ServerTlsPolicy).

    regional

    Setzen Sie bei regionalen externen Application Load Balancern und regionalen internen Application Load Balancern das Flag --location auf die Region, 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 Clientauthentifizierungsressource (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 für globale externe Application Load Balancer, klassische Application Load Balancer und regionenübergreifende interne Application Load Balancer global. Verwenden Sie für regionale externe Application Load Balancer 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 Clientauthentifizierungsressource (ServerTLSPolicy) an die Ziel-HTTPS-Proxy-Ressource des Load Balancers anhängen.

Console

  1. Rufen Sie in der Google Cloud Console 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 Clientauthentifizierungsressource (ServerTLSPolicy) anhängen möchten.

  3. Klicken Sie auf Bearbeiten.

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

  5. Wählen Sie in der Liste 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 Ziel-Proxys 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 Ziel-Proxys im YAML-Format. Beispiel: 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 für den regionenübergreifenden internen Application Load Balancer, den globalen externen Application Load Balancer oder den klassischen Application Load Balancer global. Verwenden Sie für einen regionalen externen Application Load Balancer oder einen regionalen internen 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. Hängen Sie die Clientauthentifizierung (ServerTlsPolicy) an den 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 Projekts in Google Cloud .
    • LOCATION: Verwenden Sie für globale externe Application Load Balancer oder klassische Application Load Balancer und regionenübergreifende interne Application Load Balancer global. Verwenden Sie für einen regionalen externen Application Load Balancer oder einen regionalen internen Application Load Balancer die Region, in der Sie den Load Balancer konfiguriert haben.
    • SERVER_TLS_POLICY_NAME: der Name der Clientauthentifizierungsressource (ServerTLSPolicy).
    • TARGET_PROXY_FILENAME: der Name der Konfigurationsdatei des Ziel-Proxys 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 Ziel-Proxys 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 Ziel-Proxys im YAML-Format. Beispiel: 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 zur mTLS-Verbindung über benutzerdefinierte Header übergeben. Sie können auch das Logging aktivieren, damit mTLS-Verbindungsfehler in Ihren Logs erfasst werden. Weitere Informationen zum Konfigurieren des Loggings finden Sie hier:

Benutzerdefinierte mTLS-Header zu Backend-Diensten 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 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 \
  --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 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 regionenü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 verwenden, um benutzerdefinierte Antwortheader (responseHeadersToAdd) zu senden.

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

Clientzertifikat mit dem Zwischenzertifikat signieren

Dieser Abschnitt bietet eine zusätzliche Konfigurationsoption zum Generieren eines Clientzertifikats (untergeordnetes Zertifikat). Wenn Sie bereits eine TrustConfig-Ressource mit einem Zwischenzertifikat erstellt haben, gehen Sie so vor:

  1. Erstellen Sie eine Konfigurationsdatei, um die 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 für Clientzertifikate finden Sie unter Zertifikatanforderungen.

    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

    Wenn Sie der Konfigurationsdatei eine SPIFFE-Identität hinzufügen möchten, gehen Sie so vor:

    • Fügen Sie dem Abschnitt [extension_requirements] ein Feld subjectAltName hinzu:

      subjectAltName            = @sans_list

    • Fügen Sie am Ende der Datei client.config einen neuen Abschnitt ([sans_list]) hinzu:

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

  2. Erstellen Sie eine CSR (client.csr) für das Clientzertifikat.

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

  3. Erstellen Sie ein Clientzertifikat (client.cert) aus der CSR. Die Zwischenzertifizierungsstelle verwendet ihren privaten Schlüssel (int.key) und ihr Zertifikat (int.cert), um das X.509-Clientzertifikat auszustellen und zu signieren.

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

  4. Senden Sie eine sichere HTTPS-Anfrage mit dem clientseitigen SSL-Zertifikat an die IP-Adresse des Load Balancers. Der Client stellt sein Zertifikat (client.cert) bereit, um sich gegenüber dem Load Balancer zu authentifizieren.

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

    Ersetzen Sie IP_ADDRESS durch die IP-Adresse des Load-Balancers.

Nächste Schritte