Diese Seite wurde von der Cloud Translation API übersetzt.

Workload Identity-Föderation auf AKS und EKS aktivieren

In diesem Thema wird erläutert, wie Sie die Identitätsföderation von Arbeitslasten für Apigee Hybrid-Installationen auf AKS- und EKS-Plattformen aktivieren.

Für Installationen in GKE folgen Sie der Anleitung unter Workload Identity in GKE aktivieren.

Übersicht

Mit der Workload Identity-Föderation können Anwendungen, die außerhalb von Google Cloud ausgeführt werden, die Identität eines Google Cloud-Dienstkontos mithilfe von Anmeldedaten eines externen Identitätsanbieters übernehmen.

Die Workload Identity-Föderation kann zur Verbesserung der Sicherheit beitragen, indem Anwendungen die Authentifizierungsmechanismen nutzen, die die externe Umgebung bereitstellt, und Dienstkontoschlüssel können ersetzt werden.

Eine Übersicht finden Sie unter Best Practices für die Verwendung der Identitätsföderation von Arbeitslasten.

Hinweis:Die apigee-logger-Komponente unterstützt keine Identitätsföderation von Arbeitslasten. Siehe Bekannte Probleme.

Identitätsföderation von Arbeitslasten einrichten

Wenn Sie die Identitätsföderation von Arbeitslasten mit Apigee Hybrid verwenden möchten, müssen Sie zuerst Ihren Cluster konfigurieren und dann die Funktion auf Ihre Apigee Hybrid-Installation anwenden.

Hinweise

In dieser Anleitung wird davon ausgegangen, dass Sie Ihre Apigee Hybrid-Installation bereits eingerichtet haben. Die IAM-Dienstkonten und Kubernetes-Dienstkonten werden bei der Erstinstallation erstellt. Eine Übersicht über die Installation von Apigee Hybrid finden Sie unter Allgemeiner Überblick.

Bei Installationen in AKS muss der OpenID Connect (OIDC)-Aussteller aktiviert sein. Sie müssen diese Funktion aktivieren, damit die Workload Identity-Föderation auf die OpenID Connect-Metadaten und das JSON Web Key Set (JWKS) für den Cluster zugreifen kann.

Konfigurieren Sie Ihren Cluster für die Verwendung der Identitätsföderation von Arbeitslasten.

Prüfen Sie mit dem folgenden Befehl, ob die aktuelle gcloud-Konfiguration auf Ihre Google Cloud-Projekt-ID festgelegt ist:
```
gcloud config get project
```

Legen Sie gegebenenfalls die aktuelle gcloud-Konfiguration fest:

gcloud config set project PROJECT_ID

Aktivieren Sie die Security Token Service API:
Prüfen Sie mit dem folgenden Befehl, ob die Security Token Service API aktiviert ist:
```
gcloud services list --enabled --project PROJECT_ID | grep sts.googleapis.com
```
Wenn die API nicht aktiviert ist:
Console

Enable the Security Token Service API.
Enable the API
Befehlszeile

Aktivieren Sie die API mit dem folgenden Befehl:
```
gcloud services enable sts.googleapis.com --project PROJECT_ID
```
Erstellen Sie den Workload Identity-Pool und den Anbieter.
Erforderliche Rollen
Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für das Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Konfigurieren der Workload Identity-Föderation benötigen:
- Workload Identity Pool Admin (roles/iam.workloadIdentityPoolAdmin)
- Service Account Admin (roles/iam.serviceAccountAdmin)
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.
Alternativ enthält die einfache Rolle „IAM-Inhaber“ (roles/owner) auch Berechtigungen zum Konfigurieren der Identitätsföderation. In einer Produktionsumgebung sollten Sie keine einfachen Rollen zuweisen, Sie können sie aber in einer Entwicklungs- oder Testumgebung gewähren.
So erstellen Sie einen Workload Identity-Pool und -Anbieter:
1. Bestimmen Sie die Aussteller-URL Ihres AKS-Clusters:
  AKS
  az aks show -n NAME -g RESOURCE_GROUP --query "oidcIssuerProfile.issuerUrl" -otsv
  Ersetzen Sie Folgendes:
  - NAME: Der Name des Clusters.
  - RESOURCE_GROUP: Die Ressourcengruppe des Clusters.
  Der Befehl gibt die Aussteller-URL aus. Sie benötigen die Aussteller-URL in einem der folgenden Schritte.
  
  Wenn der Befehl keine Aussteller-URL zurückgibt, prüfen Sie, ob Sie das Feature OIDC-Aussteller aktiviert haben.
  EKS
  aws eks describe-cluster --name NAME --query "cluster.identity.oidc.issuer" --output text
  Ersetzen Sie NAME durch den Namen des Clusters.
  
  Der Befehl gibt die Aussteller-URL aus. Sie benötigen die Aussteller-URL in einem der folgenden Schritte.
  Andere Kubernetes
  1. Stellen Sie eine Verbindung zu Ihrem Kubernetes-Cluster her und ermitteln Sie mit kubectl die Aussteller-URL des Clusters:
    kubectl get --raw /.well-known/openid-configuration | jq -r .issuer
    
    Sie benötigen die Aussteller-URL in einem der folgenden Schritte.
