Workload Identity-Föderation auf AKS und EKS aktivieren

Sie sehen sich gerade die Version 1.14 der Apigee Hybrid-Dokumentation an. Weitere Informationen finden Sie unter Unterstützte Versionen.

Version 1.14 

   Supported versions:

• v1.15 (latest)                        
• v1.14                        
• v1.13                         
• List of supported versions

   Unsupported versions:

• v1.12                         
• v1.11                         
• v1.10                                      
• v1.9                                         
• v1.8                                         
• v1.7                                         
• v1.6                                         
• v1.5                                         
• v1.4                                         
• v1.3                                         
• v1.2                                         
• v1.1                                         

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 der GKE folgen Sie der Anleitung unter Workload Identity in GKE aktivieren.

Übersicht

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

Die Identitätsföderation von Arbeitslasten kann zur Verbesserung der Sicherheit beitragen. Anwendungen können die Authentifizierungsmechanismen der externen Umgebung nutzen 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 die Apigee Hybrid-Installation an.

Hinweis

In dieser Anleitung wird davon ausgegangen, dass Sie Ihre Apigee Hybrid-Installation bereits eingerichtet haben. Die IAM- 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-Aussteller (OIDC) aktiviert sein. Sie müssen diese Funktion aktivieren, damit die Identitätsföderation von Arbeitslasten auf die OpenID Connect-Metadaten und das JSON Web Key Set (JWKS) für den Cluster zugreifen kann.

Hinweis: Wenn der Cluster aus irgendeinem Grund gelöscht wird, muss der IAM-Anbieter neu erstellt werden.

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

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

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

   Falls die API nicht aktiviert ist:

   Console

   Enable the Security Token Service API.

   Roles required to enable APIs

   To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

   Enable the API

   Befehlszeile

   Aktivieren Sie die API mit dem folgenden Befehl:

   gcloud services enable sts.googleapis.com --project PROJECT_ID

3. Erstellen Sie den Workload Identity-Pool und Provider.

   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 Identitätsföderation von Arbeitslasten 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 Owner“ (roles/owner) auch Berechtigungen zum Konfigurieren der Identitätsföderation. In einer Produktionsumgebung sollten Sie keine einfachen Rollen zuweisen, in einer Entwicklungs- oder Testumgebung ist dies aber unproblematisch.

   So erstellen Sie einen Workload Identity-Pool und Provider:

   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 ist der Name des Clusters.
      • RESOURCE_GROUP ist die Ressourcengruppe des Clusters.

      Der Befehl gibt die Aussteller-URL aus. Sie benötigen diese in einem der folgenden Schritte.

      Falls der Befehl keine Aussteller-URL zurückgibt, prüfen Sie, ob Sie die Funktion 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 diese in einem der folgenden Schritte.

      Andere Kubernetes-Produkte

      1. Stellen Sie eine Verbindung zu Ihrem Kubernetes-Cluster her und finden Sie mit „kubectl“ die Aussteller-URL des Clusters heraus:

         kubectl get --raw /.well-known/openid-configuration | jq -r .issuer
         

         Sie benötigen diese in einem der folgenden Schritte.

   2. Optional: Wenn der 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: Bei Verwendung der JWKS-Datei müssen Sie jedes Mal 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 ist die eindeutige ID des Pools.
      • DISPLAY_NAME (optional) ist der Name des Pools.
      • DESCRIPTION (optional) ist 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 Provider hinzu. Wählen Sie den Befehl zum Erstellen des Providers abhängig davon aus, ob der OIDC-Aussteller öffentlich zugänglich oder nicht öffentlich zugänglich ist:

      Öffentlich zugänglich

      Wenn der OIDC-Aussteller öffentlich zugänglich ist, erstellen Sie den Provider 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 der OIDC-Aussteller nicht öffentlich zugänglich ist, erstellen Sie den Provider 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.

      Durch den Befehl wird das JWKS des Clusters nicht validiert. Wenn es 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 ist eine eindeutige Provider-ID Ihrer Wahl für den Workload Identity-Pool.
      • POOL_ID ist die ID des Workload Identity-Pools, die Sie zuvor erstellt haben.
      • ISSUER ist die Aussteller-URL, die Sie zuvor für den Aussteller-URI herausgefunden haben.

      attribute-mapping="google.subject=assertion.sub" ordnet das Kubernetes-Subjekt dem IAM-Subjekt zu.

