Backend-mTLS mit verwalteter Arbeitslastidentität – Übersicht

Dieses Dokument bietet einen Überblick über die Verwendung einer verwalteten Arbeitslastidentität, um gegenseitiges TLS (mTLS) zwischen einem Application Load Balancer und seinen Back-Ends zu erreichen. Mit verwalteten Arbeitslastidentitäten werden X.509-Zertifikate automatisch vom Certificate Authority Service bereitgestellt und verwaltet.

Sie können auch ohne verwaltete Arbeitslastidentität Backend-mTLS erreichen. Weitere Informationen zu Backend-mTLS ohne verwaltete Arbeitslastidentität finden Sie unter Übersicht über Backend-authentifiziertes TLS und Backend-mTLS.

Die Informationen in diesem Dokument basieren auf Konzepten, die in den folgenden Dokumenten eingeführt werden:

Einführung in verwaltete Arbeitslastidentitäten für Load Balancer

Ohne verwaltete Arbeitslastidentität erfordert die Einrichtung von Backend-mTLS die Konfiguration mehrerer Ressourcen. Wenn Sie einem Backend-Dienst eines Load Balancers eine verwaltete Identität zuweisen, werden mit der verwalteten Arbeitslastidentität automatisch die für mTLS erforderlichen Ressourcen erstellt, z. B. das Clientzertifikat, die Vertrauenskonfiguration und die Konfiguration der Backend-Authentifizierung.

Bei Backend-mTLS fungiert die Backend-Dienstressource des Load-Balancers als Quell-Arbeitslast, die sich beim Backend authentifiziert, der die Ziel-Arbeitslast ist.

Sie können dem Backend-Dienst eines Load Balancers eine verwaltete Identität zuweisen, die durch eine SPIFFE-ID dargestellt wird. Google Cloud Certificate Authority Service stellt automatisch ein X.509-Zertifikat für die SPIFFE-ID bereit. Dieses X.509-Zertifikat für die SPIFFE-ID wird auch als SPIFFE Verifiable Identity Document (SVID) bezeichnet. Der Backend-Dienst des Load Balancers und seine Backends verwenden die SVIDs, um sich gegenseitig über die mTLS-Authentifizierung zu authentifizieren.

Das folgende Diagramm zeigt, wie der Load-Balancer (Quellarbeitslast) und das Backend (Zielarbeitslast) sich gegenseitig mit einer verwalteten Arbeitslastidentität authentifizieren.

Backend-mTLS mit verwalteten Arbeitslastidentitäten.
Backend-mTLS mit verwalteter Workload Identity (zum Vergrößern klicken).

Das folgende Beispiel zeigt ein X.509-SVID, das als Wrapper für die SPIFFE-ID dient. Die SPIFFE-ID, dargestellt als URI, ist im alternativen Antragstellernamen (Subject Alternative Name, SAN) eines X.509-Zertifikats codiert.

Issuer:
    C=US
    O=Example Inc.
    CN=Example CA

Validity:
    Not Before: Jun 14 00:00:00 2025 GMT
    Not After : Jun 16 00:00:00 2025 GMT

Subject (Distinguished Name):
    C=US
    O=Example Inc.
    OU=Production
    CN=api.example.com

Subject Public Key Info:
    Public Key Algorithm: RSA Encryption
    RSA Public-Key: (2048 bit)

X.509v3 Extensions:
    Subject Alternative Name (SAN):
        DNS: api.example.com
        URI: spiffe://WORKLOAD_IDENTITY_POOL_ID.global.PROJECT_NUMBER.workload.id.goog/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID

Diese Ausgabe enthält die folgenden Werte:

  • WORKLOAD_IDENTITY_POOL_ID: die ID des Workload Identity-Pools
  • PROJECT_NUMBER: Die Projektnummer IhresGoogle Cloud -Projekts
  • NAMESPACE_ID: die Namespace-ID
  • MANAGED_IDENTITY_ID: die ID der verwalteten Identität

Vorteile der Verwendung von verwalteten Arbeitslastidentitäten