2. Optional:Wenn Ihr OIDC-Aussteller nicht öffentlich zugänglich ist, laden Sie das JSON Web Key Set (JWKS) des Clusters herunter:
  Hinweis:Für diesen Schritt ist kubectl-Zugriff auf Ihren Cluster erforderlich.
  
  Tipp:Wenn Sie die JWKS-Datei verwenden, müssen Sie jedes Mal, wenn Sie die Signaturschlüssel für den Cluster rotieren, eine neue JWKS-Datei hochladen.
```
kubectl get --raw /openid/v1/jwks > cluster-jwks.json
```
  Um zu prüfen, ob Ihr OIDC-Anbieter öffentlich verfügbar ist, sollten Sie mit einem CURL-Befehl auf Ihre Anbieter-URL zugreifen und eine Antwort 200 erhalten.
3. Erstellen Sie einen neuen Workload Identity-Pool:
```
gcloud iam workload-identity-pools create POOL_ID \
  --location="global" \
  --description="DESCRIPTION" \
  --display-name="DISPLAY_NAME"
            
```
  Ersetzen Sie Folgendes:
  - POOL_ID: die eindeutige ID des Pools.
  - DISPLAY_NAME: (Optional) Der Name des Pools.
  - DESCRIPTION: (Optional) Eine Beschreibung des von Ihnen gewählten Pools. Diese Beschreibung wird angezeigt, wenn Sie Zugriff auf Poolidentitäten gewähren.
  Beispiel:
```
gcloud iam workload-identity-pools create my-wi-pool --display-name="My workload pool" --description="My workload pool description"
```
4. Fügen Sie den Cluster als Workload Identity-Poolanbieter hinzu. Wählen Sie den Befehl zum Erstellen des Anbieters aus, je nachdem, ob Ihr OIDC-Aussteller öffentlich zugänglich oder nicht öffentlich zugänglich ist:
  Öffentlich zugänglich
  
  Wenn Ihr OIDC-Aussteller öffentlich zugänglich ist, erstellen Sie den Anbieter mit dem folgenden Befehl:
  gcloud iam workload-identity-pools providers create-oidc WORKLOAD_PROVIDER_ID \ --location="global" \ --workload-identity-pool="POOL_ID" \ --issuer-uri="ISSUER" \ --attribute-mapping="google.subject=assertion.sub"
  Nicht öffentlich zugänglich
  
  Wenn Ihr OIDC-Aussteller nicht öffentlich zugänglich ist, erstellen Sie den Anbieter mit dem folgenden Befehl:
  gcloud iam workload-identity-pools providers create-oidc WORKLOAD_PROVIDER_ID \ --location="global" \ --workload-identity-pool="POOL_ID" \ --issuer-uri="ISSUER" \ --jwks-file="cluster-jwks.json" \ --attribute-mapping="google.subject=assertion.sub"
  Hinweis:Wenn Sie Ihre Schlüssel rotieren, müssen Sie bei jeder Schlüsselrotation das neue JWKS hochladen.
  Der Befehl validiert nicht das JWKS des Clusters. Wenn das JWKS fehlerhaft oder abgelaufen ist, können nachfolgende Authentifizierungsversuche mit der Fehlermeldung Error connecting to the given credential's issuer fehlschlagen.
  Ersetzen Sie Folgendes:
  - WORKLOAD_PROVIDER_ID: Eine eindeutige Anbieter-ID für Workload Identity-Pool Ihrer Wahl.
  - POOL_ID: Die ID des Workload Identity-Pools, die Sie zuvor erstellt haben.
  - ISSUER: Verwenden Sie die zuvor ermittelte Aussteller-URL für den Aussteller-URI .
  attribute-mapping="google.subject=assertion.sub"ordnet das Kubernetes-Subjekt dem IAM-Subjekt zu.

