Gegenseitiges TLS mit vom Nutzer bereitgestellten Zertifikaten einrichten

Auf dieser Seite finden Sie eine Anleitung zum Erstellen eines Root-Zertifikats und eines signierten Zwischenzertifikats sowie zum Hochladen dieser Zertifikate in eine TrustConfig-Ressource von Zertifikatmanager. Wenn Sie vorhandene Zertifikate hochladen möchten, überspringen Sie die folgenden Schritte zum Erstellen neuer Zertifikate.

Sie erstellen auch die Netzwerksicherheitsressourcen, die zum Konfigurieren von gegenseitigem TLS (mTLS) für Application Load Balancer erforderlich sind. In der Anleitung werden OpenSSL verwendet, um die Root- und Zwischenzertifikate zu erstellen.

Hinweis

  • Lesen Sie die Übersicht zu gegenseitigem TLS.
  • Weitere Informationen finden Sie unter 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 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.

  • APIs aktivieren: Compute Engine API, Certificate Manager API, Network Security und Network Services API.

  • 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 neben dem Back-End-Bucket auch mindestens ein Back-End-Dienst auch mit dem Load-Balancer verbunden ist)
    • Cloud Run, App Engine oder Cloud Run Functions
    • Hybridkonnektivität

  • Wenn Sie regionale externe Application Load Balancer, regionenübergreifende interne Application Load Balancer oder regionale interne 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

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

Schlüssel und signierte Zertifikate generieren

In diesem Abschnitt werden openssl-Befehle verwendet, um Root- und Zwischenzertifikate zu erstellen.

Verwenden Sie die folgenden Befehle, um ein Root-Zertifikat und ein signiertes Zwischenzertifikat mit gültigen Feldern keyUsage und extendedKeyUsage zu generieren.

  1. Erstellen Sie eine example.cnf-Beispieldatei mit der Mindestkonfiguration, die zum Erstellen gültiger Signaturzertifikate erforderlich ist. Sie können diese Datei bearbeiten, wenn Sie zusätzliche Felder für diese Zertifikate festlegen möchten.

    cat > example.cnf << EOF
[req]
distinguished_name = empty_distinguished_name
[empty_distinguished_name]
# Kept empty to allow setting via -subj command line arg.
[ca_exts]
basicConstraints=critical,CA:TRUE
keyUsage=keyCertSign
extendedKeyUsage=clientAuth
EOF

  2. Erstellen Sie das Root-Zertifikat.

    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 die Signaturanfrage 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 Zwischenzertifikat.

    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

Zertifikat generieren und einer Zulassungsliste hinzufügen

In diesem Abschnitt werden openssl-Befehle verwendet, um ein Beispielzertifikat zu erstellen und einer Zulassungsliste hinzuzufügen.

Verwenden Sie die folgenden Befehle, um ein Zertifikat zu generieren und einer Zulassungsliste hinzuzufügen.

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

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 in die YAML-Datei gelesen werden können. Verwenden Sie die folgenden Befehle, um die Zertifikate zu formatieren und in Umgebungsvariablen zu speichern:

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 werden, 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 auf einer Zulassungsliste den folgenden Befehl, um die Zertifikate in eine einzelne Zeile zu formatieren und in der Umgebungsvariablen ALLOWLISTED_CERT zu speichern.

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

TrustConfig-Ressource erstellen

Erstellen Sie eine Zertifikatmanager-TrustConfig-Ressource, die Ihre PKI darstellt. Diese TrustConfig-Beispielressource enthält einen Trust Store mit zwei Trust-Anchors und zwei Zwischen-CA-Zertifikaten. Der Zertifikatsinhalt wird aus den Umgebungsvariablen gelesen, die im vorherigen Schritt Zertifikate formatieren erstellt wurden.

Fügen Sie im entsprechenden Abschnitt pemCertificate-Zeilen hinzu, um einen Trust Store mit zusätzlichen Trust-Anchors oder Zwischen-CA-Zertifikaten zu erstellen. Wenn Sie weniger Trust-Anchors oder Zwischen-CA-Zertifikate haben, entfernen Sie die nicht benötigten Zeilen.

Diese TrustConfig-Beispielressource enthält ein Zertifikat, das einer Zulassungsliste hinzugefügt wird. Sie können mehrere Zertifikate in einer Zulassungsliste angeben, indem Sie mehrere Instanzen des Felds pemCertificate verwenden.

