Diese Seite wurde von der Cloud Translation API übersetzt.

Authentifizierung von verwalteten Arbeitslastidentitäten für GKE konfigurieren
Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

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

Das Einrichten und Verwenden verwalteter Arbeitslastidentitäten für GKE umfasst die folgenden Schritte:

Zertifizierungsstellendienst für die Ausstellung von Zertifikaten für verwaltete Arbeitslastidentitäten konfigurieren
Binden Sie die Zertifizierungsstellen an den Workload Identity-Pool.
Verwaltete Arbeitslastidentitäten autorisieren, um Zertifikate vom CA-Pool anzufordern
Arbeitslasten mit verwalteten Arbeitslastidentitäten bereitstellen

Von Google verwalteter Workload Identity-Pool

Wenn Sie Ihre Cluster GKE-Flotten hinzufügen, wird automatisch ein von Google verwalteter Workload Identity-Pool erstellt, der als Stamm Ihrer Vertrauensdomain dient. Der von Google verwaltete Workload Identity-Pool hat die folgenden Einschränkungen:

Google verwaltet den Pool vollständig. Sie können also keine untergeordneten Ressourcen wie Namespaces, Identitäten oder Identitätsanbieter erstellen.
Der Pool kann nur für GKE-Arbeitslasten verwendet werden. Sie können dem Pool keine anderen Arten von Arbeitslasten wie Compute Engine-VMs hinzufügen.
Alle Cluster im Pool unterliegen dem Standardmodell für die Gleichheit von Kubernetes-Namespaces. Das bedeutet, dass alle Cluster im Pool gleichberechtigt sind. Für Arbeitslasten, die auf einem der Cluster im Pool ausgeführt werden, kann jede Identität im Pool verwendet werden.

Konfiguration mehrerer Projekte

Google 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. Verwenden Sie das Flag --project, um für jede Ressource das richtige Projekt anzugeben.

Hinweise

Create or select a Google Cloud project.
- Create a Google Cloud project:
```
gcloud projects create PROJECT_ID
```
  Replace PROJECT_ID with a name for the Google Cloud project you are creating.
- Select the Google Cloud project that you created:
```
gcloud config set project PROJECT_ID
```
  Replace PROJECT_ID with your Google Cloud project name.

Verwaltete Arbeitslastidentitäten
Sie benötigen mindestens einen GKE-Cluster. Ihre Cluster müssen Version 1.32.2-gke.1652000 oder höher ausführen. Für Cluster, die mit Versionen vor 1.30.1-gke.1156000 erstellt wurden, können keine verwalteten Arbeitslastidentitäten verwendet werden, auch wenn sie auf 1.32.2-gke.1652000 aktualisiert werden.
Fügen Sie Ihre Cluster GKE-Flotten hinzu. Wenn es sich bei Ihrem Cluster um einen Autopilot-Cluster handelt, lassen Sie --enable-workload-identity weg. In Fleets wird automatisch ein von Google verwalteter Workload Identity-Pool erstellt, der als Vertrauensdomain dient.

