Ein gültiges Clientzertifikat muss eine Vertrauenskette zum Vertrauensanker im Trust Store aufweisen. Auf dieser Seite finden Sie eine Anleitung zum Erstellen einer eigenen Vertrauenskette mit dem Root-Zertifikat einer privaten Zertifizierungsstelle (Certificate Authority, CA), über die Sie die Kontrolle haben. Bei dieser Einrichtung wird die private CA 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 Trust Store der TrustConfig
-Ressource von Certificate Manager hochladen. Anschließend wird die Vertrauenskonfiguration mit der Ressource zur Clientauthentifizierung (ServerTLSPolicy
) verknüpft und die Ressource zur Clientauthentifizierung 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 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 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.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 einrichten:
- Back-Ends von VM-Instanzgruppen
- Cloud Storage-Buckets (werden nur unterstützt, wenn neben dem Backend-Bucket auch mindestens ein Backend-Dienst an den Load-Balancer angehängt 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 Back-Ends 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
: Administrator für Compute-Load-Balancer (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 Stamm-CA abrufen
Die Root-CA hat ein selbst signiertes Zertifikat, das Sie dem Truststore hinzufügen müssen. Das Zertifikat der Stamm-CA befindet sich oben in der Zertifikatskette.
Um das Zertifikat der Stammzertifizierungsstelle zu erhalten, müssen Sie zuerst einen CA-Pool erstellen, der bei der Erstellung leer ist. Anschließend müssen Sie 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.
Verwenden Sie zum Erstellen eines CA-Pools den Befehl
gcloud privateca pools create
:gcloud privateca pools create CA_POOL \ --location=us-central1
Ersetzen Sie
CA_POOL
durch die ID oder den Namen des übergeordneten CA-Pools.Verwenden Sie zum Erstellen einer Stamm-CA und zum Hinzufügen zum CA-Pool den Befehl
gcloud privateca roots create
: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
ist die ID oder der Name des übergeordneten CA-Pools.
Extrahieren Sie das PEM-codierte Zertifikat, das die Stammzertifizierungsstelle identifiziert.
gcloud privateca roots describe CA_ROOT \ --pool=CA_POOL \ --location=us-central1 \ --format='value(pemCaCertificates)' > root.cert
Ersetzen Sie Folgendes:
CA_ROOT
ist die ID oder der Name der privaten CA.CA_POOL
ist die ID oder der Name des übergeordneten CA-Pools.
Das Root-Zertifikat (
root.cert
) muss in den Trust Store hochgeladen werden. Dieser Schritt wird im folgenden Abschnitt ausgeführt.
Weitere Informationen zum Erstellen eines CA-Pools und einer Root-CA mit Certificate Authority Service finden Sie unter:
Stamm-CA-Zertifikat formatieren
Wenn Sie das Root-Zertifikat in einen Trust Store aufnehmen möchten, formatieren Sie das Zertifikat in einer einzelnen Zeile und speichern Sie es in einer Umgebungsvariable, damit in der YAML-Datei der Trust-Konfiguration darauf verwiesen 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 Vertrauenskonfigurationsressource:
Console
Rufen Sie in der Google Cloud Console die Seite Certificate Manager auf.
Klicken Sie auf dem Tab Vertrauenskonfigurationen auf Vertrauenskonfiguration hinzufügen.
Geben Sie einen Namen für die Konfiguration ein.
Wählen Sie als Standort die Option Global oder Regional aus.
Der Speicherort gibt an, wo die Vertrauenskonfigurationsressource 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.
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.
Klicken Sie auf Hinzufügen.
Klicken Sie auf Erstellen.
Prüfen Sie, ob die neue Vertrauenskonfigurationsressource in der Liste der Konfigurationen angezeigt wird.
gcloud
Erstellen Sie eine YAML-Datei für die Vertrauenskonfiguration (
trust_config.yaml
), in der die Parameter für die Vertrauenskonfiguration angegeben werden. 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 CA generiert.cat << EOF > trust_config.yaml name: TRUST_CONFIG_NAME trustStores: - trustAnchors: - pemCertificate: "${ROOT?}" EOF
Verwenden Sie den
gcloud certificate-manager trust-configs import
-Befehl, um die YAML-Datei mit der 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 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 istglobal
.
Clientauthentifizierungsressource erstellen
Mit einer Ressource zur Clientauthentifizierung (auch als ServerTLSPolicy
bezeichnet) 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-Clientvalidierungsmodi.
- Wenn
clientValidationMode
aufALLOW_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
aufREJECT_INVALID
festgelegt ist, werden nur Anfragen, die ein Clientzertifikat enthalten, das anhand einerTrustConfig
-Ressource validiert werden kann, an das Backend weitergeleitet.
Führen Sie die folgenden Schritte aus, um eine Ressource für die Clientauthentifizierung (ServerTlsPolicy
) zu erstellen:
Console
Rufen Sie in der Google Cloud Console die Seite Authentifizierungskonfiguration auf.
Klicken Sie auf dem Tab Client Authentication (Clientauthentifizierung) auf Create (Erstellen).
Geben Sie einen Namen für die Clientauthentifizierungsressource ein.
Wählen Sie als Standort die Option Global oder Regional aus.
Für globale externe Application Load Balancer, klassische Application Load Balancer und regionenübergreifende interne Application Load Balancer legen Sie 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.
Wählen Sie für Client Authentication mode (Clientauthentifizierungsmodus) die Option Load balancing (Lastenausgleich) aus.
Wählen Sie einen Clientvalidierungsmodus aus.
Wählen Sie die Konfigurationsressource für die Vertrauensstellung aus, die Sie zuvor erstellt haben.
Klicken Sie auf Erstellen.
Prüfen Sie, ob die Clientauthentifizierung (ServerTlsPolicy
) angezeigt wird.
gcloud
Wählen Sie je nach gewünschter Vorgehensweise eine der folgenden Optionen aus, um die Ressource „Client Authentication“ (
ServerTlsPolicy
) im YAML-Format zu definieren.Option 1:
clientValidationMode
ist aufALLOW_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 Vertrauenskonfigurationsressource 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 Vertrauenskonfigurationsressource 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 aufREJECT_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 Vertrauenskonfigurationsressource 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 Vertrauenskonfigurationsressource 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 für die Clientauthentifizierung (ServerTlsPolicy
).PROJECT_ID
: die ID Ihres Google Cloud Projekts.LOCATION
: Verwenden Sieglobal
für globale externe Application Load Balancer, klassische Application Load Balancer und regionenübergreifende interne Application Load Balancer. Verwenden Sie für einen regionalen externen oder 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.
Verwenden Sie den Befehl
gcloud network-security server-tls-policies import
, um die ClientauthentifizierungsressourceServerTlsPolicy
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
aufglobal
.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 für die Clientauthentifizierung (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 für die Clientauthentifizierung (ServerTlsPolicy
).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 Balancerglobal
. Verwenden Sie für einen regionalen externen oder internen Application Load Balancer die Region, in der Sie den Load Balancer konfiguriert haben.
Ressource zur Clientauthentifizierung an den Load-Balancer anhängen
Damit die gegenseitige TLS-Authentifizierung funktioniert, müssen Sie nach dem Einrichten des Load-Balancers die Ressource für die Clientauthentifizierung (ServerTLSPolicy
) an die Ziel-HTTPS-Proxy-Ressource des Load-Balancers anhängen.
Console
Rufen Sie in der Google Cloud Console die Seite Load-Balancing auf.
Wählen Sie in der Liste der Load Balancer den Load Balancer aus, an den Sie die Client Authentication-Ressource (
ServerTLSPolicy
) anhängen möchten.Klicken Sie auf
Bearbeiten.Maximieren Sie im Bereich Frontend-Konfiguration für ein HTTPS-Frontend den Bereich Erweiterte Funktionen anzeigen.
Wählen Sie in der Liste Clientauthentifizierung die Clientauthentifizierungsressource aus.
Klicken Sie auf Fertig.
Klicken Sie auf Aktualisieren.
gcloud
Verwenden Sie den Befehl
gcloud compute target-https-proxies list
, um alle Ziel-HTTPS-Proxyressourcen in Ihrem Projekt aufzulisten:gcloud compute target-https-proxies list
Notieren Sie sich den Namen des HTTPS-Ziel-Proxys, an den die
ServerTLSPolicy
-Ressource angehängt werden soll. Dieser Name wird in den folgenden Schritten alsTARGET_HTTPS_PROXY_NAME
bezeichnet.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 Zielproxys 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 Zielproxys im YAML-Format. z. B.mtls_target_proxy.yaml
.REGION
: die Region, in der Sie den Load Balancer konfiguriert haben.
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 Sieglobal
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 Application Load Balancer 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 alsSERVER_TLS_POLICY_NAME
bezeichnet.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 Google Cloud Projekts.LOCATION
: Verwenden Sie für globale externe Application Load Balancer oder klassische Application Load Balancer und regionenübergreifende interne Application Load Balancerglobal
. 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.SERVER_TLS_POLICY_NAME
: der Name der Ressource für die Clientauthentifizierung (ServerTLSPolicy
).TARGET_PROXY_FILENAME
: Der Name der Konfigurationsdatei des Zielproxys im YAML-Format.
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 Zielproxys 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 Zielproxys 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 zur mTLS-Verbindung über benutzerdefinierte Header übergeben. Sie können auch das Logging aktivieren, damit mTLS-Verbindungsfehler in den Logs erfasst werden.
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.
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.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 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 einem CSR abrufen
Dieser Abschnitt bietet eine zusätzliche Konfigurationsoption zum Generieren eines Clientzertifikats (untergeordnetes Zertifikat), das vom Zertifikat der Stammzertifizierungsstelle signiert wird.
Um ein Clientzertifikat zu erhalten, generieren Sie eine Anfrage für die Zertifikatssignierung (Certificate Signing Request, CSR) und senden Sie sie an den CA-Pool.
Erstellen Sie eine OpenSSL-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 werden, die in die CSR aufgenommen werden sollen. Weitere Informationen zu den Anforderungen an 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
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 -nodes \ -config client.config \ -keyout key.pem \ -out csr.pem
Führen Sie den folgenden
gcloud privateca certificates create
-Befehl aus, um den CSR einzureichen und das X.509-Clientzertifikat von der CA 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.
Senden Sie mit dem clientseitigen SSL-Zertifikat eine sichere HTTPS-Anfrage an die IP-Adresse des Load-Balancers. Der Client präsentiert sein Zertifikat, um sich gegenüber dem Load Balancer zu authentifizieren.
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.