Authentifizierung von verwalteten Arbeitslastidentitäten für GKE konfigurieren

In diesem Dokument wird beschrieben, wie Sie verwaltete Arbeitslastidentitäten für Google Kubernetes Engine (GKE) in Ihren von Flotten verwalteten GKE-Clustern konfigurieren. Außerdem wird beschrieben, wie Sie eine Arbeitslast bereitstellen und die Identität und das Zertifikat der Arbeitslast überprüfen.

Führen Sie die folgenden Schritte aus, um verwaltete Arbeitslastidentitäten für GKE einzurichten und zu verwenden:

  1. Option für die Zertifizierungsstelle (CA) auswählen

  2. Zertifizierungsstelle konfigurieren

  3. Arbeitslasten mit verwalteten Arbeitslastidentitäten bereitstellen

  4. Optional: Vertrauenswürdige Föderation zwischen Pools von Arbeitslastidentitäten aktivieren

Von Google verwalteter Workload Identity-Pool

Wenn Sie GKE-Flotten Cluster hinzufügen, erstellt GKE automatisch einen von Google verwalteten Workload Identity-Pool, der als Root of Trust (auch als SPIFFE-Vertrauensdomain für Ihre Arbeitslasten bezeichnet) dient. Alle Arbeitslasten innerhalb der Vertrauensdomäne erhalten Zertifikate und Trust-Anchors, die standardmäßig die Authentifizierung innerhalb der Vertrauensdomäne ermöglichen. Wenn Sie mehrere Vertrauensdomänen haben, können Sie die Vertrauensföderation aktivieren, um die Kommunikation zwischen den Vertrauensdomänen zu ermöglichen.

Der von Google verwaltete Workload Identity-Pool hat die folgenden Eigenschaften:

  • Identitätsverwaltung:Google verwaltet den Pool vollständig. Sie können keine untergeordneten Ressourcen wie Namespaces, Identitäten oder Identitätsanbieter erstellen.

  • Unterstützung von Arbeitslasten:Sie können den Pool nur für GKE-Arbeitslasten verwenden. Sie können dem Pool keine anderen Arten von Arbeitslasten wie Compute Engine-VMs hinzufügen.

  • Flottenintegration:Für alle Cluster im Pool gilt das standardmäßige Kubernetes-Modell für die Namespace-Gleichheit. Das bedeutet, dass alle Cluster im Pool gleichberechtigt sind und Workloads in jedem Cluster im Pool jede Identität in diesem Pool verwenden können.

Selbstverwalteter Workload Identity-Pool

In Umgebungen mit unterschiedlichen Vertrauensstufen, z. B. in Multi-Tenant-Flotten, können Sie einen separaten selbstverwalteten Workload Identity-Pool für eine Teilmenge Ihrer Arbeitslasten und Cluster konfigurieren. Ein selbstverwalteter Workload Identity-Pool hat die folgenden Merkmale:

  • Identitätsverwaltung:Wenn Sie einen eigenen Workload Identity-Pool definieren, haben Sie die vollständige Kontrolle über die Identitätsverwaltung im Pool. Unter dem Pool können Sie Ihre eigene Identitätshierarchie definieren, z. B. Namespaces und Identitäten. Sie können Attestierungsrichtlinien definieren, um festzulegen, welche Arbeitslasten Identitäten unter dem Pool oder den Namespaces bestätigen können.

  • Unterstützung von Arbeitslasten:Alle Arbeitslasten (z. B. VMs, Container und serverlose Arbeitslasten) können im Pool platziert werden.

  • Flottenintegration:Für Arbeitslasten, die von GKE-Flotten verwaltet werden, bieten Flotten eine integrierte Schnittstelle zum Verwalten von Identitäten. Sie können Ihren Workload Identity-Pool als Mandantenpool für den Flottenbereich konfigurieren. In Flotten werden automatisch Namespaces für Workload Identity-Pools erstellt, die den Flotten-Namespaces entsprechen, und Identitäten werden den Arbeitslasten zugewiesen.

Wenn Sie einen selbstverwalteten Workload Identity-Pool verwenden möchten, müssen Sie Funktionen zur Verwaltung von Flottenteams wie Teambereiche und Flotten-Namespaces konfigurieren und den selbstverwalteten Pool als Pool für die Bereichsmandanten einrichten. Eine Anleitung zum Erstellen und Konfigurieren eines selbstverwalteten Pools finden Sie unter Über Workloads der Flotte mit unterschiedlichen Vertrauensstufen bei Google Cloud -APIs authentifizieren.

Konfiguration mehrerer Projekte

DieGoogle Cloud -Ressourcen, die Sie in diesem Dokument verwenden, z. B. GKE-Cluster, die Stamm-CA und untergeordnete CAs, können in separaten Projekten vorhanden sein. Wenn Sie auf diese Ressourcen verweisen, verwenden Sie das Flag --project, um das richtige Projekt für jede Ressource anzugeben.

