Workload Identity-Föderation auf AKS und EKS aktivieren

In diesem Thema wird erläutert, wie Sie Workload Identity für Apigee Hybrid-Installationen auf AKS- und AKS-Plattformen 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 Platform-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.

Identitätsföderation von Arbeitslasten einrichten

Wenn Sie Workload Identity-Föderation mit Apigee Hybrid verwenden möchten, konfigurieren Sie zuerst den Cluster und wenden Sie das Feature dann auf Ihre Apigee Hybrid-Installation an.

Konfigurieren Sie Ihren Cluster für die Verwendung der Workload Identity-Föderation.

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

  • Mit den folgenden Befehlen können Sie Ihre IAM-Dienstkonten und Kubernetes-Dienstkonten auflisten:
    • 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. Unter Informationen zu Dienstkonten finden Sie eine Liste der IAM-Dienstkonten, die von Apigee Hybrid benötigt werden.

      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.

      Sie können die Kubernetes-Dienstkonten in Ihrem Cluster mit den kubectl get sa-Befehlen 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 Zielgruppe fest und speichern Sie diesen Wert für später. 
    https://iam.googleapis.com/projects/PROJECT_NUM/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID
  • Beenden Sie die Anleitung nach Schritt 1 unter Kubernetes-Arbeitslast bereitstellen. Für jedes Google-Dienstkonto gibt es eine Anmeldedatenkonfigurationsdatei. 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 Workload Identity-Föderation konfigurieren

  1. Kopieren Sie die Quelldatei der Anmeldedaten und die Ausgabedatei (credential-configuration.json) in die folgenden Diagrammverzeichnisse. Dies 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 Anmeldedatenquelle, die von der Workload Identity-Föderation zum Abrufen der Anmeldedaten für die Dienstkonten verwendet wird. Dies ist der Wert, den Sie für credential-source-file angeben, wenn Sie die Workload Identity-Föderation 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 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 Quelldatei der Anmeldedaten. Dies muss der Pfad relativ zum Diagrammverzeichnis sein. Beispiel:

    udca:
  serviceAccountPath: fwi/credential-configuration.json

    K8s-Secret

    1. Erstellen Sie ein neues Kubernetes-Secret für die Quelldatei der Anmeldedaten. 
      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 Diagramm apigee-operator: 

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

    Aktualisieren Sie die übrigen 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 jedes Mal ENV_NAME: 

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

    In der Referenz zu Apigee Hybrid-Helm finden Sie eine Liste der Komponenten und der zugehörigen Diagramme.

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