Konfigurationsdateien mit Anmeldedaten erstellen

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

1. 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 Tool create-service-account 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 in der Installationsanleitung in Schritt 4: Dienstkonten erstellen.

   Sie müssen Konfigurationsdateien mit 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
   

   Wenn Sie Monetization for Apigee Hybrid in v1.14.3 oder höher verwenden, müssen Sie auch die Konfigurationsdatei mit Anmeldedaten für das apigee-mint-task-scheduler-Dienstkonto erstellen.

   DISPLAY NAME                 EMAIL                                                              DISABLED
   ...
   apigee-mint-task-scheduler   apigee-mint-task-scheduler@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 Ihre Dienstkonten benutzerdefinierte Namen haben, die nicht den Namen der Apigee-Komponenten entsprechen, können Sie die Rolle jedes Dienstkontos herausfinden, indem Sie die zugewiesenen Rollen mit den Rollen vergleichen, die unter Informationen zu Dienstkonten empfohlen werden.

   Mit dem folgenden Befehl können Sie die einem Dienstkonto zugewiesenen Rollen prüfen:

   gcloud projects get-iam-policy PROJECT_ID  \
     --flatten="bindings[].members" \
     --format='table(bindings.role)' \
     --filter="SERVICE_ACCOUNT_NAME"

   Notieren Sie sich für jedes IAM-Dienstkonto in der vorherigen Liste das entsprechende benutzerdefinierte Dienstkonto.