Hinweis

  1. Erstellen Sie ein Google Cloud Projekt oder wählen Sie eines aus.

    Rollen, die zum Auswählen oder Erstellen eines Projekts erforderlich sind

    • Projekt auswählen: Für die Auswahl eines Projekts ist keine bestimmte IAM-Rolle erforderlich. Sie können jedes Projekt auswählen, für das Ihnen eine Rolle zugewiesen wurde.
    • Projekt erstellen: Zum Erstellen eines Projekts benötigen Sie die Rolle „Projektersteller“ (roles/resourcemanager.projectCreator), die die Berechtigung resourcemanager.projects.create enthält. Weitere Informationen zum Zuweisen von Rollen

    • So erstellen Sie ein Google Cloud -Projekt:

      gcloud projects create PROJECT_ID

      Ersetzen Sie PROJECT_ID durch einen Namen für das Google Cloud -Projekt, das Sie erstellen.

    • Wählen Sie das von Ihnen erstellte Google Cloud Projekt aus:

      gcloud config set project PROJECT_ID

      Ersetzen Sie PROJECT_ID durch den Namen Ihres Projekts in Google Cloud .

  2. Verwaltete Arbeitslastidentitäten

  3. Ihre Cluster müssen Version 1.33.0-gke.2248000 oder höher ausführen.

  4. Fügen Sie Ihre Cluster GKE-Flotten hinzu. Wenn es sich bei Ihrem Cluster um einen Autopilot-Cluster handelt, lassen Sie das Flag --enable-workload-identity weg. In Flotten wird automatisch ein von Google verwalteter Workload Identity-Pool erstellt, der als vertrauenswürdige Domain dient.

    Aktivieren Sie GKE-Flotten mit dem folgenden Befehl:

    gcloud container clusters update CLUSTER_NAME \
--workload-pool=PROJECT_ID.svc.id.goog \
--enable-fleet \
--fleet-project=PROJECT_ID

    Ersetzen Sie diese Werte:

    • CLUSTER_NAME: der Name des GKE-Clusters, der bei der GKE-Flotte registriert werden soll
    • PROJECT_ID: die Projekt-ID des GKE-Hostprojekts der Flotte

  5. Aktivieren Sie die IAM API und die Certificate Authority Service API.

    Rollen, die zum Aktivieren von APIs erforderlich sind

    Zum Aktivieren von APIs benötigen Sie die IAM-Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin), die die Berechtigung serviceusage.services.enable enthält. Weitere Informationen zum Zuweisen von Rollen

    APIs aktivieren

  6. Konfigurieren Sie die Google Cloud CLI so, dass Ihr Abrechnungs- und Kontingentprojekt verwendet wird.

    gcloud config set billing/quota_project PROJECT_ID

    Ersetzen Sie PROJECT_ID durch die ID des Flottenprojekts.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für das Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Erstellen verwalteter Workload-Identitäten und zum Bereitstellen von Zertifikaten für verwaltete Workload-Identitäten benötigen:

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.

CA-Option auswählen

Wählen Sie zum Signieren Ihrer Arbeitslastzertifikate die Option für die Zertifizierungsstelle (Certificate Authority, CA) aus, die am besten zu Ihrem Anwendungsfall passt:

  • Von Google verwaltete Standard-CA: Verwenden Sie diese Option für eine vollständig verwaltete, kostenlose Lösung. Die Standard-Zertifizierungsstelle bietet eine gemeinsame Root of Trust für alleGoogle Cloud -Nutzer.

  • Benutzerdefinierte Zertifizierungsstelle: Mit dieser Option können Sie Ihre eigene Public-Key-Infrastruktur (PKI) über den Certificate Authority Service konfigurieren. Diese Option ist geeignet, wenn Sie einen benutzerdefinierten Root of Trust benötigen oder wenn Sie Signierschlüssel in einem Hardwaresicherheitsmodul (HSM) speichern müssen, um Compliance-Anforderungen zu erfüllen. Certificate Authority Service wird separat von der verwalteten Arbeitslastidentität abgerechnet. Weitere Informationen finden Sie unter CA Service – Preise.

CA konfigurieren

Standard-Zertifizierungsstelle

Wenn Sie die Standard-Zertifizierungsstelle an den Workload Identity-Pool binden möchten, aktualisieren Sie den Workload Identity-Pool mit dem Flag use-default-shared-ca.

  gcloud iam workload-identity-pools update TRUST_DOMAIN_NAME \
      --location="global" \
      --use-default-shared-ca \
      --project=PROJECT_ID

Ersetzen Sie Folgendes:

  • TRUST_DOMAIN_NAME:

    Der Name der vertrauenswürdigen Domain. Formatieren Sie den Namen je nach Pooltyp so:

    • Von Google verwalteter Pool:PROJECT_ID.svc.id.goog
    • Selbstverwalteter Pool:POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog
  • PROJECT_ID: Die Projekt-ID Ihres Flotten-Hostprojekts.

