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 Workload Identity-Föderation.

Workload Identity-Föderation 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 von Workload Identity-Föderation für Kubernetes mit den folgenden Änderungen:

Im Schritt Workload Identity-Föderation konfigurieren ist die Standardzielgruppe für erstellte Workload Identity-Pools und -Anbieter folgende: Verwenden Sie diese Standardeinstellung oder legen Sie eine benutzerdefinierte erwartete Zielgruppe fest und speichern Sie diesen Wert zur späteren Verwendung.
```
https://iam.googleapis.com/projects/PROJECT_NUM/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID
```
Sie müssen die Schritte unter Dienstkontopaar erstellen nicht ausführen, da die benötigten Dienstkonten bereits erstellt worden sein sollten:
- 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.
  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
```
Beenden Sie nach Schritt 1 unter Kubernetes-Arbeitslast bereitstellen. Speichern Sie die Konfigurationsdatei für Anmeldedaten und speichern Sie den für den Parameter --credential-source-file eingegebenen Pfad, z. B. /var/run/service-account/token.
Hinweis: Sie finden die Werte für audience und credentialSourceFile auch in der JSON-Datei für die Anmeldedatenkonfiguration unter den Pfaden .audience und .credential_source.file. . Sie benötigen diese Werte für die Überschreibungsdatei, um Apigee Hybrid zu konfigurieren.

Apigee Hybrid für die Verwendung der Workload Identity-Föderation konfigurieren

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/
Tipp: Sie können für diese Dateien ein Unterverzeichnis verwenden, z. B.: apigee-datastore/fwi/
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:
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"
```

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.