Die Verwendung einer verwalteten Arbeitslastidentität für Backend-mTLS bietet unter anderem folgende Vorteile:

  • Erweiterte Sicherheitsfunktionen: Durch den Beitritt zu einem Workload Identity-Pool werden ein Google Cloud Load Balancer und seine Backends Teil einer vertrauenswürdigen Domain. In Verbindung mit Backend-mTLS authentifizieren sich der Load Balancer und die Backend-Arbeitslasten gegenseitig. Diese gegenseitige Authentifizierung verhindert, dass unbefugte Arbeitslasten auf Ihre Dienste zugreifen, und verschlüsselt Daten bei der Übertragung.

  • Automatisierte Zertifikatsverwaltung: Nach erfolgreicher Arbeitslastbestätigung stelltGoogle Cloud automatisch die X.509-Zertifikate für Arbeitslasten bereit, die an der Vertrauensdomäne des Arbeitslastidentitätspools teilnehmen, und rotiert sie. Durch die automatische Verwaltung von X.509-Zertifikaten entfällt die komplexe und fehleranfällige manuelle Zertifikatsverwaltung.

  • Interoperable Identität: Workload Identity-Pools verwenden das SPIFFE-Framework, einen Standard für die Verwaltung von Identitäten in verteilten Systemen, der die Authentifizierung und Autorisierung in modernen, auf Mikrodiensten basierenden Architekturen ermöglicht.

  • Zentrale Verwaltung: Workload Identity-Pools bieten einen zentralen Kontrollpunkt. Administratoren können Vertrauensdomänen definieren und Attestierungsrichtlinien festlegen, um zu bestimmen, welche Arbeitslasten ein X.509-Zertifikat für die verwaltete Identität erhalten können.

Zertifikatsanforderungen

Achten Sie beim Konfigurieren von Zertifikaten darauf, dass sie die folgenden Anforderungen erfüllen:

  • Moderne Kryptografietools bilden die Grundlage der mTLS-Authentifizierung. Zertifikate müssen entweder RSA- oder ECDSA-Algorithmen für den Schlüsselaustausch verwenden. Für Hashing-Algorithmen muss SHA-256 oder eine stärkere kryptografische Hash-Funktion verwendet werden. Hash-Algorithmen wie MD4, MD5 und SHA-1 werden nicht unterstützt.

  • Von Back-Ends bereitgestellte Leaf-Serverzertifikate müssen die folgenden Anforderungen erfüllen:

  • Die in Backend-mTLS verwendeten Leaf-Clientzertifikate (Load-Balancer) sind die automatisch erstellten vom Zertifikatmanager verwalteten Identitätszertifikate und sollten automatisch die folgenden Anforderungen erfüllen:

  • Damit die Serverzertifikate authentifiziert werden können, die Ihr Backend dem Load Balancer präsentiert, müssen die Root- und Zwischenzertifikate in der Vertrauenskonfiguration die folgenden Anforderungen erfüllen:

Architektur von Backend-mTLS mit verwalteter Arbeitslastidentität

Die folgenden Komponenten arbeiten zusammen, um Backend-mTLS mit verwalteter Workload Identity zu erreichen:

  • Backend-Dienst des Load-Balancers (Compute Engine API)
  • Identity and Access Management-Vertrauensbereich (Identity and Access Management API)
  • Zertifizierungsstellenpool (Certificate Authority Service API)
  • Konfiguration der Backend-Authentifizierung (Network Security API)
  • Konfiguration der Vertrauensstellung des Zertifikatmanagers (Certificate Manager API)
  • Verwaltetes Identitätszertifikat für Zertifikatmanager (Certificate Manager API)