Konfigurationsdateien für Anmeldedaten erstellen

Wenn Sie eine Kubernetes-Arbeitslast bereitstellen möchten, die auf Google Cloud Ressourcen zugreifen kann, müssen Sie zuerst eine Anmeldedatenkonfigurationsdatei für jedes IAM-Dienstkonto erstellen:

Mit dem folgenden Befehl können Sie eine Liste der IAM-Dienstkonten (auch als „Google-Dienstkonten“ bezeichnet) aufrufen:
```
gcloud iam service-accounts list --project PROJECT_ID
```
Hinweis:Sie haben die IAM-Dienstkonten (auch als „Google-Dienstkonten“ bezeichnet) wahrscheinlich bereits bei der Erstinstallation von Apigee Hybrid mit dem Tool create-service-account erstellt. Eine Liste der IAM-Dienstkonten, die für Apigee Hybrid erforderlich sind, finden Sie unter Informationen zu Dienstkonten. Eine Anleitung zum Erstellen der IAM-Dienstkonten finden Sie im Installationsleitfaden unter Schritt 4: Dienstkonten erstellen.

Sie müssen die Konfigurationsdateien für die Anmeldedaten für die folgenden IAM-Dienstkonten erstellen:
Prod

Für Produktionsumgebungen:
```
DISPLAY NAME         EMAIL                                                      DISABLED
apigee-cassandra     apigee-cassandra@my_project_id.iam.gserviceaccount.com     False
apigee-mart          apigee-mart@my_project_id.iam.gserviceaccount.com          False
apigee-metrics       apigee-metrics@my_project_id.iam.gserviceaccount.com       False
apigee-runtime       apigee-runtime@my_project_id.iam.gserviceaccount.com       False
apigee-synchronizer  apigee-synchronizer@my_project_id.iam.gserviceaccount.com  False
apigee-udca          apigee-udca@my_project_id.iam.gserviceaccount.com          False
apigee-watcher       apigee-watcher@my_project_id.iam.gserviceaccount.com       False
```
Non-prod

Für Nicht-Produktionsumgebungen:
```
DISPLAY NAME         EMAIL                                                      DISABLED
apigee-non-prod      apigee-non-prod@my_project_id.iam.gserviceaccount.com      False
```
Tipp: Wenn Sie benutzerdefinierte Namen für Ihre Dienstkonten haben, die nicht leicht mit den Namen der Apigee-Komponenten übereinstimmen, können Sie die Rolle jedes Dienstkontos ermitteln. Prüfen Sie dazu die zugewiesenen Rollen und vergleichen Sie sie mit den Rollen, die unter Informationen zu Dienstkonten empfohlen werden.
Verwenden Sie den folgenden Befehl, um die einem Dienstkonto zugewiesenen Rollen zu prüfen:
```
gcloud projects get-iam-policy PROJECT_ID  \
  --flatten="bindings[].members" \
  --format='table(bindings.role)' \
  --filter="SERVICE_ACCOUNT_NAME"
```
Notieren Sie sich, welches benutzerdefinierte Dienstkonto den in der vorherigen Liste aufgeführten IAM-SAs entspricht.

Erstellen Sie für jedes IAM-Dienstkonto in der vorherigen Liste eine Anmeldedatenkonfigurationsdatei. Sie benötigen diese Konfigurationsdateien für Anmeldedaten, um Apigee Hybrid für die Verwendung der Workload Identity-Föderation zu konfigurieren:

Code

gcloud iam workload-identity-pools create-cred-config \
  projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/WORKLOAD_PROVIDER_ID \
  --service-account=SERVICE_ACCOUNT_EMAIL \
  --credential-source-file=/var/
  --credential-source-type=text \
  --output-file=SERVICE_ACCOUNT_NAME-credential-configuration.json

Beispiel

