Workload Identity-Föderation auf AKS und EKS aktivieren

In diesem Thema wird das Aktivieren von Workload Identity für Apigee Hybrid-Installationen auf den Plattformen AKS und EKS erläutert.

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

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.

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

Folgen Sie der Google Cloud-Anleitung zum Konfigurieren der Identitätsföderation von Arbeitslasten für Kubernetes, wobei Sie die folgenden Änderungen vornehmen:

  • Listen Sie Ihre IAM-Dienstkonten und Kubernetes-Dienstkonten mit den folgenden Befehlen auf:
    • IAM-Dienstkonten: 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.

      Mit dem folgenden Befehl können Sie eine Liste der IAM-Dienstkonten in Ihrem Projekt aufrufen: 

      gcloud iam service-accounts list --project PROJECT_ID
    • Kubernetes-Dienstkonten:Die Apigee Hybrid-Diagramme erstellen die erforderlichen Kubernetes-Dienstkonten für jede Komponente, wenn Sie den Befehl helm install oder helm update ausführen.

      Mit den kubectl get sa-Befehlen können Sie die Kubernetes-Dienstkonten in Ihrem Cluster aufrufen: 

      kubectl get sa -n APIGEE_NAMESPACE
kubectl get sa -n apigee-system
  • Im Schritt Identitätsföderation von Arbeitslasten konfigurieren ist die Standardzielgruppe für erstellte Workload Identity-Pools und ‑Anbieter wie unten angegeben. Verwenden Sie diesen Standardwert oder legen Sie eine benutzerdefinierte erwartete Zielgruppe fest und speichern Sie diesen Wert für die spätere Verwendung. 
    https://iam.googleapis.com/projects/PROJECT_NUM/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID
  • Fahren Sie nach Schritt 1 unter Kubernetes-Arbeitslast bereitstellen fort. Für jedes Google-Dienstkonto gibt es eine Konfigurationsdatei mit Anmeldedaten. Speichern Sie jede Konfigurationsdatei für Anmeldedaten und den für den Parameter --credential-source-file eingegebenen Pfad, z. B. /var/run/service-account/token.

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

  1. Kopieren Sie die Datei mit den Anmeldedaten und die Ausgabedatei (credential-configuration.json) in die folgenden Diagrammverzeichnisse. Das sind die Werte, die Sie in Schritt 1 unter Kubernetes-Arbeitslast bereitstellen angegeben haben.
    • apigee-datastore/
    • apigee-env
    • apigee-org/
    • apigee-telemetry/
  2. Nehmen Sie die folgenden globalen Änderungen an der Überschreibungsdatei Ihres Clusters vor: 
    gcp:
  workloadIdentity:
    enabled: false # must be set to false to use Workload Identity Federation
  federatedWorkloadIdentity:
    enabled: true
    audience: "AUDIENCE"
    credentialSourceFile: "CREDENTIAL_SOURCE_FILE"

    Wobei:

    • AUDIENCE ist die zulässige Zielgruppe des Workload Identity-Anbieters, der Wert unter .audience in der JSON-Datei zur Konfiguration der Anmeldedaten, die Sie in Schritt 1 unter Kubernetes-Arbeitslast bereitstellen konfiguriert haben.
    • CREDENTIAL_SOURCE_FILE ist der Dateiname und der Pfad zur Anmeldedaten-Quelldatei, die von der Identitätsföderation von Arbeitslasten verwendet wird, um die Anmeldedaten für die Dienstkonten abzurufen. Das ist der Wert, den Sie für credential-source-file angeben, wenn Sie die Identitätsföderation von Arbeitslasten mit dem Befehl create-cred-config in Schritt 1 unter Kubernetes-Arbeitslast bereitstellen konfigurieren. Beispiel:

      • Beispiel:

      gcp:
  workloadIdentity:
    enabled: false
  federatedWorkloadIdentity:
    enabled: true
    audience: "//iam.googleapis.com/projects/123456789012/locations/global/workloadIdentityPools/aws-pool/providers/aws-provider"
    credentialSourceFile: "/var/run/service-account/token"
  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. Dies muss der Pfad relativ zum Diagrammverzeichnis sein. Beispiel:

    udca:
  serviceAccountPath: fwi/credential-configuration.json

    Kubernetes-Secret

    1. Erstellen Sie mit der Anmeldedaten-Quelldatei ein neues Kubernetes-Secret. 
      kubectl create secret -n apigee generic SECRET_NAME --from-file="client_secret.json=CREDENTIAL_CONFIGURATION_FILE"

      Beispiel:

      kubectl create secret -n apigee generic udca-fwi-secret --from-file="client_secret.json=./fwi/credential-configuration.json"
    2. Ersetzen Sie den Wert von serviceAccountRef durch das neue Secret. Beispiel: 
      udca:
  serviceAccountRef: udca-fwi-secret

    Vault

    Aktualisieren Sie den Dienstkontoschlüssel SAKEY in Vault mit der Anmeldedaten-Quelldatei. Für UDCA (das Verfahren ist für alle Komponenten beispielsweise ähnlich): 

    SAKEY=$(cat ./fwi/credential-configuration.json); kubectl -n apigee exec vault-0 -- vault kv patch secret/apigee/orgsakeys udca="$SAKEY"
  4. Wenden Sie die Änderungen mit dem Befehl helm update auf jede betroffene Komponente an:

    Wenn Sie Vault zum ersten Mal mit diesem Cluster verwenden, aktualisieren Sie das apigee-operator-Diagramm: 

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

    Aktualisieren Sie die restlichen betroffenen Diagramme in der folgenden Reihenfolge: 

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

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

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

    Aktualisieren Sie das Diagramm apigee-env für jede Umgebung und ersetzen Sie dabei jeweils ENV_NAME: 

    helm upgrade $ENV_NAME apigee-env/ \
  --namespace apigee \
  --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.

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.