Das folgende Diagramm zeigt eine verwaltete Identität für den Backend-Dienst des Load-Balancers, mit der sich der Load-Balancer beim Backend authentifizieren kann. Im Diagramm stellen die Schritte 1 bis 3 explizit erstellte Ressourcen dar, während die Schritte 4 bis 5 automatisch erstellte Ressourcen darstellen.

  1. Konfigurieren Sie einen CA-Pool für den Certificate Authority Service, um Zertifikate für verwaltete Arbeitslastidentitäten auszustellen.
  2. Konfigurieren Sie eine vertrauenswürdige Domain, indem Sie einen Workload Identity-Pool erstellen. Für diesen Pool sind ein Namespace, eine verwaltete Identität, eine Attestierungsrichtlinie, eine Inline-Ressource für die Konfiguration der Zertifikatsausstellung und eine Inline-Ressource für die Trust-Konfiguration erforderlich.
  3. Konfigurieren Sie den Backend-Dienst des Load Balancers mit der verwalteten Identität.

  4. Mit der verwalteten Workload Identity werden automatisch das vom Zertifikatmanager verwaltete Identitätszertifikat und die vom Zertifikatmanager verwaltete Vertrauenskonfiguration erstellt.

    Das vom Zertifikatmanager verwaltete Identitätszertifikat wird auf Grundlage der Konfiguration der Zertifikatsausstellung im Workload Identity-Pool erstellt. Die Vertrauenskonfiguration des Zertifikatmanagers ist mit der Inline-Vertrauenskonfiguration des Workload Identity-Pools synchronisiert.

  5. Mit der verwalteten Arbeitslastidentität wird die Backend-Authentifizierungskonfiguration automatisch erstellt.

    Die Konfiguration der Vertrauensstellung des Zertifikatmanagers ist an die Konfiguration der Backend-Authentifizierung angehängt. Das von Zertifikatmanager verwaltete Identitätszertifikat (X.509-SVID) ist auch an die Konfiguration der Backend-Authentifizierung angehängt, die dann zur Authentifizierung beim Backend verwendet wird.

Weitere Informationen zur Backend-mTLS-Konfiguration mit verwalteter Identität finden Sie unter Backend-mTLS mit verwalteter Workload Identity einrichten.

Backend-mTLS mit verwalteter Workload Identity.
Architektur von Back-End-mTLS mit verwalteter Workload Identity (zum Vergrößern klicken).

Ressourcen, die während des Backend-mTLS mit verwalteter Identität erstellt werden

Wie im vorherigen Architekturdiagramm dargestellt, müssen Sie beim Zuweisen einer verwalteten Identität zum Backend-Dienst die Backend-Authentifizierungskonfiguration, die Zertifikatmanager-Vertrauenskonfiguration und das Zertifikatmanager-Zertifikat nicht konfigurieren. Diese Ressourcen werden automatisch von der verwalteten Arbeitslastidentität erstellt.

In diesem Abschnitt werden die verschiedenen Teile des Konfigurationsprozesses für verwaltete Identitäten genauer betrachtet. Dabei wird auf die Ressourcen eingegangen, die explizit und automatisch erstellt werden.

Explizit erstellte Ressourcen

Die folgenden Ressourcen müssen explizit erstellt werden, wenn Sie die Backend-mTLS mit verwalteter Workload Identity konfigurieren.

Zertifizierungsstellenpool

Wenn Sie verwaltete Arbeitslastidentitäten für den Load Balancer konfigurieren möchten, müssen Sie zuerst eine Zertifizierungsstelle und optional eine oder mehrere untergeordnete Zertifizierungsstellen konfigurieren. Diese Einrichtung wird als Zertifizierungsstellenhierarchie bezeichnet.

Sie können CA-Service-Pools verwenden, um diese Hierarchie einzurichten.

Der Workload Identity-Pool wird an den CA-Pool gebunden, indem der Workload Identity-Pool mit der Inline-Konfiguration für die Zertifikatausstellung aktualisiert wird.

Workload Identity-Pool

Verwaltete Arbeitslastidentitäten werden in einem Workload Identity-Pool definiert, der als vertrauenswürdige Domain dient.

Die vertrauenswürdige Domain stellt eine logische Sicherheitsgrenze dar, innerhalb derer sich Arbeitslasten mithilfe ihrer SPIFFE-IDs gegenseitig authentifizieren und autorisieren können. Alle Arbeitslasten in derselben vertrauenswürdigen Domain haben einen gemeinsamen Root of Trust, sodass die Arbeitslasten die Identitäten des jeweils anderen prüfen können.