gcloud iam workload-identity-pools create-cred-config \
  projects/123123123123/locations/global/workloadIdentityPools/my-wi-pool/providers/my-wi-provider \
  --service-account=apigee-cassandra@myhybridporg.iam.gserviceaccount.com \
  --credential-source-file=/var/
  --credential-source-type=text \
  --output-file=apigee-cassandra-credential-configuration.json

Wobei:

PROJECT_NUMBER: Die Projektnummer des Projekts, das den Workload Identity-Pool enthält. Dies muss die Projektnummer anstelle der Projekt-ID sein.
POOL_ID: die ID des Workload Identity-Pools
WORKLOAD_PROVIDER_ID: die ID des Workload Identity-Poolanbieters
SERVICE_ACCOUNT_EMAIL: E-Mail-Adresse des Dienstkontos, wenn Sie Ihr Kubernetes-Dienstkonto so konfiguriert haben, dass die Identitätsdiebstahl-Funktion für IAM-Dienstkonten verwendet wird.

Wichtig:credential-source-type muss auf text gesetzt sein.

Hinweis:Erstellen Sie keine Konfigurationsdatei für Anmeldedaten für das Dienstkonto apigee-logger.

Mit der Konfigurationsdatei für Anmeldedaten können die [Cloud-Clientbibliotheken](/apis/docs/cloud-client-libraries), die gcloud CLI und Terraform Folgendes ermitteln:

Wo externe Anmeldedaten abgerufen werden
Welcher Workload Identity-Pool und -Anbieter verwendet werden
Welches Dienstkonto übernommen wird

Apigee Hybrid für die Verwendung der Identitätsföderation von Arbeitslasten konfigurieren

Kopieren oder verschieben Sie jede Ausgabedatei (SERVICE_ACCOUNT_NAME-credential-configuration.json) in die folgenden Diagrammverzeichnisse (oder Unterverzeichnisse). Das waren die Dateien, die Sie im Schritt Konfigurationsdateien für Anmeldedaten erstellen erstellt haben.

Prod

Dienstkonto	Apigee Helm-Diagrammverzeichnis
`apigee-cassandra`	`apigee-datastore/`
`apigee-mart`	`apigee-org/`
`apigee-metrics`	`apigee-telemetry/`
`apigee-runtime`	`apigee-env/`
`apigee-synchronizer`	`apigee-env/`
`apigee-udca`	`apigee-org/` `apigee-env/`
`apigee-watcher`	`apigee-org/`

Non-prod

Dienstkonto	Apigee Helm-Diagramm
`apigee-non-prod`	`apigee-datastore/` `apigee-telemetry/` `apigee-org/` `apigee-env/`

Nehmen Sie die folgenden globalen Änderungen an der Überschreibungsdatei Ihres Clusters vor:

Code

gcp:
  workloadIdentity:
    enabled: false # must be set to false to use Workload Identity Federation
  federatedWorkloadIdentity:
    enabled: true
    audience: "AUDIENCE"
    credentialSourceFile: "/var/run/service-account/token"

Beispiel

gcp:
  workloadIdentity:
    enabled: false
  federatedWorkloadIdentity:
    enabled: true
    audience: "//iam.googleapis.com/projects/123123123123/locations/global/workloadIdentityPools/my-wi-pool/providers/my-wi-provider"
    credentialSourceFile: "/var/run/service-account/token"

Dabei ist AUDIENCE die zulässige Zielgruppe des Workload Identity-Anbieters. Sie finden den Wert, indem Sie in einer der Konfigurationsdateien für Anmeldedaten nach dem Begriff audience: suchen. Der Wert für die Zielgruppe ist in jeder Anmeldedatenkonfigurationsdatei identisch.

Beispiel: In der folgenden apigee-udca-credential-configuration.json-Beispieldatei:

{
  "universe_domain": "googleapis.com",
  "type": "external_account:,"
  "audience": "//iam.googleapis.com/projects/123123123123/locations/global/workloadIdentityPools/my-wi-pool/providers/my-wi-provider",
  "subject_token_type": "urn:ietf:params:oauth: token-type:jwt",
  "token_url": "https://sts.googleapis.com/v1/token",
  "service
  "impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/apigee-udca@myhybridproject.iam.gserviceaccount.com:generateAccessToken",
  "credential_source": {
    "file": "/var/run/service-account/token",
    "format": {
      "type": "text"
    }
  }
}