Benutzerdefinierte CA

  1. CA Service so konfigurieren, dass Zertifikate für verwaltete Arbeitslastidentitäten ausgestellt werden
  2. Binden Sie die Zertifizierungsstellen an den Workload Identity-Pool.
  3. Verwaltete Arbeitslastidentitäten autorisieren, um Zertifikate vom CA-Pool anzufordern

CA Service so konfigurieren, dass Zertifikate für verwaltete Arbeitslastidentitäten ausgestellt werden

Wenn Sie verwaltete Arbeitslastidentitäten für GKE konfigurieren möchten, müssen Sie zuerst eine Zertifizierungsstelle (Certificate Authority, CA) und eine oder mehrere untergeordnete CAs konfigurieren. Diese Konfiguration wird als Zertifizierungsstellen-Hierarchie bezeichnet.

Sie können CA-Service-Pools verwenden, um diese Hierarchie einzurichten. In dieser Hierarchie stellt der untergeordnete CA-Pool die X.509-Zertifikate für Arbeitslastidentitäten für Ihre Arbeitslasten aus.

Die CA-Pools, die zum Ausstellen von Zertifikaten für Arbeitslasten mit verwalteten Arbeitslastidentitäten konfiguriert sind, müssen sich in derselben Region wie die Arbeitslast befinden. Wenn Sie eine multiregionale Architektur für Ausfallsicherheit gegen regionale Ausfälle entwerfen möchten, empfehlen wir, für jede Region, in der Sie Arbeitslasten ausführen, einen untergeordneten CA-Pool für den Certificate Authority Service zu konfigurieren. So kann jede Ihrer Arbeitslasten auf einen untergeordneten CA-Pool des Certificate Authority Service in der Region verweisen.

Stamm-CA-Pool konfigurieren

So erstellen Sie den Root-Zertifizierungsstellen-Pool:

Erstellen Sie den Stamm-CA-Pool im Enterprise-Tarif mit gcloud privateca pools create. Diese Ebene ist für die langlebige Ausgabe von Zertifikaten mit geringem Volumen vorgesehen.

gcloud privateca pools create ROOT_CA_POOL_ID \
    --location=REGION \
    --project=CA_PROJECT_ID \
    --tier=enterprise

Ersetzen Sie Folgendes:

  • ROOT_CA_POOL_ID: Eine eindeutige ID für den Root-CA-Pool. Die ID darf bis zu 64 Zeichen lang sein und darf nur alphanumerische Zeichen in Groß- und Kleinschreibung, Unterstriche oder Bindestriche enthalten. Die Pool-ID muss innerhalb der Region eindeutig sein.

  • REGION: Die Region, in der sich der Stamm-CA-Pool befindet.

  • CA_PROJECT_ID: Die Projekt-ID, in der Sie die Stammzertifizierungsstelle erstellen möchten.

Weitere Informationen zu CA-Pools, ‑Stufen und ‑Regionen finden Sie unter CA-Pools erstellen.

Stamm-CA konfigurieren

Erstellen Sie mit gcloud privateca roots create eine Stamm-Zertifizierungsstelle im Stamm-Zertifizierungsstellen-Pool. Sie werden möglicherweise aufgefordert, die Stamm-CA zu aktivieren, wenn dies die einzige CA im Stamm-CA-Pool ist.

Führen Sie den folgenden Befehl aus, um eine Stamm-Zertifizierungsstelle zu erstellen:

gcloud privateca roots create ROOT_CA_ID \
    --pool=ROOT_CA_POOL_ID \
    --subject="CN=ROOT_CA_CN, O=ROOT_CA_ORGANIZATION" \
    --key-algorithm="KEY_ALGORITHM" \
    --max-chain-length=1 \
    --location=REGION \
    --project=CA_PROJECT_ID \
    --auto-enable

Ersetzen Sie Folgendes:

  • ROOT_CA_ID: Ein eindeutiger Name für die Stammzertifizierungsstelle. Der Name der Zertifizierungsstelle darf bis zu 64 Zeichen lang sein und darf nur alphanumerische Zeichen in Groß- und Kleinschreibung, Unterstriche oder Bindestriche enthalten. Der Name der Zertifizierungsstelle muss innerhalb der Region eindeutig sein.
  • ROOT_CA_POOL_ID: Die ID des Stammzertifizierungsstellen-Pools.
  • ROOT_CA_CN: Der Name der Stammzertifizierungsstelle.
  • ROOT_CA_ORGANIZATION: Die Organisation der Stamm-CA.
  • KEY_ALGORITHM: Der Schlüsselalgorithmus, z. B. ec-p256-sha256.
  • REGION: Die Region, in der sich der Stamm-CA-Pool befindet.
  • CA_PROJECT_ID: Die Projekt-ID, in der Sie die Stammzertifizierungsstelle erstellt haben.