Wenn Sie verwaltete Identitäten verwenden möchten, müssen Sie den Workload Identity-Pool im Modus TRUST_DOMAIN konfigurieren. Alle Identitäten in einem Pool bestehen aus einem einzelnen Namespace und einer individuellen Arbeitslast-ID.

Namespace

In einem Workload Identity-Pool werden verwaltete Arbeitslastidentitäten in administrativen Grenzen, sogenannten Namespaces, organisiert. Mit Namespaces können Sie zugehörige Arbeitslastidentitäten organisieren und Zugriff darauf gewähren.

Verwaltete Arbeitslastidentität

Die verwaltete Arbeitslastidentität basiert auf dem SPIFFE-Standard, der ein Framework zur Identifizierung, Authentifizierung und Sicherung der Kommunikation zwischen Arbeitslasten mithilfe einer eindeutigen SPIFFE-ID bietet.

Eine verwaltete Arbeitslastidentität oder eine verwaltete Identität ist ein Arbeitslast-Identifier, der in einem Workload Identity-Pool konfiguriert ist. Sie ist an eineGoogle Cloud -Ressource angehängt. Jede verwaltete Identität wird eindeutig durch einen Namespace und eine individuelle Workload-Kennung identifiziert.

Im Zusammenhang mit der Implementierung von Backend-mTLS wird die verwaltete Identität an die Backend-Dienstressource des Load-Balancers angehängt.

Der Wert einer verwalteten Identität ist eine vollständig angegebene SPIFFE-ID, die dem folgenden Format entsprechen muss:

spiffe://TRUST_DOMAIN_NAME/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID

Ein TRUST_DOMAIN_NAME wird so erweitert:

WORKLOAD_IDENTITY_POOL_ID.global.PROJECT_NUMBER.workload.id.goog

Compute Engine-Arbeitslasten, z. B. die Backend-Dienstressource eines Load Balancers, können eine verwaltete Identität haben:

spiffe://WORKLOAD_IDENTITY_POOL_ID.global.PROJECT_NUMBER.workload.id.goog/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID

Attestierungsrichtlinie

Eine Attestierungsrichtlinie enthält Regeln für Google Cloud IAM, um zu prüfen, ob der Backend-Dienst berechtigt ist, ein X.509-Zertifikat für die verwaltete Identität zu erhalten.

Wenn die Überprüfung der Attestierungsrichtlinie erfolgreich ist, fordert IAM ein X.509-Zertifikat für die verwaltete Identität vom Certificate Authority Service an. Das X.509-Zertifikat wird im CA-Pool erstellt, der an die verwaltete Identität gebunden ist. Der CA Service stellt das Zertifikat über die Identitätsspiegelung bereit. Dabei wird die konfigurierte SPIFFE-ID in ein X.509-Zertifikat gespiegelt.

Inline-Konfiguration der Zertifikatsausstellung

Wenn Sie einen Workload Identity-Pool einrichten, konfigurieren Sie eine Inline-Konfiguration für die Zertifikatausstellung. Mit dieser Konfiguration wird angegeben, welcher CA-Pool aus Ihrer Certificate Authority Service-Instanz zum Generieren von X.509-Zertifikaten für die Identitäten im Workload Identity-Pool verwendet wird. In der Konfigurationsdatei werden auch die Gültigkeitsdauer des Zertifikats, der Prozentsatz des Rotationszeitraums und der Schlüsselalgorithmus angegeben.

Der CA-Pool stellt X.509-Zertifikate für verwaltete Arbeitslastidentitäten aus, nachdem die Durchsetzung der Attestierungsrichtlinie erfolgreich war.

Inline-Konfiguration für die Vertrauensstellung des Workload Identity-Pools

