Identitätsföderation von Arbeitslasten für GKE aktivieren

In diesem Thema wird das Aktivieren von Workload Identity Federation for GKE für Apigee Hybrid erläutert.

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

Mit Workload Identity Federation for GKE können Anwendungen, die in GKE (Google Kubernetes Engine) ausgeführt werden, auf Dienste Google Cloud zugreifen. Übersichten zu Workload Identity Federation for GKE 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.

Auch Kubernetes verfügt ü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, Google-Dienstkonten sind Google Cloud-spezifisch. 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 Federation for GKE 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 (in der Regel 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=MY_ORG_NAME
export ENV_NAME=MY_ENV_NAME
export NAMESPACE=APIGEE_NAMESPACE
export CLUSTER_LOCATION=MY_CLUSTER_LOCATION
export CLUSTER_NAME=MY_CLUSTER_NAME

Workload Identity Federation for GKE 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 Federation for GKE 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 Federation for GKE löschen. Bei den meisten Installationen befinden sie sich im Verzeichnis des Diagramms der einzelnen Komponenten.

Workload Identity Federation for GKE für Apigee Hybrid aktivieren

Folgen Sie dieser Anleitung, um Ihr Projekt für die Verwendung von Workload Identity Federation for GKE zu konfigurieren.

Workload Identity Federation für GKE konfigurieren

  1. Prüfen Sie, ob Workload Identity Federation for GKE in Ihrer Überschreibungsdatei aktiviert ist. Sie sollte in der Überschreibungsdatei aktiviert sein und Sie sollten Werte für die folgenden Konfigurationsattribute haben:
  2. Prüfen Sie mit dem folgenden Befehl, ob die aktuelle gcloud-Konfiguration auf Ihre Google Cloud-Projekt-ID festgelegt ist: 
    gcloud config get project

    3. Legen Sie gegebenenfalls die aktuelle gcloud-Konfiguration fest:

    gcloud config set project $PROJECT_ID
  3. Prüfen Sie, ob Workload Identity Federation for GKE für Ihren GKE-Cluster aktiviert ist. Wenn Sie den Cluster in Schritt 1: Cluster erstellen erstellt haben, wurde in Schritt 6 die Workload Identity Federation for GKE aktiviert. Bestätigen Sie mit dem folgenden Befehl:
    dass Workload Identity Federation for GKE 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 null in den Ergebnissen angezeigt wird, führen Sie den folgenden Befehl aus, um Workload Identity Federation for GKE 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

  4. Aktivieren Sie Workload Identity Federation for GKE 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.

  5. Prüfen Sie mit den folgenden Befehlen, ob Workload Identity Federation for GKE 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

Installation für die Verwendung von Workload Identity Federation for GKE konfigurieren

Gehen Sie so vor, um Workload Identity Federation for GKE für die folgenden Hybridkomponenten zu aktivieren:

  • apigee-datastore
  • apigee-telemetry
  • apigee-org
  • apigee-env

Wenn Sie die helm upgrade mit den --dry-run oder --dry-run=server Flags für die apigee-datastore, apigee-env, apigee-org und apigee-telemetry Diagramme ausführen, enthält die Ausgabe die Befehle, die Sie dazu benötigen, Workload Identity Federation for GKE mit den richtigen GSA- und KSA-Namen zu konfigurieren.

Beispiel:

helm upgrade datastore apigee-datastore/ \
  --namespace $NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server

Die Ausgabe sieht in etwa so aus:

NAME: datastore
...
For Cassandra backup, please make sure to add the following membership to the IAM policy binding using the respective kubernetes SA (KSA).
gcloud iam service-accounts add-iam-policy-binding apigee-cassandra@PROJECT_ID.iam.gserviceaccount.com \
      --role roles/iam.workloadIdentityUser \
      --member "serviceAccount:PROJECT_ID.svc.id.goog[APIGEE_NAMESPACE/apigee-cassandra-default]" \
      --project PROJECT_ID

kubectl annotate serviceaccount apigee-cassandra-default \
      iam.gke.io/gcp-service-account=apigee-cassandra@PROJECT_ID.iam.gserviceaccount.com \
      --namespace APIGEE_NAMESPACE

Wobei:

  • apigee-cassandra der Name des Google-Dienstkontos (GSA) für Cassandra ist. Weitere Informationen finden Sie unter Dienstkonten.
  • PROJECT_ID durch Ihre Google Cloud-Projekt-ID ersetzt wird.
  • APIGEE_NAMESPACE durch Ihren Apigee-Namespace ersetzt wird, standardmäßig apigee.
  • apigee-cassandra-default der Name des Kubernetes-Dienstkontos für die Cassandra-Pods ist, die vom Diagramm apigee-datastore erstellt wurden.
  1. Rufen Sie den Befehl zum Einrichten von Workload Identity Federation for GKE für apigee-datastore ab und führen Sie die Befehle unter NOTES: in der Ausgabe aus. 
    helm upgrade datastore apigee-datastore/ \
  --namespace $NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server
  2. Rufen Sie die Befehle zum Einrichten von Workload Identity Federation for GKE für apigee-telemetry ab und führen Sie sie unter NOTES: in der Ausgabe aus. 
    helm upgrade telemetry apigee-telemetry/ \
  --namespace $NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run
  3. Rufen Sie die Befehle zum Einrichten von Workload Identity Federation for GKE für apigee-org ab und führen Sie sie unter NOTES: in der Ausgabe aus. 
    helm upgrade $ORG_NAME apigee-org/ \
  --namespace $NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run
  4. Rufen Sie die Befehle zum Einrichten von Workload Identity Federation for GKE für apigee-env ab und führen Sie sie unter NOTES: in der Ausgabe aus. 
    helm upgrade $ENV_NAME apigee-env/ \
  --namespace $NAMESPACE \
  --set env=$ENV_NAME \
  -f OVERRIDES_FILE \
  --dry-run

    Wiederholen Sie diesen Schritt für jede Umgebung in Ihrer Installation.

Workload Identity Federation für GKE prüfen

  1. 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
  2. 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}')
  3. Logs prüfen: 
    kubectl logs -n $NAMESPACE -l app=apigee=synchronizer,env=$ENV_NAME,org=$ORG_NAME apigee-synchronizer
  4. (Optional) Sie können den Status Ihrer Kubernetes-Dienstkonten auf der Seite Kubernetes: Arbeitslasten – Übersicht von Google Cloud consolesehen.

    Zu Arbeitslasten