Der Zielgruppenwert ist //iam.googleapis.com/projects/123123123123/locations/global/workloadIdentityPools/my-wi-pool/providers/my-wi-provider.

Konfigurieren Sie die Überschreibungen für jede Komponente mithilfe der Workload Identity-Föderation. Wählen Sie die Anleitung für Zertifikatdateien, Kubernetes-Secrets oder Vault aus, die für Ihre Installation geeignet ist.

Zertifikatsdatei

Ersetzen Sie den Wert von serviceAccountPath durch die Anmeldedatenquelle für das entsprechende IAM-Dienstkonto. Dies muss der Pfad relativ zum Diagrammverzeichnis sein. Beispiel:

envs:
- name: ENVIRONMENT_NAME
  serviceAccountPaths:
    synchronizer: apigee-synchronizer-credential-configuration.json
    runtime: apigee-runtime-credential-configuration.json
    udca: udca-credential-configuration.json

mart:
  serviceAccountPath: mart-credential-configuration.json

connectAgent:
  serviceAccountPath: mart-credential-configuration.json

metrics:
  serviceAccountPath: metrics-credential-configuration.json

udca:
  serviceAccountPath: UDCA_SERVICE_ACCOUNT_FILEPATH

watcher:
  serviceAccountPath: WATCHER_SERVICE_ACCOUNT_FILEPATH

K8s-Secret

Erstellen Sie für jede Konfigurationsdatei für Anmeldedaten ein neues Kubernetes-Secret mit der Anmeldedatenquelle.

kubectl create secret -n APIGEE_NAMESPACE generic SECRET_NAME --from-file="client_secret.json=CREDENTIAL_CONFIGURATION_FILE"

Beispiel:

kubectl create secret -n apigee generic udca-workoad-identity-secret --from-file="client_secret.json=./apigee-udca-credential-configuration.json"

Ersetzen Sie den Wert von serviceAccountRef durch das neue Secret. Beispiel:
```
udca:
  serviceAccountRef: udca-workoad-identity-secret
```

Vault

Aktualisieren Sie den Dienstkontoschlüssel SAKEY für jedes Dienstkonto in Vault mit der entsprechenden Anmeldedaten-Quelldatei. Die Vorgehensweise ist für alle Komponenten ähnlich. Für UDCA beispielsweise:

SAKEY=$(cat .apigee-udca-credential-configuration.json); kubectl -n APIGEE_NAMESPACE exec vault-0 -- vault kv patch secret/apigee/orgsakeys udca="$SAKEY"

Weitere Informationen finden Sie unter Storing service account keys in Hashicorp Vault.

Wenden Sie die Änderungen mit dem Befehl helm upgrade auf jede betroffene Komponente an:

Wenn Sie die Vault-Dienstkontoschlüssel aktualisiert haben, aktualisieren Sie das Diagramm apigee-operator.

helm upgrade operator apigee-operator/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides.yaml

Aktualisieren Sie die restlichen betroffenen Diagramme in der folgenden Reihenfolge:

helm upgrade datastore apigee-datastore/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides.yaml

helm upgrade telemetry apigee-telemetry/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides.yaml

helm upgrade $ORG_NAME apigee-org/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides.yaml

Aktualisieren Sie das apigee-env-Diagramm für jede Umgebung und ersetzen Sie dabei jedes Mal $ENV_RELEASE_NAME und ENV_NAME:

helm upgrade $ENV_RELEASE_NAME apigee-env/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set env=$ENV_NAME \
  -f overrides.yaml

Eine Liste der Komponenten und ihrer entsprechenden Diagramme finden Sie in der Referenz zu Apigee Hybrid-Helm-Diagrammen.

Zugriff auf die Kubernetes-Dienstkonten gewähren

Mit dem folgenden Befehl können Sie eine Liste der Kubernetes-Dienstkonten aufrufen:
```
kubectl get sa -n APIGEE_NAMESPACE
```
Hinweis: Die erforderlichen Kubernetes-Dienstkonten für jede Komponente wurden von den Apigee Hybrid-Diagrammen erstellt, als Sie die helm upgrade-Befehle ausgeführt haben.

Wichtig:Sie verwenden nicht jedes Kubernetes-Dienstkonto, das mit diesem Befehl aufgeführt ist.