Standardmäßig können sich Ihre Arbeitslasten innerhalb derselben vertrauenswürdigen Domain gegenseitig mit verwalteten Arbeitslastidentitäten authentifizieren. Wenn Sie möchten, dass Arbeitslasten in verschiedenen vertrauenswürdigen Domains sich gegenseitig authentifizieren, müssen Sie die Vertrauensstellung im Workload Identity-Pool explizit deklarieren. Dazu erstellen Sie eine Inline-Konfiguration für die Vertrauensstellung, in der Zertifikate aus anderen Vertrauensdomänen erkannt und akzeptiert werden. Diese Zertifikate werden verwendet, um eine Vertrauenskette zu erstellen und die Identität der Arbeitslasten aus anderen Domains zu bestätigen.

Die Inline-Konfiguration der Vertrauensstellung enthält eine Reihe von Trust-Anchors, die von der verwalteten Workload-Identität zum Validieren von Peer-Zertifikaten verwendet werden. Die Vertrauenskonfiguration des Zertifikatmanagers enthält einen SPIFFE Trust Store, der mit der Inline-Vertrauenskonfiguration des Workload Identity-Pools synchronisiert wird.

Da der Workload Identity-Pool an den CA-Pool gebunden ist, vertraut der Workload Identity-Pool automatisch den Root-Zertifikaten desselben CA-Pools. Sie müssen die CA-Roots des Pools nicht der Inline-Vertrauenskonfiguration hinzufügen, da das Vertrauen bereits integriert ist.

Im folgenden Diagramm gehören der Load-Balancer und das Back-End zur selben Vertrauensdomäne und verwenden dasselbe Root-Zertifikat. Das Root-Zertifikat wird verwendet, um eine Vertrauenskette zu erstellen und die Identität der Arbeitslasten in der vertrauenswürdigen Domain zu überprüfen.

Ressourcenhierarchie für verwaltete Arbeitslastidentitäten.
Ressourcenhierarchie für verwaltete Arbeitslastidentitäten (zum Vergrößern klicken).

Backend-Dienst (Compute Engine API)

Um dem Load-Balancer eine verwaltete Identität zuzuweisen, müssen Sie den Backend-Dienst des Load-Balancers so konfigurieren, dass sein Attribut tlsSettings auf die neue Eigenschaft identity (backendService.tlsSettings.identity) verweist.

Beachten Sie die folgenden Einschränkungen, die bei der Verwendung des Felds identity für den Backend-Dienst des Load-Balancers gelten:

  • Wenn Sie das Attribut identity festlegen, können Sie die folgenden Felder für das Attribut tlsSettings nicht manuell festlegen:

    • tlsSettings.sni
    • tlsSettings.subjectAltNames
    • tlsSettings.authenticationConfig

  • Das Feld identity kann nur beim Erstellen des Backend-Dienstes zugewiesen werden.

  • Das Feld identity ist unveränderlich. Nachdem Sie eine IP-Adresse dem Backend-Dienst des Load-Balancers zugewiesen haben, kann sie nicht mehr aktualisiert oder gelöscht werden.

Automatisch erstellte Ressourcen

Nachdem Sie die Eigenschaft identity (backendService.tlsSettings.identity) für den Backend-Dienst des Load Balancers festgelegt haben, werden die folgenden Ressourcen in der Certificate Manager API und der Network Security API automatisch von der verwalteten Arbeitslastidentität erstellt.

Die automatisch erstellten Ressourcen werden im selben Projekt wie der Backend-Dienst erstellt und verwenden die Standardkontingente in diesem Projekt.

Konfiguration der Vertrauensstellung des Zertifikatmanagers (Certificate Manager API)

Die Konfiguration der Vertrauensstellung im Zertifikatmanager wird automatisch erstellt und kann nicht direkt bearbeitet oder gelöscht werden.

Die Vertrauenskonfiguration des Zertifikatsmanagers enthält ein Feld mit dem Namen spiffeTrustStores. Das Feld spiffeTrustStores enthält das Trust-Bundle, das mit der Trust-Domain des Workload Identity-Pools verknüpft ist, sowie alle zusätzlichen Trust-Bundles, die im Feld additionalTrustBundles in der Inline-Trust-Konfiguration des Workload Identity-Pools angegeben sind. Weitere Informationen finden Sie unter Prüfen, ob die Vertrauenskonfiguration von Zertifikatmanager das Feld spiffeTrustStores enthält.

