Backend-mTLS mit verwalteter Arbeitslastidentität – Übersicht

Sie können Backend-mTLS mit oder ohne verwaltete Arbeitslastidentität erreichen. Weitere Informationen zu Backend-mTLS ohne verwaltete Arbeitslastidentität finden Sie unter Backend-authentifiziertes TLS und Backend-mTLS.

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.

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.
Back-End-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:

  • Erhöhte Sicherheit: Wenn Sie einem Workload Identity-Pool beitreten, werden ein Google Cloud Loadbalancer 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 während 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 diese 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 Mikroservices basierenden Architekturen ermöglicht.

  • Zentrale Governance: 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.

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)
  • Vom Zertifikatmanager verwaltetes Identitätszertifikat (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-Konfigurationsressource für die Zertifikatausstellung und eine Inline-Konfigurationsressource für die Vertrauenskonfiguration erforderlich.
  3. Konfigurieren Sie den Backend-Dienst des Load Balancers mit der verwalteten Identität.
  4. Mit der verwalteten Arbeitslastidentität werden automatisch das von Certificate Manager verwaltete Identitätszertifikat und die von Certificate Manager verwaltete Vertrauenskonfiguration erstellt.

    Das vom Certificate Manager verwaltete Identitätszertifikat wird auf Grundlage der Konfiguration der Zertifikatsausstellung im Workload Identity-Pool erstellt. Die Vertrauenskonfiguration des Certificate Managers 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 vom Certificate Manager 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 Konfiguration von Backend-mTLS mit verwalteter Identität finden Sie unter Backend-mTLS mit verwalteter Workload Identity einrichten.

Backend-mTLS mit verwalteter Arbeitslastidentität.
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 wurden

Wie im vorherigen Architekturdiagramm dargestellt, müssen Sie beim Zuweisen einer verwalteten Identität zum Backend-Dienst die Backend-Authentifizierungskonfiguration, die Certificate Manager-Vertrauenskonfiguration und das Certificate Manager-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 der Fokus auf die Ressourcen gelegt, 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.

Verwaltete Arbeitslastidentität

Sie müssen eine verwaltete Arbeitslastidentität im Namespace des Workload Identity-Pools erstellen. Die verwaltete Identität ist eine vollständig angegebene SPIFFE-ID, die im SVID verwendet wird, das von der Load-Balancer-Arbeitslast präsentiert wird.

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, die dem Backend-Dienst zugewiesen ist.

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 Attestrichtlinie erfolgreich war.

Inline-Konfiguration für Vertrauensbeziehungen des Workload Identity-Pools

Standardmäßig können sich Ihre Arbeitslasten innerhalb derselben vertrauenswürdigen Domain gegenseitig mit verwalteten Workload Identities authentifizieren. Wenn Sie möchten, dass sich Arbeitslasten in verschiedenen vertrauenswürdigen Domains 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 Vertrauensstellungsdomains 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-Vertrauenskonfiguration enthält eine Reihe von Vertrauensankern, die von der verwalteten Workload-Identität zum Validieren von Peer-Zertifikaten verwendet werden. Die Certificate Manager-Vertrauenskonfiguration enthält einen SPIFFE-Vertrauensspeicher, 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 Stammzertifikaten desselben CA-Pools. Sie müssen die CA-Roots des Pools nicht der Inline-Vertrauenskonfiguration hinzufügen, da das Vertrauen bereits integriert ist.

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 Back-End-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.

Zum Validieren von SPIFFE-Zertifikaten wird das Feld spiffeTrustStores in der Certificate Manager-Vertrauenskonfiguration automatisch aktiviert, wenn eine verwaltete Arbeitslastidentität verwendet wird. 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 so konfiguriert werden, dass er Truststores aus mehreren unterschiedlichen Sicherheitsbereichen vertraut. Wenn ein Backend sein Zertifikat präsentiert, extrahiert der Load-Balancer die SPIFFE-ID, ermittelt die Vertrauensdomäne und verwendet die Zuordnung, um den richtigen Trust Store zu finden, der zum Validieren des Zertifikats erforderlich ist.

Vom Zertifikatmanager verwaltetes Identitätszertifikat (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 Certificate Manager verwaltete Identitätszertifikat hat die Eigenschaft managedIdentity, die es als Zertifikat für verwaltete Identitäten kennzeichnet. In der von Certificate Manager verwalteten Identitätszertifikatsressource 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 Certificate Manager 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.

Beschränkungen

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

  • Gegenseitiges TLS für Backends 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