Gewähren Sie den Kubernetes-Dienstkonten Zugriff, um die Identität der zugehörigen IAM-Dienstkonten zu übernehmen, wie in der folgenden Tabelle dargestellt. In der Tabelle sind die Standardnamen der Apigee IAM-Dienstkonten aufgeführt. Wenn Sie benutzerdefinierte Dienstkontonamen verwenden, verwenden Sie die entsprechenden IAM-Dienstkonten:

Kubernetes-Dienstkonten	IAM-Dienstkonto
Kubernetes-Dienstkonten auf Organisationsebene
`apigee-connect-agent-ORG_NAME-ORG_HASH_ID`	`apigee-mart`
`apigee-mart-ORG_NAME-ORG_HASH_ID`	`apigee-mart`
`apigee-metrics-apigee-telemetry`	`apigee-metrics`
`apigee-open-telemetry-collector-apigee-telemetry`	`apigee-metrics`
`apigee-udca-ORG_NAME-ORG_HASH_ID`	`apigee-udca`
`apigee-watcher-ORG_NAME-ORG_HASH_ID`	`apigee-watcher`
Kubernetes-Dienstkonten auf Umgebungsebene
`apigee-runtime-ORG_NAME-ENV_NAME-ENV_HASH_ID`	`apigee-runtime`
`apigee-synchronizer-ORG_NAME-ENV_NAME-ENV_HASH_ID`	`apigee-synchronizer`
Cassandra-Sicherung und -Wiederherstellung (falls aktiviert)
`apigee-cassandra-backup-sa`	`apigee-cassandra`
`apigee-cassandra-restore-sa`	`apigee-cassandra`

Wobei:

ORG_NAME: Die ersten 15 Zeichen des Namens Ihrer Organisation.
ORG_HASH_ID: Eine eindeutige Hash-ID des vollständigen Namens Ihrer Organisation.
ENV_NAME: Die ersten 15 Zeichen des Namens Ihrer Umgebung.
ENV_HASH_ID: Eine eindeutige Hash-ID der Namen Ihrer Organisation und Umgebung.

Beispiel:

apigee-connect-agent-myhybridorg-123abcd
apigee-runtime-myhybridorg-prodenv-234bcde

Gewähren Sie jedem Kubernetes-Dienstkonto mit dem folgenden Befehl Zugriff, um die Identität des entsprechenden IAM-Dienstkontos zu übernehmen:

gcloud iam service-accounts add-iam-policy-binding \
  IAM_SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/MAPPED_SUBJECT" \
    --role=roles/iam.workloadIdentityUser

Wobei:

IAM_SA_NAME ist der Name des Dienstkontos.
PROJECT_ID: Die ID des Projekts, das mit der Apigee-Organisation verknüpft ist.
PROJECT_NUMBER: die Projektnummer des Projekts, in dem Sie den Workload Identity-Pool erstellt haben.
POOL_ID: die ID des Workload Identity-Pools.
MAPPED_SUBJECT: das Kubernetes-Dienstkonto aus dem Anspruch in Ihrem ID-Token, das Sie google.subject zugeordnet haben. Wenn du beispielsweise google.subject=assertions.sub zugeordnet hast und dein ID-Token "sub": "system:serviceaccount:default:my-kubernetes-serviceaccount" enthält, ist MAPPED_SUBJECT system:serviceaccount:default:my-kubernetes-serviceaccount.

Weitere Informationen zur Workload Identity-Föderation und zu Best Practices finden Sie unter Best Practices für die Verwendung der Workload Identity-Föderation.

Workload Identity-Föderation auf AKS und EKS aktivieren

Übersicht

Identitätsföderation von Arbeitslasten einrichten

Hinweise

Konfigurieren Sie Ihren Cluster für die Verwendung der Identitätsföderation von Arbeitslasten.

Console

Befehlszeile

Erforderliche Rollen

AKS

EKS

Andere Kubernetes

Öffentlich zugänglich

Nicht öffentlich zugänglich

Konfigurationsdateien für Anmeldedaten erstellen

Prod

Non-prod

Code

Beispiel

Apigee Hybrid für die Verwendung der Identitätsföderation von Arbeitslasten konfigurieren

Prod

Non-prod

Code

Beispiel

Zertifikatsdatei

K8s-Secret

Vault

Zugriff auf die Kubernetes-Dienstkonten gewähren