In diesem Thema wird erläutert, wie Sie Workload Identity für Apigee Hybrid in GKE aktivieren.
Wenn Sie Apigee Hybrid mit AKS oder EKS verwenden, folgen Sie der Anleitung unter Identitätsföderation von Arbeitslasten auf AKS und EKS aktivieren.
Übersicht
Workload Identity ermöglicht Anwendungen, die in GKE ausgeführt werden (Google Kubernetes Engine), auf Google Cloud-Dienste zuzugreifen. Eine Übersicht über Workload Identity finden Sie unter:
- Einführung in Workload Identity: Bessere Authentifizierung für Ihre GKE-Anwendungen
- Workload Identity verwenden
Ein Google Cloud IAM-Dienstkonto ist eine Identität, die eine Anwendung zum Senden von Anfragen an Google APIs verwenden kann. Diese Dienstkonten werden im Dokument als GSA (Google Service Accounts, Google-Dienstkonten) bezeichnet. Weitere Informationen zu GSAs finden Sie unter Dienstkonten.
Unabhängig davon verfügt Kubernetes auch über das Konzept von Dienstkonten. Ein Dienstkonto bietet eine Identität für Prozesse, die in einem Pod ausgeführt werden. Kubernetes-Dienstkonten sind Kubernetes-Ressourcen, während Google-Dienstkonten für Google Cloud spezifisch sind. Informationen zu Kubernetes-Dienstkonten finden Sie in der Kubernetes-Dokumentation unter Dienstkonten für Pods konfigurieren.
Apigee erstellt und verwendet ein Kubernetes-Dienstkonto für jeden Komponententyp, wenn Sie die Helm-Diagramme für diese Komponenten zum ersten Mal installieren. Wenn Sie Workload Identity aktivieren, können die Hybrid-Komponenten mit den Kubernetes-Dienstkonten interagieren.
Bei diesen Verfahren verwendete Umgebungsvariablen
Diese Verfahren verwenden die folgenden Umgebungsvariablen: Legen Sie diese entweder in der Befehls-Shell fest oder ersetzen Sie sie in den Codebeispielen durch die tatsächlichen Werte:
PROJECT_ID
: Die ID Ihres Google Cloud-Projekts.ORG_NAME
: Der Name Ihrer Apigee-Organisation.ENV_NAME
: Der Name der Apigee-Umgebung.NAMESPACE
: Ihr Apigee-Namespace (normalerweiseapigee
).CLUSTER_LOCATION
: Die Region oder Zone des Kubernetes-Clusters, z. B.:us-west1
.CLUSTER_NAME
: Der Name Ihres Clusters.
Überprüfen Sie die Umgebungsvariablen:
echo $PROJECT_IDecho $ORG_NAME
echo $ENV_NAME
echo $NAMESPACE
echo $CLUSTER_LOCATION
echo $CLUSTER_NAME
Initialisieren Sie alle erforderlichen Variablen:
export PROJECT_ID=my-project-idexport ORG_NAME=$PROJECT_ID
export ENV_NAME=my-environment-name
export NAMESPACE=apigee
export CLUSTER_LOCATION=my-cluster-location
export CLUSTER_NAME=my-cluster-name
Workload Identity und Dienstkontoschlüsseldateien
Wenn Sie Apigee Hybrid in GKE ausführen, werden standardmäßig private Schlüssel (.json
-Dateien) für jedes Dienstkonto erstellt und heruntergeladen. Wenn Sie Workload Identity verwenden, müssen Sie keine privaten Schlüssel für Dienstkonten herunterladen und zu den GKE-Clustern hinzufügen.
Wenn Sie Dienstkontoschlüsseldateien im Rahmen Ihrer Apigee Hybrid-Installation heruntergeladen haben, können Sie sie nach dem Aktivieren von Workload Identity löschen. Bei den meisten Installationen befinden sie sich im Verzeichnis für das Zeichen der einzelnen Komponenten.
Workload Identity für Apigee Hybrid aktivieren
Folgen Sie dieser Anleitung, um Workload Identity für Ihr Projekt zu konfigurieren.
Konfiguration von Workload Identity vorbereiten
- Prüfen Sie, ob Workload Identity in Ihrer Überschreibungsdatei aktiviert ist. Es sollte in der Überschreibungsdatei aktiviert werden und Sie sollten Werte für die folgenden Konfigurationsattribute haben:
- Für alle Installationen:
gcp.workloadIdentity.enabled
solltetrue
sein. Beispiel:gcp: workloadIdentity: enabled: true
- Für Produktionsinstallationen:
- Geben Sie für Nicht-Produktionsinstallationen im Attribut
gcp.workloadIdentity.gsa
die Adresse der Nicht-Produktions-GSA an (mit allen erforderlichen IAM-Rollen).
- Für alle Installationen:
- Prüfen Sie mit dem folgenden Befehl, ob die aktuelle
gcloud
-Konfiguration auf Ihre Google Cloud-Projekt-ID festgelegt ist:gcloud config get project
- Prüfen Sie, ob Workload Identity für Ihren GKE-Cluster aktiviert ist. Wenn Sie den Cluster in Schritt 1: Cluster erstellen erstellt haben, wurde in Schritt 6 Workload Identity aktiviert. Mit folgendem Befehl können Sie prüfen, ob Workload Identity aktiviert ist:
Regionale Cluster
gcloud container clusters describe $CLUSTER_NAME \ --region $CLUSTER_LOCATION \ --project $PROJECT_ID \ --flatten 'workloadIdentityConfig'
Zonale Cluster
gcloud container clusters describe $CLUSTER_NAME \ --zone $CLUSTER_LOCATION \ --project $PROJECT_ID \ --flatten 'workloadIdentityConfig'
Ihre Ausgabe sollte so aussehen:
--- workloadPool: PROJECT_ID.svc.id.goog
Wenn stattdessen in den Ergebnissen
null
angezeigt wird, führen Sie den folgenden Befehl aus, um Workload Identity für Ihren Cluster zu aktivieren:Regionale Cluster
gcloud container clusters update $CLUSTER_NAME \ --workload-pool=$PROJECT_ID.svc.id.goog \ --project $PROJECT_ID \ --region $CLUSTER_LOCATION
Zonale Cluster
gcloud container clusters update $CLUSTER_NAME \ --workload-pool=$PROJECT_ID.svc.id.goog \ --zone $CLUSTER_LOCATION \ --project $PROJECT_ID
-
Aktivieren Sie Workload Identity für jeden Knotenpool mit den folgenden Befehlen. Dieser Vorgang kann für jeden Knoten bis zu 30 Minuten dauern:
Regionale Cluster
gcloud container node-pools update NODE_POOL_NAME \ -cluster=$CLUSTER_NAME \ --region $CLUSTER_LOCATION \ --project $PROJECT_ID \ --workload-metadata=GKE_METADATA
Zonale Cluster
gcloud container node-pools update NODE_POOL_NAME \ --cluster=$CLUSTER_NAME \ --zone $CLUSTER_LOCATION \ --project $PROJECT_ID \ --workload-metadata=GKE_METADATA
Dabei ist NODE_POOL_NAME der Name jedes Knotenpools. In den meisten Apigee Hybrid-Installationen heißen die beiden Standardknotenpools
apigee-data
undapigee-runtime
. - Prüfen Sie mit den folgenden Befehlen, ob Workload Identity auf Ihren Knotenpools aktiviert ist:
Regionale Cluster
gcloud container node-pools describe apigee-data \ --cluster $CLUSTER_NAME \ --region $CLUSTER_LOCATION \ --project $PROJECT_ID \ --flatten "config:"
gcloud container node-pools describe apigee-runtime \ --cluster $CLUSTER_NAME \ --region $CLUSTER_LOCATION \ --project $PROJECT_ID \ --flatten "config:"
Zonale Cluster
gcloud container node-pools describe apigee-data \ --cluster $CLUSTER_NAME \ --zone $CLUSTER_LOCATION \ --project $PROJECT_ID \ --flatten "config:"
gcloud container node-pools describe apigee-runtime \ --cluster $CLUSTER_NAME \ --zone $CLUSTER_LOCATION \ --project $PROJECT_ID \ --flatten "config:"
Die Ausgabe sollte in etwa so aussehen:
--- diskSizeGb: 100 diskType: pd-standard ... workloadMetadataConfig: mode: GKE_METADATA
Legen Sie gegebenenfalls die aktuelle gcloud
-Konfiguration fest:
gcloud config set project $PROJECT_ID
Workload Identity konfigurieren
Gehen Sie folgendermaßen vor, um Workload Identity für die folgenden Hybridkomponenten zu aktivieren:
apigee-datastore
apigee-telemetry
apigee-org
apigee-env
Wenn Sie helm upgrade
mit dem Flag --dry-run
oder --dry-run=server
für die Diagramme apigee-datastore
, apigee-env
, apigee-org
und apigee-telemetry
ausführen, enthält die Ausgabe die Befehle, die Sie dazu benötigen, Workload Identity mit den richtigen GSA- und KSA-Namen zu konfigurieren.
Beispiel:
helm upgrade datastore apigee-datastore/ \ --namespace $NAMESPACE \ -f overrides.yaml \ --dry-run=server
NAME: datastore ... For Cassandra backup GKE Workload Identity, please make sure to add the below membership to the IAM policy binding using the respective kubernetes SA (KSA). gcloud iam service-accounts add-iam-policy-binding my-gsa@my-project-id.iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:my-project-id.svc.id.goog[apigee/apigee-cassandra-default]" \ --project my-project-id kubectl annotate serviceaccount apigee-cassandra-default \ iam.gke.io/gcp-service-account=my-gsa@my-project-id.iam.gserviceaccount.com \ --namespace apigee
- Rufen Sie den Befehl zum Einrichten von Workload Identity für
apigee-datastore
ab und führen Sie den Befehl unterNOTES:
in der Ausgabe aus.helm upgrade datastore apigee-datastore/ \ --namespace $NAMESPACE \ -f overrides.yaml \ --dry-run=server
- Rufen Sie die Befehle zum Einrichten von Workload Identity für
apigee-telemetry
ab und führen Sie die Befehle unterNOTES:
in der Ausgabe aus.helm upgrade telemetry apigee-telemetry/ \ --namespace $NAMESPACE \ -f overrides.yaml \ --dry-run
- Rufen Sie die Befehle zum Einrichten von Workload Identity für
apigee-org
ab und führen Sie die Befehle unterNOTES:
in der Ausgabe aus.helm upgrade $ORG_NAME apigee-org/ \ --namespace $NAMESPACE \ -f overrides.yaml \ --dry-run
- Rufen Sie die Befehle zum Einrichten von Workload Identity für
apigee-env
ab und führen Sie die Befehle unterNOTES:
in der Ausgabe aus.helm upgrade $ENV_NAME apigee-env/ \ --namespace $NAMESPACE \ --set env=$ENV_NAME \ -f overrides.yaml \ --dry-run
Wiederholen Sie diesen Schritt für jede Umgebung in Ihrer Installation.
Workload Identity prüfen
- Prüfen Sie, ob die Schritte funktioniert haben:
gcloud config set project $PROJECT_ID
kubectl run --rm -it --image google/cloud-sdk:slim \ --namespace $NAMESPACE workload-identity-test\ -- gcloud auth list
Wenn Sie keine Eingabeaufforderung sehen, drücken Sie die Eingabetaste.
Wenn die Schritte korrekt ausgeführt wurden, wird eine Antwort wie diese angezeigt:
Credentialed Accounts ACTIVE ACCOUNT * GSA@PROJECT_ID.iam.gserviceaccount.com
- Wenn Sie ein Upgrade von einer früheren Installation durchführen, bereinigen Sie die Secrets, die die privaten Schlüssel des Dienstkontos enthielten:
kubectl delete secrets -n $NAMESPACE $(k get secrets -n $NAMESPACE | grep svc-account | awk '{print $1}')
- Prüfen Sie die Logs:
kubectl logs -n $NAMESPACE -l app=apigee=synchronizer,env=$ENV_NAME,org=$ORG_NAME apigee-synchronizer
- (Optional) Sie können den Status Ihrer Kubernetes-Dienstkonten in der Google Cloud Console auf der Seite Kubernetes: Arbeitslasten – Übersicht sehen.