Weitere Informationen zu den subject-Feldern für die Zertifizierungsstelle finden Sie unter Inhaber.

Optional können Sie zusätzliche Root-Zertifizierungsstellen in Ihrem Root-CA-Pool erstellen. Das kann bei der Rotation der Stammzertifizierungsstelle hilfreich sein.

Untergeordnete Zertifizierungsstellen konfigurieren

Optional können Sie untergeordnete CAs konfigurieren. Die Konfiguration untergeordneter Zertifizierungsstellen kann in folgenden Fällen hilfreich sein:

  • Mehrere Szenarien für die Zertifikatausstellung: Wenn Sie mehrere Szenarien für die Zertifikatausstellung haben, können Sie für jedes Szenario eine untergeordnete CA erstellen.

  • Besseres Load Balancing: Wenn Sie einem CA-Pool mehrere untergeordnete CAs hinzufügen, können Sie ein besseres Load Balancing von Zertifikatsanfragen erreichen.

So erstellen Sie einen untergeordneten CA-Pool und eine untergeordnete CA:

  1. Erstellen Sie den untergeordneten CA-Pool auf der Ebene DevOps, die für die Ausstellung von kurzlebigen Zertifikaten mit hohem Volumen vorgesehen ist.

    gcloud privateca pools create SUBORDINATE_CA_POOL_ID \
    --location=REGION \
    --project=CA_PROJECT_ID \
    --tier=devops

    Ersetzen Sie Folgendes:

    • SUBORDINATE_CA_POOL_ID: Eine eindeutige ID für den untergeordneten CA-Pool. Die ID darf bis zu 64 Zeichen lang sein und darf nur alphanumerische Zeichen in Groß- und Kleinschreibung, Unterstriche oder Bindestriche enthalten. Die Pool-ID muss innerhalb der Region eindeutig sein.
    • REGION: Die Region, in der der untergeordnete CA-Pool erstellt werden soll.
    • CA_PROJECT_ID: Die ID des Projekts, in dem Sie die untergeordnete CA erstellt haben.

    Weitere Informationen finden Sie unter CA-Pools erstellen.

  2. Erstellen Sie eine untergeordnete CA im untergeordneten CA-Pool. Ändern Sie den konfigurationsbasierten Standardausstellungsmodus nicht.

    gcloud privateca subordinates create SUBORDINATE_CA_ID \
    --pool=SUBORDINATE_CA_POOL_ID \
    --location=REGION \
    --issuer-pool=ROOT_CA_POOL_ID \
    --issuer-location=REGION \
    --subject="CN=SUBORDINATE_CA_CN, O=SUBORDINATE_CA_ORGANIZATION" \
    --key-algorithm="KEY_ALGORITHM" \
    --use-preset-profile=subordinate_mtls_pathlen_0 \
    --project=CA_PROJECT_ID \
    --auto-enable

    Ersetzen Sie Folgendes:

    • SUBORDINATE_CA_ID: Ein eindeutiger Name für die untergeordnete CA. Der Name darf bis zu 64 Zeichen lang sein und darf nur alphanumerische Zeichen in Groß- und Kleinschreibung, Unterstriche oder Bindestriche enthalten. Der Poolname muss innerhalb der Region eindeutig sein.
    • SUBORDINATE_CA_POOL_ID: Der Name des untergeordneten CA-Pools.
    • REGION: Die Region, in der sich der untergeordnete CA-Pool befindet.
    • ROOT_CA_POOL_ID: Die ID des Stammzertifizierungsstellen-Pools.
    • REGION: Die Region des Stamm-CA-Pools.
    • SUBORDINATE_CA_CN: Der Name der untergeordneten CA.
    • SUBORDINATE_CA_ORGANIZATION: Der Name der Organisation, die die untergeordnete CA ausstellt.
    • KEY_ALGORITHM: Der Schlüsselalgorithmus, z. B. ec-p256-sha256.
    • CA_PROJECT_ID: Die ID des Projekts, in dem Sie die untergeordnete CA erstellt haben.

    Weitere Informationen zu den subject-Feldern für die Zertifizierungsstelle finden Sie unter Inhaber.

Konfigurationsdatei für die Zertifikatsausstellung erstellen

Um CAs an Workload Identity-Pools zu binden, ist eine Konfiguration für die Zertifikatausstellung erforderlich. Wenn Ihre Arbeitslasten in mehreren vertrauenswürdigen Domains authentifiziert werden müssen, lesen Sie den Abschnitt Vertrauenswürdige Föderation zwischen Workload Identity-Pools aktivieren (optional).

Um die Konfiguration der Zertifikatsausstellung zu konfigurieren, erstellen Sie eine Konfigurationsdatei für die Zertifikatsausstellung mit dem Namen cic.json. Das Format der Datei sieht in etwa so aus:

{
  "inlineCertificateIssuanceConfig": {
      "caPools": {
        "REGION1": "projects/CA_PROJECT_NUMBER1/locations/REGION1/caPools/SUBORDINATE_CA_POOL_ID1",
        "REGION2": "projects/CA_PROJECT_NUMBER2/locations/REGION2/caPools/SUBORDINATE_CA_POOL_ID2"
      },
      "lifetime": "DURATION",
      "rotationWindowPercentage": ROTATION_WINDOW_PERCENTAGE,
      "keyAlgorithm": "ALGORITHM"
  }
}

Ersetzen Sie Folgendes:

  • REGION: Die Regionen, in denen sich die Zertifizierungsstellen befinden.

  • CA_PROJECT_NUMBER: Die Projektnummer des Projekts, in dem Sie den untergeordneten CA-Pool erstellt haben. Führen Sie den folgenden Befehl aus, um die Projektnummer des Projekts CA_PROJECT_ID abzurufen:

    gcloud projects describe CA_PROJECT_ID --format="value(projectNumber)"

  • SUBORDINATE_CA_POOL_ID: Der Name des untergeordneten CA-Pools.

  • ALGORITHM: Optional. Der Verschlüsselungsalgorithmus, der zum Generieren des privaten Schlüssels verwendet wird. Gültige Werte sind ECDSA_P256, ECDSA_P384, RSA_2048, RSA_3072 und RSA_4096. Wenn nichts angegeben ist, wird ECDSA_P256 als Standardalgorithmus verwendet.

  • DURATION: Optional. Die Gültigkeitsdauer des Blattzertifikats in Sekunden. Der Wert muss zwischen 86.400 (1 Tag) und 2.592.000 (30 Tage) liegen. Wenn nicht angegeben, wird der Standardwert 86.400 (1 Tag) verwendet. Die tatsächliche Gültigkeit des ausgestellten Zertifikats hängt auch von der ausstellenden Zertifizierungsstelle ab, da diese die Lebensdauer des ausgestellten Zertifikats einschränken kann.

  • ROTATION_WINDOW_PERCENTAGE (optional): Der Prozentsatz der Zertifikatslebensdauer, bei dem eine Verlängerung ausgelöst wird. Der Wert muss zwischen 50 und 80 liegen. Wenn nicht angegeben, wird 50 als Standardwert verwendet.

Zertifizierungsstellen an den Workload Identity-Pool binden

Nachdem Sie die CA-Hierarchie und Konfigurationen für die Zertifikatausstellung für jede CA erstellt haben, binden Sie die CAs an den Workload Identity-Pool. Wenn Sie eine CA an den Workload Identity-Pool binden möchten, aktualisieren Sie den Workload Identity-Pool mit der Konfiguration der Zertifikatausstellung der CA. Anschließend können Sie prüfen, ob der Pool aktualisiert wurde.

Workload Identity-Pool aktualisieren

Führen Sie den folgenden Befehl aus, um den Pool zu aktualisieren:

gcloud iam workload-identity-pools update TRUST_DOMAIN_NAME \
    --location="global" \
    --inline-certificate-issuance-config-file=CIC_JSON_FILE_PATH \
    --project=PROJECT_ID

Ersetzen Sie Folgendes:

  • TRUST_DOMAIN_NAME: Der Name der Vertrauensdomäne. Formatieren Sie den Namen je nach Pooltyp so:

    • Von Google verwalteter Pool:PROJECT_ID.svc.id.goog
    • Selbstverwalteter Pool:POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog

  • CIC_JSON_FILE_PATH: Der Pfad zur JSON-formatierten Konfigurationsdatei für die Zertifikatausstellung (cic.json), die Sie zuvor erstellt haben.

Prüfen, ob der Workload Identity-Pool aktualisiert wurde

Führen Sie den folgenden Befehl aus, um zu prüfen, ob Ihr Workload Identity-Pool mit der Konfiguration für die Zertifikatausstellung aktualisiert wurde:

gcloud iam workload-identity-pools describe TRUST_DOMAIN_NAME \
    --location="global" \
    --project=PROJECT_ID

Ersetzen Sie TRUST_DOMAIN_NAME durch den Namen der Vertrauensdomäne, die Sie zuvor in diesem Dokument zum Aktualisieren des Workload Identity-Pools verwendet haben.

Die entsprechende Ausgabe sieht etwa so aus:

inlineCertificateIssuanceConfig:
    caPools:
      REGION1: projects/PROJECT_NUMBER1/locations/REGION1/caPools/SUBORDINATE_CA_POOL_ID1,
      REGION2: projects/PROJECT_NUMBER2/locations/REGION2/caPools/SUBORDINATE_CA_POOL_ID2
    keyAlgorithm: ALGORITHM
    lifetime: DURATION
    rotationWindowPercentage: ROTATION_WINDOW_PERCENTAGE
mode: TRUST_DOMAIN
name: TRUST_DOMAIN_NAME
state: ACTIVE