Aktivieren Sie GKE-Flotten mit dem folgenden Befehl:
```
gcloud container clusters update CLUSTER_NAME \
    --enable-workload-identity \
    --enable-fleet \
    --fleet-project=PROJECT_ID
```
Ersetzen Sie Folgendes:
- CLUSTER_NAME: Name des GKE-Clusters, den Sie bei der GKE-Flotte registrieren möchten
- PROJECT_ID: die Projekt-ID des GKE-Hostprojekts der Flotte
Enable the IAM and Certificate Authority Service APIs:
```
gcloud services enable cloudresourcemanager.googleapis.com iam.googleapis.com privateca.googleapis.com
```
Konfigurieren Sie die Google Cloud CLI für die Verwendung des Abrechnungs- und Kontingentprojekts.
```
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 Arbeitslastidentitäten und zum Bereitstellen von Zertifikaten für verwaltete Arbeitslastidentitäten benötigen:

So erstellen und konfigurieren Sie verwaltete Arbeitslastidentitäten: IAM Workload Identity Pool Admin (roles/iam.workloadIdentityPoolAdmin)
So erstellen und konfigurieren Sie CA-Pools: CA Service Admin (roles/privateca.admin)

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-Dienst zum Ausstellen von Zertifikaten für verwaltete Arbeitslastidentitäten konfigurieren

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

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

Stamm-CA-Pool konfigurieren

So erstellen Sie den Root-CA-Pool:

Erstellen Sie den Stamm-CA-Pool in der Stufe Enterprise 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 Stamm-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-CA im Stamm-CA-Pool. Möglicherweise werden Sie 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-CA 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 Stamm-CA-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 Stamm-CAs in Ihrem Stamm-CA-Pool erstellen. Das kann für die Rotation der Stamm-CA nützlich sein.

Untergeordnete Zertifizierungsstellen konfigurieren

Optional können Sie untergeordnete Zertifizierungsstellen konfigurieren. Die Konfiguration untergeordneter Zertifizierungsstellen kann bei Folgendem helfen:

Mehrere Szenarien für die Zertifikatausstellung: Wenn Sie mehrere Szenarien für die Zertifikatausstellung haben, können Sie für jedes Szenario eine untergeordnete Zertifizierungsstelle erstellen.
Besseres Load Balancing: Wenn Sie mehrere untergeordnete Zertifizierungsstellen in einem CA-Pool hinzufügen, können Sie das Load Balancing von Zertifikatsanfragen verbessern.

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

Erstellen Sie den untergeordneten CA-Pool auf der Ebene DevOps, die für die kurzlebige Zertifikatausstellung 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 Zertifizierungsstelle erstellt haben.
Weitere Informationen finden Sie unter CA-Pools erstellen.
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 Zertifizierungsstelle. 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 Stamm-CA-Pools.
- REGION: die Region des Stamm-CA-Pools.
- SUBORDINATE_CA_CN: der Name der untergeordneten Zertifizierungsstelle
- SUBORDINATE_CA_ORGANIZATION: der Name der ausstellenden Organisation der untergeordneten Zertifizierungsstelle.
- KEY_ALGORITHM: Der Schlüsselalgorithmus, z. B. ec-p256-sha256
- CA_PROJECT_ID: die ID des Projekts, in dem Sie die untergeordnete Zertifizierungsstelle erstellt haben.
Weitere Informationen zu den subject-Feldern für die Zertifizierungsstelle finden Sie unter Inhaber.

Konfigurationsdatei für die Zertifikatsausstellung erstellen

Damit Zertifizierungsstellen mit Workload Identity-Pools verknüpft werden können, benötigen sie eine Konfiguration für die Zertifikatausstellung. Optional können Sie den Pool auch mit Konfigurationen für die Vertrauensstellung aktualisieren, wenn sich Ihre Arbeitslasten über mehrere Vertrauensdomains hinweg authentifizieren müssen.

Um die Konfiguration der Zertifikatsausstellung zu konfigurieren, erstellen Sie eine Konfigurationsdatei für die Zertifikatsausstellung. 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 wurde. Gültige Werte sind ECDSA_P256 (Standard), ECDSA_P384, RSA_2048, RSA_3072 und RSA_4096.
DURATION: Optional. Gültigkeitsdauer des Endzertifikats in Sekunden. Der Wert muss zwischen 86.400 (1 Tag) und 259.2000 (30 Tage) liegen. Wenn keine Angabe erfolgt, wird der Standardwert 86400 (1 Tag) verwendet. Die tatsächliche Gültigkeit des ausgestellten Zertifikats hängt auch von der ausstellenden Zertifizierungsstelle ab, da sie die Lebensdauer des ausgestellten Zertifikats einschränken kann.
ROTATION_WINDOW_PERCENTAGE: Optional: Der Prozentsatz der Lebensdauer des Zertifikats, nach dem eine Verlängerung ausgelöst wird. Der Wert muss zwischen 50 und 80 liegen. Der Standardwert ist 50.

Konfigurationsdatei für die Vertrauensstellung erstellen

Standardmäßig können sich Ihre Arbeitslasten innerhalb derselben vertrauenswürdigen Domain gegenseitig mithilfe verwalteter Workload Identities authentifizieren. Wenn Sie möchten, dass Arbeitslasten in unterschiedlichen vertrauenswürdigen Domains sich gegenseitig authentifizieren, müssen Sie die Vertrauensbeziehung im Workload Identity-Pool explizit deklarieren. Dazu erstellen Sie eine Trust-Konfigurationsdatei, die eine inlineTrustConfig enthält, die Zertifikate für jede Domain bereitstellt.

Die Vertrauenskonfigurationsdatei enthält eine Reihe von Vertrauensanker, die die verwaltete Arbeitslastidentität zum Validieren von Peerzertifikaten verwendet. In der Vertrauenskonfigurationsdatei wird die SPIFFE-Vertrauensdomain CA-Zertifikaten zugeordnet.

So erstellen Sie die Konfigurationsdatei für die Vertrauensstellung:

Laden Sie die Zertifikate herunter.
```
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 Stamm-CA-Pools
- CERTIFICATE_PATH: Der Pfad, unter dem das PEM-codierte Zertifikat ausgegeben werden soll.
- REGION: die Region des Stamm-CA-Pools

