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 Identitätsföderation von Arbeitslasten können Anwendungen, die außerhalb von Google Cloud ausgeführt werden, die Identität eines Google Cloud Platform-Dienstkontos mithilfe von Anmeldedaten eines externen Identitätsanbieters übernehmen.

Die Identitätsföderation von Arbeitslasten 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.

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.

Hinweis

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-Aussteller (OIDC) aktiviert sein. Sie müssen dieses Feature 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.

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

  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

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

    Wenn die API nicht aktiviert ist:

    Konsole

    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
  3. Workload Identity-Pool und -Anbieter erstellen

    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:

    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, in einer Entwicklungs- oder Testumgebung ist dies aber unproblematisch.

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

      Der Befehl gibt die Aussteller-URL aus. Sie benötigen die Aussteller-URL 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 Ihr OIDC-Aussteller nicht öffentlich zugänglich ist, laden Sie das JSON Web Key Set (JWKS) des Clusters herunter: 
      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 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"

      Ersetzen Sie Folgendes:

      • WORKLOAD_PROVIDER_ID ist eine eindeutige Anbieter-ID für Workload Identity-Pool Ihrer Wahl.
      • POOL_ID ist die ID des Workload Identity-Pools, die 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:

  1. Listen Sie die IAM-Dienstkonten (auch als „Google-Dienstkonten“ bezeichnet) mit dem folgenden Befehl auf: 
    gcloud iam service-accounts list --project PROJECT_ID

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

    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 Verwendung der Identitätsübernahme des IAM-Dienstkontos konfiguriert haben.

    Mithilfe der Konfigurationsdatei mit Anmeldedaten können die [Cloud-Clientbibliotheken](/apis/docs/cloud-client-libraries), die gcloud CLI und Terraform Folgendes feststellen:

    • Wo externe Anmeldedaten abgerufen werden können
    • Welcher Workload Identity-Pool und Provider verwendet werden sollen
    • Die Identität welches Dienstkontos übernommen werden soll

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

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

      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 Zielgruppenwert ist in allen Dateien gleich.

      Beispiel in der 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/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.

    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

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 $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-Diagrammen.

    Zugriff auf die Kubernetes-Dienstkonten gewähren

    1. Listen Sie die Kubernetes-Dienstkonten mit dem folgenden Befehl auf: 
      kubectl get sa -n APIGEE_NAMESPACE
    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-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: 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 Ihres Organisations- und Umgebungsnamens.

      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

      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.

    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.