Wenn inlineCertificateIssuanceConfig in der Befehlsausgabe nicht vorhanden ist, prüfen Sie, ob Sie die gcloud CLI korrekt konfiguriert haben, um das richtige Projekt für Abrechnung und Kontingent zu verwenden. Möglicherweise müssen Sie auf eine neuere Version der gcloud CLI aktualisieren.

Verwaltete Arbeitslastidentitäten autorisieren, um Zertifikate vom CA-Pool anzufordern

Nachdem Sie die CAs an den Workload Identity-Pool gebunden haben, autorisieren Sie verwaltete Arbeitslastidentitäten, Zertifikate vom CA-Pool anzufordern. So autorisieren Sie diese Identitäten:

  1. Weisen Sie der Vertrauenswürdigkeitsdomain die IAM-Rolle Anfragesteller des CA Service-Arbeitslastzertifikats (roles/privateca.workloadCertificateRequester) für jeden untergeordneten CA-Pool zu. Mit dem folgenden gcloud privateca pools add-iam-policy-binding-Befehl wird die Vertrauensdomäne autorisiert, Zertifikate von den CA Service-Zertifikatsketten anzufordern.

    gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_ID \
    --location=REGION \
    --role=roles/privateca.workloadCertificateRequester \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/name/locations/global/workloadIdentityPools/TRUST_DOMAIN_NAME" \
    --project=CA_PROJECT_ID

    Ersetzen Sie Folgendes:

    • SUBORDINATE_CA_POOL_ID: Die ID des untergeordneten CA-Pools.
    • REGION: Die Region des untergeordneten CA-Pools.

    • PROJECT_NUMBER: Die Projektnummer des Projekts, das den GKE Workload Identity-Pool enthält.

      Führen Sie den folgenden Befehl aus, um PROJECT_NUMBER aus Ihrem Workload Identity-Pool-Projekt abzurufen.

      gcloud projects describe WORKLOAD_IDENTITY_POOL_PROJECT_ID --format="value(projectNumber)"

    • WORKLOAD_IDENTITY_POOL_PROJECT_ID: Die Projekt-ID des Projekts, das den Workload Identity-Pool enthält.

    • TRUST_DOMAIN_NAME: Der Name der Vertrauensdomäne. Formatieren Sie den Namen je nach Pooltyp so:

      • Von Google verwalteter Pool:PROJECT_ID.svc.id.goog
      • Selbstverwalteter Pool:POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog

    • CA_PROJECT_ID: Die ID des Projekts, in dem Sie die untergeordnete CA erstellt haben.

  2. Weisen Sie der verwalteten Arbeitslastidentität die Rolle CA Service Pool Reader (roles/privateca.poolReader) für die untergeordneten CA-Pools zu. Dadurch wird die verwaltete Arbeitslastidentität autorisiert, die signierten X.509-Zertifikate aus den Zertifikatsketten der Zertifizierungsstelle abzurufen.

    gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_ID \
    --location=REGION \
    --role=roles/privateca.poolReader \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/name/locations/global/workloadIdentityPools/TRUST_DOMAIN_NAME" \
    --project=CA_PROJECT_ID

    Ersetzen Sie Folgendes:

    • SUBORDINATE_CA_POOL_ID: Die ID des untergeordneten CA-Pools.
    • REGION: Die Region des untergeordneten CA-Pools.
    • PROJECT_NUMBER: die Projektnummer des Projekts, das den GKE Workload Identity-Pool enthält.
    • TRUST_DOMAIN_NAME: Der Name der Vertrauensdomäne. Je nach Pooltyp formatieren Sie den Namen so:
      • Von Google verwalteter Pool:PROJECT_ID.svc.id.goog
      • Selbstverwalteter Pool:POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog
    • CA_PROJECT_ID: Die ID des Projekts, in dem Sie die untergeordnete CA erstellt haben.

Arbeitslasten mit verwalteten Arbeitslastidentitäten bereitstellen

Nachdem Sie Ihre CA-Pools so konfiguriert haben, dass sie Zertifikate für verwaltete Arbeitslastidentitäten ausstellen, können Sie Arbeitslasten mit verwalteten Arbeitslastidentitäten bereitstellen.

In diesem Abschnitt wird gezeigt, wie Sie eine Testarbeitslast mit einer verwalteten Arbeitslastidentität bereitstellen. Dazu stellen Sie einen Pod bereit, prüfen, ob Anmeldedaten generiert wurden, und sehen sich das Zertifikat und die SPIFFE-ID an.

Pod bereitstellen

Sie können einen Pod bereitstellen, dessen verwaltete Arbeitslastidentität aus einem von Google verwalteten oder einem selbstverwalteten Workload Identity-Pool stammt.

Von Google verwalteter Pool