Erstellen Sie eine Datei mit dem Namen „trust.pem“, die Ihre Inline-Vertrauensstellung mit PEM-formatierten Zertifikaten enthält. Die Datei sieht in etwa so aus:

{
  "inlineTrustConfig": {
    "additionalTrustBundles": {
      "TRUST_DOMAIN_NAME1": {
        "trustAnchors": [
          {
              "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL1\n-----END CERTIFICATE-----"
          },
          {
              "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL2\n-----END CERTIFICATE-----"
          }
        ]
      },
      "TRUSTED_DOMAIN_NAME2": {
        "trustAnchors": [
          {
              "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL3\n-----END CERTIFICATE-----"
          },
          {
              "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL4\n-----END CERTIFICATE-----"
          }
        ]
      }
    }
  }
}

Ersetzen Sie Folgendes:

TRUST_DOMAIN_NAME: Der Name der Vertrauensdomain, der so formatiert ist:
```
PROJECT_ID.svc.id.goog
```
CERTIFICATE_MATERIAL: Eine Reihe von CA-Zertifikaten im PEM-Format, denen bei der Ausstellung von Zertifikaten in der vertrauenswürdigen Domain vertraut wird.

CAs an den Workload Identity-Pool binden

Nachdem Sie die Zertifizierungsstellenhierarchie erstellt und Konfigurationen für die Zertifikatsausstellung für jede Zertifizierungsstelle erstellt haben, binden Sie die Zertifizierungsstellen an den Workload Identity-Pool. Wenn Sie eine Zertifizierungsstelle an den Workload Identity-Pool binden möchten, aktualisieren Sie den Workload Identity-Pool mit der Konfiguration für die Zertifikatsausstellung der Zertifizierungsstelle. 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 \
    --inline-trust-config-file=TC_JSON_FILE_PATH \
    --project=PROJECT_ID

Ersetzen Sie Folgendes:

TRUST_DOMAIN_NAME: Der Name der Vertrauensdomain, der so formatiert ist:
```
PROJECT_ID.svc.id.goog
```
CIC_JSON_FILE_PATH: Der Pfad zur JSON-formatierten Konfigurationsdatei für die Zertifikatausstellung (cic.json), die Sie zuvor erstellt haben.
TC_JSON_FILE_PATH: Optional. Der Pfad zur JSON-formatierten Vertrauens-Konfigurationsdatei (tc.json), die Sie zuvor erstellt haben. Wenn sich Ihre Arbeitslasten über verschiedene vertrauenswürdige Domains hinweg authentifizieren, müssen Sie diese Datei angeben. Andernfalls können Sie --inline-trust-config weglassen.

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 zusammen mit der Konfiguration für die Zertifikatausstellung und der Vertrauensstellung 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 Vertrauensdomain, mit der Sie den Workload Identity-Pool in diesem Dokument aktualisiert haben.

Die Befehlsausgabe sieht dann ungefähr 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
inlineTrustConfig:
    additionalTrustBundles:
      example.com:
          trustAnchors:
          - pemCertificate: |-
            -----BEGIN CERTIFICATE-----
            CERTIFICATE_MATERIAL1
            -----END CERTIFICATE-----
          - pemCertificate: |-
            -----BEGIN CERTIFICATE-----
            CERTIFICATE_MATERIAL2
            -----END CERTIFICATE-----
      myorg.com:
          trustAnchors:
          - pemCertificate: |-
            -----BEGIN CERTIFICATE-----
            CERTIFICATE_MATERIAL3
            -----END CERTIFICATE-----
          - pemCertificate: |-
            -----BEGIN CERTIFICATE-----
            CERTIFICATE_MATERIAL4
            -----END CERTIFICATE-----
name: PROJECT_ID.svc.id.goog
state: ACTIVE

