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:

Option für die Zertifizierungsstelle (CA) auswählen
Zertifizierungsstelle konfigurieren
Arbeitslasten mit verwalteten Arbeitslastidentitäten bereitstellen
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 Vertrauensstamm (auch als SPIFFE-Vertrauensdomäne 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 vertrauenswürdige Domains haben, können Sie die Vertrauensbundesidentität aktivieren, um die Kommunikation zwischen den vertrauenswürdigen Domains zu ermöglichen.

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 in einem beliebigen Cluster im Pool können jede Identität in diesem Pool verwenden.

Konfiguration mehrerer Projekte

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

Hinweis

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 .
Verwaltete Arbeitslastidentitäten
Ihre Cluster müssen Version 1.33.0-gke.2248000 oder höher ausführen.
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
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
```
gcloud services enable cloudresourcemanager.googleapis.com iam.googleapis.com privateca.googleapis.com
```
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 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-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-CA bietet eine gemeinsame Root of Trust für alle Google 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 Signaturschlüssel in einem Hardwaresicherheitsmodul (HSM) speichern müssen, um Complianceanforderungen zu erfüllen. Certificate Authority Service wird separat von der verwalteten Arbeitslastidentität abgerechnet. Weitere Informationen finden Sie unter Preise für CA-Dienste.

CA konfigurieren

Standard-CA

Wenn Sie die Standard-CA 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, formatiert wie folgt:
```
  PROJECT_ID.svc.id.goog
```
PROJECT_ID: Die Projekt-ID.

Benutzerdefinierte CA

CA Service so konfigurieren, dass Zertifikate für verwaltete Arbeitslastidentitäten ausgestellt werden
Binden Sie die Zertifizierungsstellen an den Workload Identity-Pool.
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 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 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:

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 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 sich Ihre Arbeitslasten über mehrere vertrauenswürdige Domains hinweg authentifizieren 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, 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.

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 weiter oben 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: PROJECT_ID.svc.id.goog
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, 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 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 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 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

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.

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 Vertrauenswürdigkeitsfö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 Vertrauensstellung zu aktivieren:

Vertrauenskonfigurationsdatei erstellen
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.

Laden Sie für benutzerdefinierte CAs die Zertifikate für eine Vertrauensdomäne herunter, die eine benutzerdefinierte CA 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.
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

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

Ü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

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

Hinweis

Erforderliche Rollen

CA-Option auswählen

CA konfigurieren

Standard-CA

Benutzerdefinierte CA

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

Stamm-CA-Pool konfigurieren

Stamm-CA konfigurieren

Untergeordnete Zertifizierungsstellen konfigurieren

Konfigurationsdatei für die Zertifikatsausstellung erstellen

Zertifizierungsstellen 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

Arbeitslastanmeldedaten auflisten

Zertifikat ansehen

Authentifizierung von Arbeitslasten testen

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

Konfigurationsdatei für die Vertrauensstellung erstellen

Workload Identity-Pool mit Vertrauenskonfiguration aktualisieren

Nächste Schritte

Überzeugen Sie sich selbst

Authentifizierung von verwalteten Arbeitslastidentitäten für GKE konfigurieren