Einige oder alle Informationen auf dieser Seite gelten möglicherweise nicht für Trusted Cloud von S3NS.

Diese Seite wurde von der Cloud Translation API übersetzt.

Authentifizierung von verwalteten Arbeitslastidentitäten für GKE konfigurieren

In diesem Dokument wird erläutert, wie Sie verwaltete Arbeitslastidentitäten für 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 von verwalteten Arbeitslastidentitäten für GKE umfasst die folgenden Schritte:

Zertifizierungsstellendienst so konfigurieren, dass Zertifikate für verwaltete Arbeitslastidentitäten ausgestellt werden
Binden Sie die CAs 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 zu GKE-Flotten hinzufügen, wird in Flotten automatisch ein von Google verwalteter Workload Identity-Pool erstellt, der als Stamm Ihrer Vertrauensdomäne dient. Für den von Google verwalteten Workload Identity-Pool gelten 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.
Für alle Cluster im Pool gilt das Standardmodell für Kubernetes-Namespaces. Das bedeutet, dass alle Cluster im Pool gleichberechtigt sind. Arbeitslasten, die auf einem der Cluster im Pool ausgeführt werden, können jede Identität im Pool verwenden.

Konfiguration mehrerer Projekte

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

Hinweise

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

Verwaltete Arbeitslastidentitäten
Prüfen Sie, ob mindestens ein GKE-Cluster vorhanden ist. Achten Sie darauf, dass auf Ihren Clustern Version 1.33.0-gke.2248000 oder höher ausgeführt wird.
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 Flotten wird automatisch ein von Google verwalteter Workload Identity-Pool erstellt, der als Vertrauensdomäne 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 Folgendes:
- CLUSTER_NAME: der Name des GKE-Clusters, den Sie in 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 das Google Cloud CLI so, dass das 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 Arbeitslastidentitäten und zum Bereitstellen verwalteter Zertifikate für 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 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 Zertifizierungsstellenhierarchie 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.

Stamm-CA-Pool konfigurieren

So erstellen Sie den Root-CA-Pool:

Erstellen Sie den Stamm-CA-Pool im Tarif 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 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-CA im Stamm-CA-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-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 CA-Name 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-CAs 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 CAs 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:

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.
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 Zertifizierungsstelle.
- 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

Damit CAs an Workload Identity-Pools gebunden werden können, benötigen sie eine Konfiguration für die Zertifikatausstellung. Wenn Ihre Arbeitslasten die Authentifizierung über mehrere Vertrauensbereiche hinweg erfordern, können Sie den Pool optional auch mit Vertrauenskonfigurationskonfigurationen aktualisieren.

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. Die Gültigkeitsdauer des Blattzertifikats in Sekunden. Der Wert muss zwischen 86.400 (1 Tag) und 2.592.000 (30 Tage) liegen. Wenn keine Angabe erfolgt, 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 Gültigkeitsdauer des Zertifikats, bei dem eine Erneuerung 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 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 Vertrauenskonfigurationsdatei, die ein inlineTrustConfig mit Zertifikaten für jede Domain enthält.

Die Datei mit der Vertrauenskonfiguration enthält eine Reihe von Vertrauensankern, die von der verwalteten Arbeitslastidentität zum Validieren von Peerzertifikaten verwendet werden. In der Vertrauenskonfigurationsdatei wird die vertrauenswürdige SPIFFE-Domain 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 Stammzertifizierungsstellen-Pools
- CERTIFICATE_PATH: Der Pfad, in den das PEM-codierte Zertifikat ausgegeben werden soll.
- REGION: die Region des Stamm-CA-Pools

Erstellen Sie eine Datei mit dem Namen, die Ihre Inline-Vertrauenskonfiguration 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 Vertrauensdomäne, 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.

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 Zertifikatausstellungskonfiguration 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 \
    --inline-trust-config-file=TC_JSON_FILE_PATH \
    --project=PROJECT_ID

Ersetzen Sie Folgendes:

TRUST_DOMAIN_NAME: Der Name der Vertrauensdomäne, 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 Vertrauenskonfigurationsdatei (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 Zertifikatausstellungskonfiguration und der Vertrauenskonfiguration 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 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, um Zertifikate vom CA-Pool anzufordern. So autorisieren Sie diese Identitäten:

Weisen Sie der Vertrauensdomäne 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/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 aus PROJECT_ID abzurufen:
```
gcloud projects describe PROJECT_ID --format="value(projectNumber)"
```
- PROJECT_ID: Die Projekt-ID des GKE-Hostprojekts der Flotte.
- CA_PROJECT_ID: die ID des Projekts, in dem Sie die untergeordnete CA erstellt haben.
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/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-Hostprojekts der Flotte.
- 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 Zertifikate für verwaltete Arbeitslastidentitäten ausgestellt werden, können Sie Arbeitslasten mit verwalteten Arbeitslastidentitäten bereitstellen.

In diesem Abschnitt wird beschrieben, 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

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-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

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

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

Sehen Sie sich die Zertifikatsdatei an.
```
cat certfile
```
Im Zertifikat sehen Sie im Attribut X509v3 Subject Alternative Name die SPIFFE-ID im folgenden Format: spiffe://PROJECT_ID.svc.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.

Nächste Schritte

Fehlerbehebung bei der verwalteten Workload Identity für GKE
Weitere Informationen zum Erstellen von CA-Pools.