So stellen Sie einen Test-Pod in Ihrem Cluster bereit:

  1. Rufen Sie die Clusteranmeldedaten ab.

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CLUSTER_ZONE \
    --project=CLUSTER_PROJECT_ID

  2. Erstellen Sie den Kubernetes-Namespace.

    kubectl create namespace KUBERNETES_NAMESPACE

  3. Stellen Sie eine Test-PodSpec bereit.

    cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  namespace: KUBERNETES_NAMESPACE
  name: example-pod
spec:
  containers:
  - name: main
    image: debian
    command: ['sleep', 'infinity']
    volumeMounts:
    - name: fleet-spiffe-credentials
      mountPath: /var/run/secrets/workload-spiffe-credentials
      readOnly: true
  nodeSelector:
    iam.gke.io/gke-metadata-server-enabled: "true"
  volumes:
  - name: fleet-spiffe-credentials
    csi:
      driver: podcertificate.gke.io
      volumeAttributes:
        signerName: spiffe.gke.io/fleet-svid
        trustDomain: fleet-project/svc.id.goog
EOF

Selbstverwalteter Pool

So stellen Sie einen Test-Pod in Ihrem Cluster mit einem selbstverwalteten Workload Identity-Pool bereit:

  1. Richten Sie einen selbstverwalteten Workload Identity-Pool ein und konfigurieren Sie die Flottencluster für die Verwendung dieses Pools.

  2. Rufen Sie die Clusteranmeldedaten ab.

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CLUSTER_ZONE \
    --project=CLUSTER_PROJECT_ID

  3. Erstellen Sie den Kubernetes-Namespace.

    kubectl create namespace KUBERNETES_NAMESPACE

  4. Stellen Sie eine Test-PodSpec bereit.

    Die folgende PodSpec konfiguriert das trustDomain-Volumenattribut für einen selbstverwalteten Workload Identity-Pool:

    cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  namespace: KUBERNETES_NAMESPACE
  name: example-pod
spec:
  containers:
  - name: main
    image: debian
    command: ['sleep', 'infinity']
    volumeMounts:
    - name: fleet-spiffe-credentials
      mountPath: /var/run/secrets/workload-spiffe-credentials
      readOnly: true
  nodeSelector:
    iam.gke.io/gke-metadata-server-enabled: "true"
  volumes:
  - name: fleet-spiffe-credentials
    csi:
      driver: podcertificate.gke.io
      volumeAttributes:
        signerName: spiffe.gke.io/fleet-svid
        trustDomain: fleet-project/tenancy-scope
EOF

Arbeitslastanmeldedaten auflisten

Führen Sie den folgenden Befehl aus, um die Anmeldedaten der Arbeitslast aufzulisten. Es kann einige Minuten dauern, bis die Anmeldedaten erstellt sind.

kubectl exec -it example-pod -n KUBERNETES_NAMESPACE -- ls  /var/run/secrets/workload-spiffe-credentials

In der Befehlsausgabe werden die folgenden Dateien aufgeführt:

  • ca_certificates.pem: Enthält das CA-Zertifikat der Stammzertifizierungsstelle, mit dem das Arbeitslastzertifikat signiert wird.
  • certificates.pem: Enthält das X.509-Zertifikat der Arbeitslast.
  • private_key.pem: Enthält den privaten Schlüssel der Arbeitslast.
  • trust_bundles.json: Enthält eine Zuordnung von Vertrauensdomänen und CA-Zertifikaten, die für die angegebene Arbeitslast vertrauenswürdig sind. Jeder Eintrag enthält den Trust-Domain-String als Schlüssel und die CA-Zertifikate, die dieser Trust-Domain entsprechen.
  • credential-bundle.pem: Enthält den privaten Schlüssel und das Zertifikat verkettet und stellt so eine einzelne Datei für mTLS-Anmeldedaten bereit. Diese Datei ist nur in GKE-Versionen nach 1.35.2-gke.1291000 verfügbar.

Zertifikat ansehen

So rufen Sie das Zertifikat auf:

  1. Exportieren Sie das Zertifikat in eine Zertifikatsdatei.

    kubectl exec -it example-pod --namespace=KUBERNETES_NAMESPACE -- cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -noout -text > certfile

  2. Sehen Sie sich die Zertifikatsdatei an.

    cat certfile

    Im Zertifikat sehen Sie im Attribut X509v3 Subject Alternative Name die SPIFFE-ID in einem Format, das je nach Typ des Workload Identity-Pools dem folgenden ähnelt:

    • Von Google verwalteter Pool:spiffe://PROJECT_ID.svc.id.goog/ns/KUBERNETES_NAMESPACE/sa/default
    • Selbstverwalteter Pool:spiffe://POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog/ns/KUBERNETES_NAMESPACE/sa/default

    default bezieht sich auf das Kubernetes-Standarddienstkonto.

Authentifizierung von Arbeitslasten testen

Informationen zum Testen der Authentifizierung zwischen Arbeitslasten finden Sie unter mTLS-Authentifizierung mit Go testen.

