שלב 11 (אופציונלי): הגדרת Workload Identity

‫Apigee hybrid v.1.14 תומך ב-Workload Identity ב-GKE ובאיחוד זהויות של עומסי עבודה (WIF) ב-AKS וב-EKS. ההליכים במדריך הזה מתייחסים רק להגדרת Workload Identity ב-GKE. ב-AKS וב-EKS, פועלים לפי ההוראות במאמר הפעלת איחוד שירותי אימות הזהות של עומסי עבודה ב-AKS וב-EKS.

הגדרת Workload Identity ב-GKE

חשבונות שירות ב-Google Cloud וחשבונות שירות ב-Kubernetes

חשבון שירות ב-Google Cloud הוא סוג מיוחד של חשבון שאפשר להשתמש בו כדי לבצע קריאות מורשות ל-API על ידי אימות כחשבון השירות עצמו. אפשר לתת לחשבונות שירות ב-Google Cloud תפקידים והרשאות כמו למשתמשים פרטיים. כשאפליקציה מבצעת אימות כחשבון שירות, יש לה גישה לכל המשאבים שחשבון השירות מורשה לגשת אליהם. מידע נוסף על חשבונות שירות ב-Google Cloud זמין במאמר סקירה כללית על חשבונות שירות.

יצרתם חשבונות שירות ב-Google Cloud להתקנה של Apigee Hybrid בשלב 4: יצירת חשבונות שירות. ‫Apigee משתמש בחשבונות השירות האלה כדי לאמת את הרכיבים ההיברידיים.

חשבונות שירות של Kubernetes דומים לחשבונות שירות של Google Cloud. חשבון שירות של Kubernetes מספק זהות לתהליכים שפועלים ב-Pod, ומאפשר לו לבצע אימות לשרת ה-API באופן דומה למשתמש. למידע נוסף על חשבונות שירות של Kubernetes, קראו את המאמר הגדרת חשבונות שירות לפודים.

אם הגדרתם את gcp.workloadIdentity.enabled לערך true בקובץ ההגדרות שלכם, כשתרשימי Helm לכל רכיב היברידי ייצרו את חשבונות השירות של Kubernetes עבור הרכיבים, כשתתקינו או תשדרגו אותם כמו שעשיתם בשלב 10: התקנת Apigee Hybrid באמצעות Helm.

כשמגדירים Workload Identity ב-GKE, משייכים את חשבונות השירות של Google Cloud לחשבונות השירות של Kubernetes באשכול Kubernetes. כך, חשבונות השירות של Kubernetes יכולים להתחזות לחשבונות השירות של Google Cloud ולהשתמש בתפקידים ובהרשאות שהוקצו להם כדי לבצע אימות מול הרכיבים ההיברידיים.

כדי להגדיר את Workload Identity בפרויקט, פועלים לפי ההוראות שכאן.

הכנות להגדרת Workload Identity

  1. מוודאים שהתכונה Workload Identity מופעלת בקובץ ההחלפות. צריך להפעיל אותו בקובץ ההגדרות החלופיות במאפיינים הבאים.
    • השדה namespace הוא שדה חובה. לדוגמה: 
      instanceID: "hybrid-instance-1"
