Workload Identity in GKE aktivieren

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:

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 (normalerweise apigee).
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_ID
echo $ORG_NAME
echo $ENV_NAME
echo $NAMESPACE
echo $CLUSTER_LOCATION
echo $CLUSTER_NAME

Initialisieren Sie alle erforderlichen Variablen:

export PROJECT_ID=my-project-id
export 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 sollte true 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).
Prüfen Sie mit dem folgenden Befehl, ob die aktuelle gcloud-Konfiguration auf Ihre Google Cloud-Projekt-ID festgelegt ist:
```
gcloud config get project
```

Legen Sie gegebenenfalls die aktuelle gcloud-Konfiguration fest:

gcloud config set project $PROJECT_ID

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 und apigee-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

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 unter NOTES: 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 unter NOTES: in der Ausgabe aus.
```
helm upgrade telemetry apigee-telemetry/ \
  --namespace $NAMESPACE \
  -f overrides.yaml \
  --dry-run=server
```
Rufen Sie die Befehle zum Einrichten von Workload Identity für apigee-org ab und führen Sie die Befehle unter NOTES: in der Ausgabe aus.
```
helm upgrade $ORG_NAME apigee-org/ \
  --namespace $NAMESPACE \
  -f overrides.yaml \
  --dry-run=server
```
Rufen Sie die Befehle zum Einrichten von Workload Identity für apigee-env ab und führen Sie die Befehle unter NOTES: in der Ausgabe aus.
```
helm upgrade $ENV_NAME apigee-env/ \
  --namespace $NAMESPACE \
  --set env=$ENV_NAME \
  -f overrides.yaml \
  --dry-run=server
```
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.
Zu Arbeitslasten

Hinweis: Für die Dienstkonten apigee-cassandra-backup und apigee-cassandra-restore wird möglicherweise ein Fehlerstatus angezeigt. Das liegt daran, dass Sie derzeit keine Sicherung oder Wiederherstellung ausführen und diese Prozesse noch nicht vollständig konfiguriert wurden. Weitere Informationen zum Sichern und Wiederherstellen in Cassandra finden Sie unter feedbackCassandra-Sicherung – Übersicht.