Identitätsföderation von Arbeitslasten in 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 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 Workload Identity-Föderation für Kubernetes, wobei Sie die folgenden Änderungen vornehmen:

Im Schritt Workload Identity-Föderation 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
```
Sie sollten die Schritte unter Dienstkontenpaar 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.
  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
```
Beenden Sie die Anleitung nach Schritt 1 unter Kubernetes-Arbeitslast bereitstellen. Speichern Sie die Konfigurationsdatei für die 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 zur Konfiguration der Anmeldedaten 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 Identitätsföderation von Arbeitslasten konfigurieren

Kopieren Sie die Quelldatei der 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/
Tipp:Sie können für diese Dateien ein Unterverzeichnis verwenden. Beispiel: 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 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 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 und verwenden Sie die Anmeldedatenquelle als Datei.
  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. Beispiel für UDCA (das Verfahren ist für alle Komponenten ä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_NAMESPACE \
  --atomic \
  -f overrides.yaml

Aktualisieren Sie die übrigen 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 dabei 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 Apigee Hybrid Helm-Referenz.

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