Weitere Informationen dazu, wie das Feld spiffeTrustStores in der Zertifikatmanager-Vertrauenskonfiguration die Validierung von SPIFFE-Zertifikaten ermöglicht, finden Sie unter Schritte zur Validierung von Serverzertifikaten.

Zertifikatmanager-Zertifikat für verwaltete Identität (Certificate Manager API)

Das von Certificate Manager verwaltete Identitätszertifikat wird automatisch von der verwalteten Arbeitslastidentität erstellt. Das Zertifikat der verwalteten Identität des Zertifikatmanagers ist schreibgeschützt und kann nicht direkt mit der Certificate Manager API bearbeitet oder gelöscht werden. Das vom Zertifikatmanager verwaltete Identitätszertifikat basiert auf der Inline-Konfiguration für die Zertifikatausstellung, die im Workload Identity-Pool definiert ist.

Das von Zertifikatmanager verwaltete Identitätszertifikat hat die Eigenschaft managedIdentity, die es als Zertifikat für verwaltete Identitäten kennzeichnet. In der Zertifikatsressource für verwaltete Identitäten von Zertifikatmanager wird die X.509-SVID im PEM-codierten Format gespeichert. Dieses X.509-SVID enthält die SPIFFE-ID, die als URI im SAN-Feld codiert ist. Diese SPIFFE-ID entspricht der verwalteten Identität im Workload Identity-Pool.

Der Bereich des von Certificate Manager verwalteten Identitätszertifikats ist CLIENT_AUTH. Das bedeutet, dass dieses Zertifikat als Clientzertifikat in Backend-mTLS verwendet wird.

Konfiguration der Backend-Authentifizierung (Network Security API)

Die Konfiguration der Backend-Authentifizierung wird automatisch von der verwalteten Arbeitslastidentität erstellt. Die Konfiguration der Backend-Authentifizierung ist schreibgeschützt und kann nicht direkt mit der Network Security API bearbeitet oder gelöscht werden.

Die Vertrauenskonfiguration des Zertifikatmanagers ist an die Konfiguration der Backend-Authentifizierung angehängt.

Das von Zertifikatmanager verwaltete Identitätszertifikat wird auch an die Konfiguration der Backend-Authentifizierung angehängt und als X.509-SVID in Backend-mTLS-Anfragen zwischen dem Load Balancer und den Zielarbeitslasten verwendet.

Schritte zur Validierung des Serverzertifikats

