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 EKS-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-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 die Identitätsföderation von Arbeitslasten mit Apigee Hybrid verwenden möchten, müssen Sie zuerst Ihren Cluster konfigurieren und dann die Funktion auf Ihre Apigee Hybrid-Installation anwenden.

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

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 die 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 IAM-Dienstkonten, die für Apigee Hybrid erforderlich sind, 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.

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

      kubectl get sa -n APIGEE_NAMESPACE
  • 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 Identitätsföderation von Arbeitslasten konfigurieren

  1. Kopieren Sie die Quelldatei für Anmeldedaten und die Ausgabedatei (credential-configuration.json) in die folgenden Diagrammverzeichnisse. Das waren 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 Identitätsföderation von Arbeitslasten. 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 Anmeldedatenquelle. Dies muss der Pfad relativ zum Diagrammverzeichnis sein. Beispiel:

    udca:
  serviceAccountPath: fwi/credential-configuration.json

    K8s-Secret

    1. Erstellen Sie ein neues Kubernetes-Secret und verwenden Sie die Anmeldedatenquelle als Datei. 
      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-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_NAMESPACE 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_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 jedes Mal ENV_NAME: 

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

    Eine Liste der Komponenten und ihrer entsprechenden Diagramme finden Sie in der Referenz zu Apigee Hybrid-Helm-Diagrammen.

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.