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

In diesem Thema wird das Aktivieren der Identitätsföderation von Arbeitslasten für 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

Die Identitätsföderation von Arbeitslasten für GKE ermöglicht Anwendungen, die in GKE (Google Kubernetes Engine) ausgeführt werden, auf Google Cloud Dienste zuzugreifen. Übersichten über die Identitätsföderation von Arbeitslasten für 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) 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 die Workload Identity-Föderation für GKE aktivieren, können die Hybridkomponenten 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-Föderation für GKE für Apigee Hybrid aktivieren

Folgen Sie dieser Anleitung, um Ihr Projekt für die Verwendung der Identitätsföderation von Arbeitslasten für GKE zu konfigurieren.

Konfiguration von Workload Identity Federation for GKE vorbereiten

  1. Prüfen Sie, ob die Identitätsföderation von Arbeitslasten für GKE in Ihrer Überschreibungsdatei aktiviert ist. Es 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 die Identitätsföderation von Arbeitslasten für GKE für Ihren GKE-Cluster aktiviert ist. Wenn Sie den Cluster in Schritt 1: Cluster erstellen erstellt haben, wurde in Schritt 6 die Identitätsföderation von Arbeitslasten für GKE aktiviert. Prüfen Sie mit dem folgenden Befehl, ob die Identitätsföderation von Arbeitslasten für 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 in den Ergebnissen null angezeigt wird, führen Sie den folgenden Befehl aus, um die Identitätsförderung von Arbeitslasten für 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 die Identitätsföderation von Arbeitslasten für 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 der Identitätsföderation von Arbeitslasten für GKE konfigurieren

Gehen Sie so vor, um die Identitätsföderation von Arbeitslasten für GKE 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, die 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 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 ist der Name des Google-Dienstkontos (GSA) für Cassandra. Weitere Informationen finden Sie unter Informationen zu Dienstkonten.
  • PROJECT_ID wird durch Ihre Google Cloud-Projekt-ID ersetzt.
  • APIGEE_NAMESPACE wird durch Ihren Apigee-Namespace ersetzt, standardmäßig apigee.
  • apigee-cassandra-default ist der Name des Kubernetes-Dienstkontos für die Cassandra-Pods, die vom apigee-datastore-Diagramm erstellt wurden.
  1. Rufen Sie den Befehl zum Einrichten der Identitätsföderation von Arbeitslasten für GKE für apigee-datastore ab und führen Sie ihn 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 der Identitätsföderation von Arbeitslasten für 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 der Identitätsföderation von Arbeitslasten für 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 der Identitätsföderation von Arbeitslasten für 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.

Identitätsföderation von Arbeitslasten 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. Prüfen Sie die Logs: 
    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