Bei der Validierung des Serverzertifikats während des Backend-mTLS führt der Load Balancer die folgenden Schritte aus:

  1. Bestätigen, dass der Server den privaten Schlüssel des Zertifikats besitzt.

    Der Server weist nach, dass er den privaten Schlüssel besitzt, der dem Zertifikat zugeordnet ist, das er dem Load-Balancer präsentiert. Dazu signiert er einen Teil der Informationen mit seinem privaten Schlüssel und sendet ihn als Teil der CertificateVerify-Nachricht an den Load-Balancer. Der Load Balancer überprüft diese Signatur dann mit dem öffentlichen Schlüssel aus dem Zertifikat des Servers. Wenn die Signaturprüfung fehlschlägt, bedeutet das, dass der Backend-Server nicht den privaten Schlüssel besitzt, der dem Zertifikat entspricht. In solchen Fällen beendet der Load Balancer den TLS-Handshake, ohne Fehler zu protokollieren.

  2. Vertrauenskette prüfen

    Das Feld spiffeTrustStores in der Vertrauenskonfiguration von Zertifikatmanager ermöglicht die Validierung von SPIFFE-Zertifikaten. Das Feld spiffeTrustStores in der Zertifikatmanager-Vertrauenskonfiguration wird automatisch aktiviert, wenn Sie eine verwaltete Workload Identity verwenden. Wenn das Feld spiffeTrustStores aktiviert ist, bleibt das Feld trustStores leer.

    Das Feld spiffeTrustStores ist eine Map-Datenstruktur mit dem folgenden Schlüssel/Wert-Paar:

    • Der Schlüssel kann sowohl eine Vertrauensdomäne sein, die sich auf einen Workload Identity-Pool bezieht (im Format, das mit .workload.id.goog endet), als auch eine zusätzliche Vertrauensdomäne.
    • Der Wert ist ein TrustStore-Objekt. Dieses Objekt enthält eine Sammlung vertrauenswürdiger Stammzertifikate (als Vertrauensbündel bezeichnet), die zum Validieren von SPIFFE-Zertifikaten aus dieser bestimmten vertrauenswürdigen Domain verwendet werden.

    Mit dieser Zuordnung kann der Load-Balancer mit Trust Stores aus mehreren unterschiedlichen Sicherheitsbereichen konfiguriert werden. Wenn ein Back-End sein SPIFFE-Zertifikat präsentiert, extrahiert der Load-Balancer die SPIFFE-ID, ermittelt die vertrauenswürdige Domain und verwendet die spiffeTrustStores-Zuordnung, um den richtigen Trust Store zum Überprüfen der Vertrauenskette und zum Validieren des Zertifikats zu finden.

    Die Überprüfung umfasst Folgendes:

    • Das Serverzertifikat des Backends, die Zwischenzertifikate (falls angegeben) und das konfigurierte Root-Zertifikat entsprechen den Zertifikatsanforderungen.
    • Für alle Zertifikate in der Vertrauenskette stimmt das Feld „Subject“ (Betreff) im übergeordneten Zertifikat mit dem Feld „Issuer“ (Aussteller) im untergeordneten Zertifikat überein. Diese Überprüfung trägt dazu bei, dass die Identität (Antragsteller) des übergeordneten Zertifikats mit der Identität übereinstimmt, die im untergeordneten Zertifikat als Aussteller aufgeführt ist.
    • Für alle Zertifikate in der Vertrauenskette stimmt die Subject Key Identifier (SKID) des übergeordneten Zertifikats mit der Authority Key Identifier (AKID) im untergeordneten Zertifikat überein. Diese Übereinstimmung bestätigt, dass das untergeordnete Zertifikat von der richtigen Stammzertifizierungsstelle ausgestellt wurde und dass es vertrauenswürdig ist, da der öffentliche Schlüssel des Stamms in der AKID referenziert wird, um die Gültigkeit des Zertifikats zu überprüfen.

  3. Verbindung zum Backend herstellen

    Wenn die Zertifikatsprüfung erfolgreich ist, stellt der Load-Balancer die Verbindung zum Backend her.

    Wenn die Zertifikatsvalidierung jedoch fehlschlägt, beendet der Load Balancer die Verbindung zum Backend, sendet den HTTP-Statuscode 502 an den Client und protokolliert den Grund für die Beendigung in Cloud Logging. Bei einem Zertifikatsvalidierungsfehler veranlassen nachfolgende eingehende Anfragen den Load-Balancer, die Backend-Verbindung neu zu initiieren.

    Die Backend-Verbindung kann auch fehlschlagen, wenn der Backend-Server die Verbindung ablehnt. Bei Backend-mTLS kann dies passieren, weil das Clientzertifikat als ungültig erkannt wird. Wenn die Verbindung zum Backend fehlschlägt, antwortet der Load Balancer auf weitergeleitete Anfragen mit dem HTTP-Statuscode 502 und protokolliert einen allgemeinen Fehlergrund in Cloud Logging.

Fehlerbehandlung und Logging

Application Load Balancers bieten detaillierte Protokollierungsfunktionen, mit denen Sie die Validierung von Serverzertifikaten überwachen, potenzielle Probleme erkennen und Verbindungsprobleme beheben können. In diesem Abschnitt werden die verschiedenen Arten von Fehlern beschrieben, die bei der mTLS-Validierung auftreten können, und wie sie protokolliert werden.

Wenn die Validierung des Serverzertifikats fehlschlägt, wird die Verbindung beendet und die Fehler werden in Cloud Logging protokolliert. Diese Fehler werden in der folgenden Tabelle beschrieben.