Wenn inlineCertificateIssuanceConfig oder inlineTrustConfig 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 Zertifizierungsstellen an den Workload Identity-Pool gebunden haben, müssen Sie verwaltete Arbeitslastidentitäten autorisieren, Zertifikate vom CA-Pool anzufordern. So autorisieren Sie diese Identitäten:

Weisen Sie der Vertrauensdomain 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 Vertrauensdomain autorisiert, Zertifikate aus den Zertifikatsketten des Zertifizierungsstellendienstes 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/PROJECT_ID.svc.id.goog" \
    --project=CA_PROJECT_ID
```
Ersetzen Sie Folgendes:
- SUBORDINATE_CA_POOL_ID: die ID für den untergeordneten CA-Pool.
- 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 von PROJECT_ID abzurufen:
```
gcloud projects describe PROJECT_ID --format="value(projectNumber)"
```
- PROJECT_ID: Die Projekt-ID des GKE-Flotten-Hostprojekts.
- CA_PROJECT_ID: die ID des Projekts, in dem Sie die untergeordnete Zertifizierungsstelle erstellt haben.
Weisen Sie der verwalteten Arbeitslastidentität die Rolle Leser von CA-Dienstpools (roles/privateca.poolReader) in den 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/PROJECT_ID.svc.id.goog" \
    --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.
- PROJECT_ID: Die Projekt-ID des GKE-Flotten-Hostprojekts.
- CA_PROJECT_ID: die ID des Projekts, in dem Sie die untergeordnete Zertifizierungsstelle 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 erfahren Sie, wie Sie eine Testarbeitslast mit einer verwalteten Arbeitslastidentität bereitstellen. Dazu müssen Sie einen Pod bereitstellen, prüfen, ob Anmeldedaten generiert wurden, und sich das Zertifikat und die SPIFFE-ID ansehen.

Pod bereitstellen

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

Rufen Sie die Clusteranmeldedaten ab.

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

Erstellen Sie den Kubernetes-Namespace.

kubectl create namespace KUBERNETES_NAMESPACE

Stellen Sie eine Test-Pod-Spezifikation 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

Anmeldedaten für die Arbeitslast auflisten

Führen Sie den folgenden Befehl aus, um die Anmeldedaten für die Arbeitslast aufzulisten. Die Erstellung der Anmeldedaten kann einige Minuten dauern.

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

Es sollte folgende Ausgabe angezeigt werden:

ca_certificates.pem
certificates.pem
private_key.pem
trust_bundles.json

Zertifikat ansehen

So rufen Sie das Zertifikat auf:

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

Rufen Sie die Zertifikatsdatei auf.
```
cat certfile
```
Im Zertifikat finden Sie im X509v3 Subject Alternative Name-Attribut die SPIFFE-ID im folgenden Format: spiffe://PROJECT_ID.svc.id.goog/ns/KUBERNETES_NAMESPACE/sa/default.

default bezieht sich auf das Standard-Kubernetes-Dienstkonto.

Authentifizierung von Arbeitslasten testen

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

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

Nächste Schritte

Fehlerbehebung bei verwalteter Arbeitslast-Identität für GKE
Weitere Informationen zum Erstellen von CA-Pools.

Überzeugen Sie sich selbst

Wenn Sie mit Google Cloudnoch nicht vertraut sind, erstellen Sie einfach 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

Authentifizierung von verwalteten Arbeitslastidentitäten für GKE konfigurieren Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Von Google verwalteter Workload Identity-Pool

Konfiguration mehrerer Projekte

Hinweise

Erforderliche Rollen

CA-Dienst zum Ausstellen von Zertifikaten für verwaltete Arbeitslastidentitäten konfigurieren

Stamm-CA-Pool konfigurieren

Stamm-CA konfigurieren

Untergeordnete Zertifizierungsstellen konfigurieren

Konfigurationsdatei für die Zertifikatsausstellung erstellen

Konfigurationsdatei für die Vertrauensstellung erstellen

CAs an den Workload Identity-Pool binden

Workload Identity-Pool aktualisieren

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

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

Arbeitslasten mit verwalteten Arbeitslastidentitäten bereitstellen

Pod bereitstellen

Anmeldedaten für die Arbeitslast auflisten

Zertifikat ansehen

Authentifizierung von Arbeitslasten testen

Nächste Schritte

Überzeugen Sie sich selbst

Authentifizierung von verwalteten Arbeitslastidentitäten für GKE konfigurieren
Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.