Schritt 11 (optional): Workload Identity konfigurieren

Apigee Hybrid v.1.13 unterstützt Workload Identity in GKE und die Workload Identity-Föderation in AKS und EKS. In diesem Leitfaden wird nur die Konfiguration von Workload Identity in GKE behandelt. Für AKS und EKS folgen Sie der Anleitung unter Identitätsföderation von Arbeitslasten auf AKS und EKS aktivieren.

Workload Identity in GKE konfigurieren

Google Cloud-Dienstkonten und Kubernetes-Dienstkonten

Ein Google Cloud-Dienstkonto ist eine spezielle Art von Konto, mit dem autorisierte API-Aufrufe durch Authentifizierung als Dienstkonto selbst ausgeführt werden können. Google Cloud-Dienstkonten können Rollen und Berechtigungen erhalten, die einem einzelnen Nutzer ähneln. Wenn sich eine Anwendung als Dienstkonto authentifiziert, hat sie Zugriff auf alle Ressourcen, auf die das Dienstkonto Zugriff hat. Weitere Informationen zu Google Cloud-Dienstkonten finden Sie in der Übersicht zu Dienstkonten.

Sie haben Google Cloud-Dienstkonten für Ihre Apigee Hybrid-Installation in Schritt 4: Dienstkonten erstellen erstellt. Apigee verwendet diese Dienstkonten zur Authentifizierung der Hybridkomponenten.

Kubernetes-Dienstkonten sind Google Cloud-Dienstkonten ähnlich. Ein Kubernetes-Dienstkonto bietet eine Identität für Prozesse, die in einem Pod ausgeführt werden, und ermöglicht ihnen, sich ähnlich wie ein Nutzer beim API-Server zu authentifizieren. Weitere Informationen zu Kubernetes-Dienstkonten finden Sie unter Dienstkonten für Pods konfigurieren.

Wenn in der Überschreibungsdatei gcp.workloadIdentity.enabled auf true gesetzt ist, erstellen Helm-Diagramme für jede Hybridkomponente die Kubernetes-Dienstkonten für die Komponenten, sofern Sie diese wie in Schritt 11: Apigee Hybrid mit Helm-Diagrammen installieren beschrieben installieren oder aktualisieren.

Wenn Sie Workload Identity in GKE konfigurieren, verknüpfen Sie die Google Cloud-Dienstkonten mit den Kubernetes-Dienstkonten im Kubernetes-Cluster. Auf diese Weise können die Kubernetes-Dienstkonten die Identität der Google Cloud-Dienstkonten übernehmen und die ihnen zugewiesenen Rollen und Berechtigungen für die Authentifizierung bei den Hybridkomponenten verwenden.

Folgen Sie dieser Anleitung, um Workload Identity für Ihr Projekt zu konfigurieren.

Konfiguration von Workload Identity vorbereiten

  1. Prüfen Sie, ob Workload Identity in Ihrer Überschreibungsdatei aktiviert ist. Es sollte in der Überschreibungsdatei in den folgenden Attributen aktiviert sein.
    • Das Feld „namespace“ darf nicht leer sein. Beispiel: 
      instanceID: "hybrid-instance-1"
namespace: "apigee"
    • Wenn Sie ein einzelnes Dienstkonto (Non-Prod) für alle Komponenten verwenden, geben Sie es mit gcp.workloadIdentity.gsa an. Beispiel: 
        gcp:
    workloadIdentity:
      enabled: true
      gsa: "apigee-non-prod@my-hybrid-project.iam.gserviceaccount.com"
    • Wenn Sie für jede Komponente ein separates Dienstkonto verwenden (Prod-Installationen), geben Sie das Dienstkonto mit dem Attribut gsa der Komponente an. Beispiel: 
        logger:
    gsa: "apigee-logger@my-hybrid-project.iam.gserviceaccount.com"

    Siehe: gcp.workloadIdentity.enabled.

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

  4. 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.

  5. 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 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
 
NAME: datastore
  ...
For C* 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  \
        --role roles/iam.workloadIdentityUser \
        --member "serviceAccount:my-project.svc.id.goog[apigee/apigee-cassandra-backup-sa]" \
        --project :my-project
  1. 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
  2. Rufen Sie die Befehle zum Einrichten von Workload Identity für apigee-telemetry ab und führen Sie und führen Sie den Befehl unter NOTES: in der Ausgabe aus. 
    helm upgrade telemetry apigee-telemetry/ \
  --namespace $NAMESPACE \
  -f overrides.yaml \
  --dry-run
  3. Rufen Sie die Befehle zum Einrichten von Workload Identity für apigee-org ab und führen Sie und führen Sie den Befehl unter NOTES: in der Ausgabe aus. 
    helm upgrade $ORG_NAME apigee-org/ \
  --namespace $NAMESPACE \
  -f overrides.yaml \
  --dry-run
  4. Rufen Sie die Befehle zum Einrichten von Workload Identity für apigee-env ab und führen Sie den Befehl unter NOTES: 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.

  5. (Optional) Sie können den Status Ihrer Kubernetes-Dienstkonten in der Google Cloud Console auf der Seite Kubernetes: Arbeitslasten – Übersicht sehen.

    Zu Arbeitslasten

Nächste Schritte

Im nächsten Schritt konfigurieren Sie das Apigee Ingress-Gateway und stellen einen Proxy zum Testen der Installation bereit.

Nächster Schritt

(WEITER) Schritt 1: Apigee-Ingress verfügbar machen 2