Im Beispielcode im Repository werden Client- und Server-Arbeitslasten erstellt. Sie können die gegenseitige Authentifizierung zwischen den Arbeitslasten mit den Zertifikaten testen, die Sie zuvor in diesem Dokument generiert haben.

Vertrauenswürdige Föderation zwischen Workload Identity-Pools aktivieren (optional)

Wenn Sie die gegenseitige Authentifizierung für Arbeitslasten in verschiedenen vertrauenswürdigen Domains aktivieren möchten, müssen Sie die Vertrauensföderation zwischen den Workload Identity-Pools konfigurieren. Dieser Schritt ist nur erforderlich, wenn sich Ihre Arbeitslasten bei Arbeitslasten in einem anderen Workload Identity-Pool authentifizieren müssen.

Führen Sie die folgenden Schritte aus, um die Vertrauensföderation zu aktivieren:

  1. Vertrauenskonfigurationsdatei erstellen
  2. Workload Identity-Pool mit Vertrauenskonfiguration aktualisieren

Konfigurationsdatei für die Vertrauensstellung erstellen

Erstellen Sie die Datei mit der Vertrauenskonfiguration mit einem inlineTrustConfig-Abschnitt, in dem die Zertifikate für jede Domain angegeben werden.

Die Konfigurationsdatei für die Vertrauensstellung enthält eine Reihe von Trust-Anchors, die von der verwalteten Arbeitslastidentität zum Validieren von Peer-Zertifikaten verwendet werden. In der Vertrauenskonfigurationsdatei wird die SPIFFE-vertrauenswürdige Domain CA-Zertifikaten zugeordnet.

  1. Laden Sie für eine benutzerdefinierte Zertifizierungsstelle die Zertifikate für eine vertrauenswürdige Domain herunter, die eine benutzerdefinierte Zertifizierungsstelle verwendet.

    gcloud privateca pools get-ca-certs ROOT_CA_POOL_ID \
    --output-file=CERTIFICATE_PATH \
    --location=REGION

    Ersetzen Sie Folgendes:

    • ROOT_CA_POOL_ID: Die ID des Stammzertifizierungsstellen-Pools.
    • CERTIFICATE_PATH: Der Ausgabepfad für das PEM-codierte Zertifikat.
    • REGION: Die Region des Stamm-CA-Pools.

  2. Erstellen Sie eine Datei mit dem Namen tc.json, die Ihre Inline-Vertrauenskonfiguration enthält. Wenn für eine Domain die von Google verwaltete Standard-CA verwendet wird, verwenden Sie das Feld trustDefaultSharedCa. Wenn für eine Domain eine benutzerdefinierte Zertifizierungsstelle verwendet wird, verwenden Sie die PEM-codierten Zertifikate, die Sie zuvor heruntergeladen haben.

    Die Datei sieht in etwa so aus:

    In diesem Beispiel verwendet TRUST_DOMAIN_A die von Google verwaltete Standard-CA und TRUSTED_DOMAIN_B eine benutzerdefinierte CA mit den heruntergeladenen Root-Zertifikaten.

    {
  "inlineTrustConfig": {
    "additionalTrustBundles": {
      "TRUST_DOMAIN_A": {
        "trustDefaultSharedCa": true
      },
      "TRUSTED_DOMAIN_B": {
        "trustAnchors": [
          {
              "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL1\n-----END CERTIFICATE-----"
          },
          {
              "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL2\n-----END CERTIFICATE-----"
          }
        ]
      }
    }
  }
}

    Ersetzen Sie Folgendes:

    • TRUST_DOMAIN_A: Der Name der Vertrauenswürdigkeitsdomain, die die von Google verwaltete Standard-CA verwendet.
    • TRUST_DOMAIN_B: Der Name der Vertrauensdomäne, die eine benutzerdefinierte Zertifizierungsstelle verwendet.
    • CERTIFICATE_MATERIAL: Eine Reihe von CA-Zertifikaten im PEM-Format, denen bei der Ausstellung von Zertifikaten in der vertrauenswürdigen Domain vertraut wird.

Workload Identity-Pool mit Vertrauenskonfiguration aktualisieren

gcloud iam workload-identity-pools update TRUST_DOMAIN_NAME \
    --location="global" \
    --inline-trust-config-file=TC_JSON_FILE_PATH \
    --project=PROJECT_ID

Ersetzen Sie Folgendes:

  • TRUST_DOMAIN_NAME: Der Name der Vertrauensdomäne.
  • TC_JSON_FILE_PATH: Der Pfad zur JSON-formatierten Datei mit der Vertrauenskonfiguration (tc.json), die Sie erstellt haben.
  • PROJECT_ID: die Projekt-ID

Nächste Schritte

Überzeugen Sie sich selbst

Wenn Sie mit Google Cloudnoch nicht vertraut sind, erstellen Sie ein Konto, um die Leistungsfähigkeit unserer Produkte in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.

Jetzt kostenlos starten