Ersetzen Sie in den folgenden Schritten TRUST_CONFIG_NAME durch den Namen der TrustConfig-Ressource:

  1. Verwenden Sie den folgenden Befehl, um die Datei trust_config.yaml mit einem Trust Store zu erstellen:

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

  2. Optional: Verwenden Sie den folgenden Befehl, um die Datei trust_config.yaml mit einem Zertifikat zu erstellen, das einer Zulassungsliste hinzugefügt wird:

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

  3. Verwenden Sie zum Erstellen der Certificate Manager-TrustConfig-Ressourcen den Befehl gcloud certificate-manager trust-configs import:

    global

    Verwenden Sie für externe Application Load Balancer und regionenübergreifende interne Application Load Balancer den folgenden Befehl:

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

    regional

    Verwenden Sie für regionale externe Application Load Balancer und regionale interne Application Load Balancer diesen Befehl:

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

Clientauthentifizierungsressourcen erstellen

Mit einer Ressource für die Clientauthentifizierung (auch ServerTLSPolicy genannt) können Sie den serverseitigen TLS-Modus und die Ressource TrustConfig angeben, die bei der Validierung von Clientzertifikaten verwendet werden sollen. 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 übergeben, 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 bereitstellen, das mit einer TrustConfig-Ressource validiert werden kann.

Führen Sie die folgenden Schritte aus, um die Ressource ServerTLSPolicy zu erstellen:

  1. Wählen Sie je nachdem, wie Sie die Verbindung verarbeiten möchten, eine der folgenden Optionen aus.

    Ersetzen Sie in den folgenden Schritten SERVER_TLS_POLICY_NAME durch den Namen der Server-TLS-Richtlinie und PROJECT_ID durch die ID Ihres Google Cloud-Projekts.

    • Option 1: clientValidationMode ist auf ALLOW_INVALID_OR_MISSING_CLIENT_CERT festgelegt.

      Erstellen Sie mit dem folgenden Befehl die Datei server_tls_policy.yaml:

      global

      Verwenden Sie für externe Application Load Balancer und regionenübergreifende interne Application Load Balancer den folgenden Befehl:

      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

      Verwenden Sie für regionale externe Application Load Balancer und regionale interne Application Load Balancer den folgenden Befehl:

      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.

      Erstellen Sie mit dem folgenden Befehl die Datei server_tls_policy.yaml:

      global

      Verwenden Sie für externe Application Load Balancer und regionenübergreifende interne Application Load Balancer den folgenden Befehl:

      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

      Verwenden Sie für regionale externe Application Load Balancer und regionale interne Application Load Balancer den folgenden Befehl:

      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

  2. Verwenden Sie den Befehl gcloud network-security server-tls-policies import, um die Ressource ServerTlsPolicy zu erstellen.

    global

    Verwenden Sie für externe Application Load Balancer und regionenübergreifende interne Application Load Balancer den folgenden Befehl:

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

    regional

    Verwenden Sie für regionale externe Application Load Balancer und regionale interne Application Load Balancer den folgenden Befehl:

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

  3. Optional: Listet alle Ressourcen der Clientauthentifizierung (ServerTlsPolicies) 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: 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 einen regionalen externen Application Load Balancer oder einen regionalen internen Application Load Balancer die Region, in der Sie den Load Balancer konfiguriert haben.

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 „Client Authentication“ (ServerTLSPolicy) bereits erstellt haben. Eine Anleitung finden Sie unter Clientauthentifizierungsressourcen 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 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 einer YAML-Datei. 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 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: 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 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 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 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 einer YAML-Datei. 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 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 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 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 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 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}"

Clientschlüssel mit dem Zwischenzertifikat signieren

Dieser Abschnitt bietet eine zusätzliche Konfigurationsoption zum Generieren eines untergeordneten Zertifikats. Wenn Sie bereits eine TrustConfig-Ressource mit Zwischenzertifikaten (int.cert und int.key) erstellt haben, folgen Sie dieser Anleitung:

  1. Erstellen Sie eine Konfigurationsdatei für den Clientschlüssel.

    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 eine SPIFFE-Identität anhängen möchten, gehen Sie so vor:

    • Fügen Sie so einen subjectAltName in den Abschnitt [extension_requirements] ein:

      subjectAltName            = @sans_list

    • Fügen Sie am Ende der Datei client.config einen neuen Abschnitt hinzu:

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

  2. Signieren Sie den Schlüssel.

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

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

  3. Senden Sie zum Testen eine curl-Anfrage an die IP-Adresse des Load Balancers.

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

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

Nächste Schritte