namespace: "apigee"
    • אם אתם משתמשים בחשבון שירות יחיד (לא בסביבת ייצור) לכל הרכיבים, מציינים אותו באמצעות: gcp.workloadIdentity.gsa. לדוגמה: 
        gcp:
    workloadIdentity:
      enabled: true
      gsa: "apigee-non-prod@my-hybrid-project.iam.gserviceaccount.com"
    • אם אתם משתמשים בחשבון שירות נפרד לכל רכיב (התקנות Prod), צריך לציין את חשבון השירות באמצעות המאפיין gsa של הרכיב. לדוגמה: 
        logger:
    gsa: "apigee-logger@my-hybrid-project.iam.gserviceaccount.com"

    מידע נוסף: gcp.workloadIdentity.enabled

  2. מריצים את הפקודה הבאה כדי לוודא שההגדרה הנוכחית של gcloud היא מזהה הפרויקט בענן ב-Google Cloud: 
    gcloud config get project

    3. אם צריך, מגדירים את ההגדרות הנוכחיות של gcloud:

    gcloud config set project $PROJECT_ID
  3. מוודאים ש-Workload Identity מופעל באשכול GKE. כשיוצרים את האשכול בשלב 1: יצירת אשכול, שלב 6 הוא להפעיל את Workload Identity. כדי לוודא ש-Workload Identity מופעל, מריצים את הפקודה הבאה:

    אשכולות אזוריים

    gcloud container clusters describe $CLUSTER_NAME \
  --region $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --flatten 'workloadIdentityConfig'

    אשכולות אזוריים

    gcloud container clusters describe $CLUSTER_NAME \
  --zone $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --flatten 'workloadIdentityConfig'

    הפלט אמור להיראות כך: 

      ---
  workloadPool: PROJECT_ID.svc.id.goog

    אם במקום זאת רואים null בתוצאות, מריצים את הפקודה הבאה כדי להפעיל את Workload Identity באשכול:

    אשכולות אזוריים

    gcloud container clusters update $CLUSTER_NAME \
  --workload-pool=$PROJECT_ID.svc.id.goog \
  --project $PROJECT_ID \
  --region $CLUSTER_LOCATION

    אשכולות של תחום מוגדר

    gcloud container clusters update  $CLUSTER_NAME \
  --workload-pool=$PROJECT_ID.svc.id.goog \
  --zone $CLUSTER_LOCATION \
  --project $PROJECT_ID

  4. מפעילים את התכונה Workload Identity לכל מאגר צמתים באמצעות הפקודות הבאות. הפעולה הזו יכולה להימשך עד 30 דקות לכל מאגר צמתים:

    אשכולות אזוריים

    gcloud container node-pools update NODE_POOL_NAME \
  --cluster=$CLUSTER_NAME \
  --region $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --workload-metadata=GKE_METADATA

    אשכולות של תחום מוגדר

    gcloud container node-pools update NODE_POOL_NAME \
  --cluster=$CLUSTER_NAME \
  --zone $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --workload-metadata=GKE_METADATA

    כאשר NODE_POOL_NAME הוא השם של כל מאגר צמתים. ברוב ההתקנות של Apigee hybrid, שני מאגרי הצמתים שמוגדרים כברירת מחדל נקראים apigee-data ו-apigee-runtime.

  5. כדי לוודא שהתכונה Workload Identity מופעלת במאגרי הצמתים, מריצים את הפקודות הבאות:

    אשכולות אזוריים

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

    אשכולות אזוריים

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

    הפלט אמור להיראות כך:

    ---
diskSizeGb: 100
diskType: pd-standard
...
workloadMetadataConfig:
  mode: GKE_METADATA

הגדרת Workload Identity

כדי להפעיל את Workload Identity לרכיבים ההיברידיים הבאים, פועלים לפי השלבים הבאים:

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

כשמריצים את הפקודה helm upgrade עם הדגל --dry-run עבור התרשימים apigee-datastore, apigee-env, apigee-org ו-apigee-telemetry, הפלט יכלול את הפקודות שצריך להריץ כדי להגדיר את Workload Identity עם השמות הנכונים של GSA ו-KSA.

לדוגמה:

helm upgrade datastore apigee-datastore/ \
  --namespace APIGEE_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-service-account@my-project.iam.gserviceaccount.com \
      --role roles/iam.workloadIdentityUser \
      --member "serviceAccount:my-project.svc.id.goog[apigee/apigee-cassandra-default]" \
      --project my-project

kubectl annotate serviceaccount apigee-cassandra-default \
      iam.gke.io/gcp-service-account=my-service-account@my-project.iam.gserviceaccount.com \
      --namespace apigee
  1. מקבלים את הפקודה להגדרת Workload Identity עבור apigee-datastore ומריצים את הפקודה בקטע NOTES: בפלט. 
    helm upgrade datastore apigee-datastore/ \
  --namespace APIGEE_NAMESPACE \
  -f overrides.yaml \
  --dry-run=server
  2. משיגים את הפקודות להגדרת Workload Identity עבור apigee-telemetry ומריצים את הפקודה בקטע NOTES: בפלט. 
    helm upgrade telemetry apigee-telemetry/ \
  --namespace APIGEE_NAMESPACE \
  -f overrides.yaml \
  --dry-run=server
  3. מקבלים את הפקודות להגדרת Workload Identity עבור apigee-org ומריצים את הפקודה שמופיעה בקטע NOTES: בפלט. 
    helm upgrade $ORG_NAME apigee-org/ \
  --namespace APIGEE_NAMESPACE \
  -f overrides.yaml \
  --dry-run=server
  4. משיגים את הפקודות להגדרת Workload Identity ל-apigee-env ומריצים את הפקודה בקטע NOTES: בפלט. 
    helm upgrade $ENV_NAME apigee-env/ \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f overrides.yaml \
  --dry-run=server

    חוזרים על השלב הזה לכל סביבה בהתקנה.

  5. (אופציונלי) אפשר לראות את הסטטוס של חשבונות השירות של Kubernetes בדף Kubernetes: Workloads Overview ב- Google Cloud console.

    כניסה לדף Workloads

השלבים הבאים

בשלב הבא תגדירו את שער הכניסה של Apigee ותפרסו שרת proxy כדי לבדוק את ההתקנה.

השלב הבא

(הבא) שלב 1: חשיפת ה-Ingress של Apigee 2