Diese Seite wurde von der Cloud Translation API übersetzt.

Workload Identity-Föderation auf AKS und EKS aktivieren

In diesem Thema wird das Aktivieren der Identitätsföderation von Arbeitslasten für Apigee Hybrid-Installationen auf den Plattformen AKS und EKS erläutert.

Bei 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, konfigurieren Sie zuerst Ihren Cluster und wenden Sie die Funktion dann auf Ihre Apigee Hybrid-Installation an.

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. Einen Überblick über die Installation von Apigee Hybrid finden Sie unter Allgemeiner Überblick.

Bei Installationen auf AKS muss der OpenID Connect (OIDC)-Aussteller aktiviert sein. Sie müssen dieses Feature 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 -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-Produkte
  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 eine neue JWKS-Datei hochladen, wenn Sie die Signaturschlüssel für den Cluster rotieren.
```
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 die Anbieter-URL zugreifen und eine 200-Antwort erhalten können.
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 ausgewä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, den Sie zuvor erstellt haben.
  - ISSUER: Verwenden Sie die Aussteller-URL, die Sie zuvor ermittelt haben, 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 Datei mit Anmeldeinformationen für jedes IAM-Dienstkonto erstellen:

Listen Sie die IAM-Dienstkonten (auch als „Google-Dienstkonten“ bezeichnet) mit dem folgenden Befehl auf:
```
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 create-service-account-Tool erstellt. Eine Liste der von Apigee Hybrid benötigten IAM-Dienstkonten 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 einzelnen IAM-Dienstkonten in der vorherigen Liste entspricht.

Erstellen Sie für jedes IAM-Dienstkonto in der vorherigen Liste eine Datei mit Anmeldeinformationen. 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 und nicht die 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 für die Verwendung der Identitätsübernahme des IAM-Dienstkontos konfiguriert haben.

Wichtig:credential-source-type muss auf text festgelegt werden.

Hinweis:Erstellen Sie keine Datei mit der Konfiguration der 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 davon). Das sind 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 gilt: AUDIENCE ist 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 Zielgruppenwert ist in jeder Anmeldedatenkonfigurationsdatei derselbe.

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 mit der Identitätsföderation von Arbeitslasten. Wählen Sie die Anleitung für Zertifikatsdateien, Kubernetes-Secrets oder Vault entsprechend Ihrer Installation aus.

Zertifikatsdatei

Ersetzen Sie den Wert von serviceAccountPath durch die Anmeldedaten-Quelldatei 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: apigee-udca-credential-configuration.json

mart:
  serviceAccountPath: apigee-mart-credential-configuration.json

connectAgent:
  serviceAccountPath: apigee-mart-credential-configuration.json

metrics:
  serviceAccountPath: apigee-metrics-credential-configuration.json

udca:
  serviceAccountPath: apigee-udca-credential-configuration.json

watcher:
  serviceAccountPath: apigee-watcher-credential-configuration.json

K8s-Secret

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

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. Das Verfahren ist für alle Komponenten ähnlich. Beispiel für UDCA:

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 apigee-operator-Diagramm.

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 $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 der entsprechenden Diagramme finden Sie in der Referenz zu Apigee Hybrid-Helm.

Zugriff auf die Kubernetes-Dienstkonten gewähren

Listen Sie die Kubernetes-Dienstkonten mit dem folgenden Befehl auf:
```
kubectl get sa -n APIGEE_NAMESPACE
```
Hinweis:Die Apigee Hybrid-Diagramme haben die erforderlichen Kubernetes-Dienstkonten für jede Komponente erstellt, als Sie die helm upgrade-Befehle ausgeführt haben.

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

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 für 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 Ihrer Organisations- und Umgebungsnamen.

Beispiel:

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

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

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 Sie beispielsweise google.subject=assertions.sub zugeordnet haben und Ihr 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 Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

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

Ö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

Workload Identity-Föderation auf AKS und EKS aktivieren