Status des Serverzertifikats Protokollierter Fehler
Die Serverzertifikatskette ist zu lang (mehr als 10 Zwischenzertifikate, die im Serverzertifikat enthalten sind). server_cert_chain_exceeded_limit

Ein Server- oder Zwischenzertifikat hat eine ungültige RSA-Schlüsselgröße.

Es wird keine Validierung durchgeführt.

RSA-Schlüssel können von 2.048 bis 4.096 Bit lang sein.

 server_cert_invalid_rsa_key_size

Ein Server oder ein Zwischenzertifikat verwendet eine nicht unterstützte elliptische Kurve.

Es wird keine Validierung durchgeführt.

Gültige Kurven sind P-256 und P-384.

 server_cert_unsupported_elliptic_curve_key

Ein Server- oder Zwischenzertifikat verwendet einen Nicht-RSA- oder Nicht-ECDSA-Algorithmus.

Es wird keine Validierung durchgeführt.

 server_cert_unsupported_key_algorithm

Die für die Validierung zu verwendende PKI hat mehr als zehn Zwischenzertifikate, die dieselben Subject- und Subject Public-Key-Informationen haben.

Es wird keine Validierung durchgeführt.

 server_cert_pki_too_large

Ein Zwischenzertifikat zur Validierung hatte mehr als 10 Namenseinschränkungen.

server_cert_chain_max_name_constraints_exceeded

Das Serverzertifikat hat ein Erweiterungsfeld Extended Key Usage (EKU), das jedoch nicht serverAuth enthält.

server_cert_chain_invalid_eku
Das Zeitlimit wurde beim Prüfen der Zertifikatskette überschritten. server_cert_validation_timed_out

Das Limit für die Tiefe oder Iteration wurde beim Prüfen der Zertifikatskette erreicht.

Die maximale Tiefe für eine Zertifikatskette beträgt zehn, einschließlich der Root- und Serverzertifikate. Die maximale Anzahl der Iterationen beträgt 100 (Zertifikate, die zur Validierung der Serverzertifikatskette geprüft werden).

 server_cert_validation_search_limit_exceeded

Sie haben mTLS konfiguriert, ohne eine TrustConfig-Ressource einzurichten.

 server_cert_validation_not_performed

Der Server hat das angeforderte Zertifikat während des Handshakes nicht bereitgestellt.

 server_cert_not_provided

Das Serverzertifikat schlägt für die Validierung der Ressource TrustConfig fehl.

 ssl_certificate_verification_failed

Der Dienst kann die Zertifikatskette nicht validieren.

 server_cert_validation_unavailable
Interner Fehler beim Validieren der Zertifikatskette. server_cert_validation_internal_error

Kein passende TrustConfig gefunden.

 server_cert_trust_config_not_found
Die Nutzlast des Clientzertifikats (einschließlich Zwischenzertifikaten) ist zu groß (über 16 KB). server_cert_exceeded_size_limit

Beschränkungen

  • Gegenseitiges TLS für Backends mit verwalteter Arbeitslastidentität kann nur für globale externe Application Load Balancer konfiguriert werden. Klassische Application Load Balancer unterstützen kein Backend-mTLS.

  • Backend-mTLS wird für globale Internet-NEG-Backends nicht unterstützt.

  • Wenn Sie dem Backend-Dienst eine verwaltete Identität zuweisen (backendService.tlsSettings.identity), können Sie die folgenden Felder in der Eigenschaft tlsSettings des Backend-Dienstes nicht manuell festlegen:

    • backendService.tlsSettings.sni
    • backendService.tlsSettings.subjectAltNames
    • backendService.tlsSettings.authenticationConfig

  • Eine verwaltete Identität kann nur beim Erstellen des Backend-Dienstes zugewiesen werden.

  • Verwaltete Identitäten sind unveränderlich. Nachdem Sie dem Backend-Dienst des Load-Balancers eine verwaltete Identität zugewiesen haben, kann diese nicht mehr aktualisiert oder gelöscht werden.

Nächste Schritte