Schutzmaßnahmen mit Workload Identity Federation für GKE einrichten

Sie können Schutzmaßnahmen bei der Erstinstallation des Diagramms apigee-operator verwenden, um zu prüfen, ob die richtigen APIs für Ihr Projekt aktiviert sind. Wenn Sie Ihre Installation mit Workload Identity Federation for GKE konfigurieren möchten, um Schutzmaßnahmen während der Installation zu verwenden, müssen Sie die Bindung manuell einrichten, bevor Sie den Befehl helm upgrade ausführen.

  1. Rufen Sie die E‑Mail-Adresse der GSA für Schutzmaßnahmen mit dem folgenden Befehl ab: 
    gcloud iam service-accounts list --project ${PROJECT_ID} --filter "apigee"

    GSA-E‑Mail-Adressen haben normalerweise folgendes Format:

    GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

    Beispiel:

    DISPLAY NAME       EMAIL                                                DISABLED
apigee-guardrails  apigee-guardrails@myproject.iam.gserviceaccount.com  False

    Verwenden Sie diese E‑Mail-Adresse für die Variable GSA_EMAIL in den nächsten beiden Schritten.

  2. Prüfen Sie, ob der Abschnitt guardrails in Ihrer Datei overrides.yaml vorhanden ist: 
    guardrails:
  gsa: GSA_EMAIL
  3. Die KSA für Schutzmaßnahmen heißt apigee-operator-guardrails-sa. Erstellen Sie die Bindung für die GSA für Schutzmaßnahmen mit dem folgenden Befehl: 
    gcloud iam service-accounts add-iam-policy-binding GSA_EMAIL \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[APIGEE_NAMESPACE/apigee-operator-guardrails-sa]" \
  --project PROJECT_ID

Wenn Sie den Befehl helm upgrade für das Diagramm apigee-operator ausführen, erstellt das Diagramm einen Pod für Schutzmaßnahmen, um zu prüfen, ob die erforderlichen APIs für Ihr Projekt aktiviert sind. Wenn erforderliche APIs nicht aktiviert sind, schlägt der Pod fehl und die Installation wird beendet. Sie können die Logs des Pods für Schutzmaßnahmen prüfen, um zu sehen, welche APIs erforderlich, aber nicht aktiviert sind. Weitere Informationen finden Sie unter Probleme mit Schutzmaßnahmen diagnostizieren.