2. Erstellen Sie für jedes IAM-Dienstkonto in der vorherigen Liste eine Konfigurationsdatei mit Anmeldedaten. Sie benötigen diese Dateien, um Apigee Hybrid für die Verwendung der Identitätsföderation von Arbeitslasten 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/run/service-account/token \
     --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=[e-mail] \
     --credential-source-file=/var/run/service-account/token \
     --credential-source-type=text \
     --output-file=apigee-cassandra-credential-configuration.json
     

   Dabei gilt:

   • PROJECT_NUMBER ist die Projektnummer des Projekts, das den Workload Identity-Pool enthält. Dies muss die Projektnummer und nicht die Projekt-ID sein.
   • POOL_ID ist die ID des Workload Identity-Pools.
   • WORKLOAD_PROVIDER_ID ist die ID des Workload Identity Providers.
   • SERVICE_ACCOUNT_EMAIL ist die E‑Mail-Adresse des Dienstkontos, wenn Sie Ihr Kubernetes-Dienstkonto für die Identitätsübernahme des IAM-Dienstkontos konfiguriert haben.
   Wichtig: credential-source-type muss auf text festgelegt sein.
   Hinweis: Erstellen Sie keine Konfigurationsdatei mit Anmeldedaten für das Dienstkonto apigee-logger.

   Die Konfigurationsdatei mit Anmeldedaten gibt den [Cloud-Clientbibliotheken](/apis/docs/cloud-client-libraries) der gcloud CLI und Terraform folgende Informationen:

   • Wo externe Anmeldedaten abgerufen werden können
   • Welcher Workload Identity-Pool und Provider verwendet werden sollen
   • Die Identität welches Dienstkontos übernommen werden soll
   Hinweis: Im Gegensatz zu einem Dienstkontoschlüssel enthält eine Konfigurationsdatei mit Anmeldedaten keine privaten Schlüssel und muss nicht vertraulich behandelt werden. Details zur Konfigurationsdatei mit Anmeldedaten finden Sie unter https://google.aip.dev/auth/4117.

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

   Tipp: Sie können die Hybridinstallation so konfigurieren, dass die Identitätsföderation von Arbeitslasten für alle oder nur bestimmte Komponenten verwendet wird. Beispielsweise kann UDCA die Identitätsföderation von Arbeitslasten verwenden, während Synchronizer Google IAM-Dienstkonten nutzt oder umgekehrt.
   1. Kopieren oder verschieben Sie alle Ausgabedateien (SERVICE_ACCOUNT_NAME-credential-configuration.json) in die folgenden Diagrammverzeichnisse (oder Unterverzeichnisse davon). Das sind die Dateien, die Sie im Schritt Konfigurationsdateien mit Anmeldedaten erstellen erstellt haben.

      Prod

      Dienstkonto	Apigee Helm-Diagrammverzeichnis
      apigee-cassandra	apigee-datastore/
      apigee-mart	apigee-org/
      apigee-metrics	apigee-telemetry/
      apigee-mint-task-scheduler (Bei Verwendung der Monetarisierung für Apigee Hybrid)	apigee-org/
      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/

   2. 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"
      

      Hinweis: Siehe

      • gcp.workloadIdentity.enabled
      • gcp.federatedWorkloadIdentity.enabled
      • gcp.federatedWorkloadIdentity.audience
      • gcp.federatedworkloadIdentity.credentialSourceFile

      Dabei gilt: AUDIENCE ist die zulässige Zielgruppe des Workload Identity Providers. Sie finden den Wert, indem Sie in den Konfigurationsdateien mit Anmeldedaten nach dem Begriff audience: suchen. Der entsprechende Wert ist in allen Dateien gleich.

      Nehmen wir als Beispiel die folgende Datei apigee-udca-credential-configuration.json:

      {
        "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/[e-mail]:generateAccessToken",
        "credential_source": {
          "file": "/var/run/service-account/token",
          "format": {
            "type": "text"
          }
        }
      }

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

   3. Konfigurieren Sie die Überschreibungen für jede Komponente mit der Identitätsföderation von Arbeitslasten. Wählen Sie je nach Installation die Anleitung für Zertifikatsdateien, Kubernetes-Secrets oder Vault 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
      
      mintTaskScheduler: # Required for Monetization for Apigee hybrid (v1.14.3 and later)
        serviceAccountPath: apigee-mint-task-scheduler-credential-configuration.json
      
      udca:
        serviceAccountPath: apigee-udca-credential-configuration.json
      
      watcher:
        serviceAccountPath: apigee-watcher-credential-configuration.json
      

      Kubernetes-Secret

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

         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"

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

   4. 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 Diagramm apigee-env für jede Umgebung und ersetzen Sie dabei jeweils $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 Kubernetes-Dienstkonten zuweisen

   1. 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 alle Kubernetes-Dienstkonten, die durch diesen Befehl aufgelistet werden.
   2. 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 haben, 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-mint-task-scheduler-ORG_NAME-ORG_HASH_ID (Wenn Sie Monetization for Apigee Hybrid in v1.14.3 und höher verwenden)	apigee-mint-task-scheduler
      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

      Dabei gilt:

      • ORG_NAME enthält die ersten 15 Zeichen des Namens Ihrer Organisation.
      • ORG_HASH_ID ist eine eindeutige Hash-ID des vollständigen Namens Ihrer Organisation.
      • ENV_NAME enthält die ersten 15 Zeichen des Namens Ihrer Umgebung.
      • ENV_HASH_ID ist eine eindeutige Hash-ID Ihres Organisations- und Umgebungsnamens.

      Beispiel:

      • apigee-connect-agent-myhybridorg-123abcd
      • apigee-runtime-myhybridorg-prodenv-234bcde
      Wichtig:Sie müssen diesen Schritt für jede Umgebung wiederholen.

      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

      Dabei gilt:

      • IAM_SA_NAME ist der Name des Dienstkontos.
      • PROJECT_ID ist die ID des Projekts, das mit der Apigee-Organisation verknüpft ist.
      • PROJECT_NUMBER ist die Projektnummer des Projekts, in dem Sie den Workload Identity-Pool erstellt haben.
      • POOL_ID ist die ID des Workload Identity-Pools.
      • MAPPED_SUBJECT ist das Kubernetes-Dienstkonto aus der Anforderung 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.
      Hinweis: Sie müssen die Projektnummer in der Mitglieds-ID verwenden. Die Verwendung der Projekt-ID wird nicht unterstützt.

   Weitere Informationen zur Identitätsföderation von Arbeitslasten und zu Best Practices finden Sie unter Best Practices für die Verwendung der Identitätsföderation von Arbeitslasten.