אימות ל-Google Cloud APIs מעומסי עבודה ב-GKE

בדף הזה מוסבר איך להשתמש באיחוד זהויות של עומסי עבודה ל-GKE כדי לגשת בצורה מאובטחת יותר לממשקי ה-API של Google Cloud מעומסי העבודה שפועלים באשכולות של Google Kubernetes Engine ‏ (GKE).

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

לפני שקוראים את הדף הזה, חשוב להכיר את המושגים של איחוד זהויות של עומסי עבודה ל-GKE.

לפני שמתחילים

לפני שמתחילים, חשוב לוודא שביצעתם את המשימות הבאות:

  • מפעילים את ממשק ה-API של Google Kubernetes Engine.
    • הפעלת Google Kubernetes Engine API
  • כדי להשתמש ב-Google Cloud CLI למשימה הזו, מתקינים ואז מאתחלים את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.

הפעלת איחוד זהויות של עומסי עבודה ל-GKE באשכולות ובמאגרי צמתים

ב-Autopilot, איחוד זהויות של עומסי עבודה ל-GKE תמיד מופעל. דלגו לקטע הגדרת אפליקציות לשימוש באיחוד זהויות של עומסי עבודה ל-GKE.

ב-Standard, מפעילים את איחוד שירותי אימות הזהות של עומסי עבודה ב-GKE באשכולות ובמאגרי צמתים באמצעות Google Cloud CLI או Google Cloud המסוף. חובה להפעיל איחוד זהויות של עומסי עבודה ל-GKE ברמת האשכול לפני שמפעילים איחוד זהויות של עומסי עבודה ל-GKE במאגרי צמתים.

כדי להפעיל את איחוד הזהויות של עומסי עבודה ל-GKE באשכול Standard קיים, אפשר להשתמש ב-CLI של gcloud או במסוף Google Cloud . מאגרי צמתים קיימים לא מושפעים, אבל כל מאגר צמתים חדש באשכול משתמש באיחוד זהויות של עומסי עבודה ל-GKE.

gcloud

  1. במסוף Google Cloud , מפעילים את Cloud Shell.

    הפעלת Cloud Shell

    בחלק התחתון של Google Cloud המסוף יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.

  2. כדי להפעיל איחוד זהויות של עומסי עבודה ל-GKE באשכול קיים, מריצים את הפקודה הבאה:

    gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --workload-pool=PROJECT_ID.svc.id.goog

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫CLUSTER_NAME: השם של האשכול הקיים.
    • ‫LOCATION: האזור או התחום של מישור הבקרה של האשכול ב-Compute Engine, למשל us-central1 או us-central1-a.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .

המסוף

כדי להפעיל איחוד זהויות של עומסי עבודה ל-GKE באשכול קיים:

  1. נכנסים לדף Google Kubernetes Engine במסוף Google Cloud .

    מעבר אל Google Kubernetes Engine

  2. ברשימת האשכולות, לוחצים על שם האשכול שרוצים לשנות.

  3. בדף הפרטים של האשכול, בקטע אבטחה, לוחצים על עריכת Workload Identity.

  4. בתיבת הדו-שיח Edit Workload Identity, מסמנים את התיבה Enable Workload Identity.

  5. לוחצים על שמירת השינויים.

העברת עומסי עבודה קיימים ל-Workload Identity Federation ל-GKE

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

אפשר להפעיל איחוד זהויות של עומסי עבודה ל-GKE במאגר צמתים רק אם איחוד זהויות של עומסי עבודה ל-GKE מופעל באשכול.

שיטה מומלצת:

צריך ליצור מאגרי צמתים חדשים אם אתם צריכים גם לשנות את האפליקציות כך שיהיו תואמות לאיחוד זהויות של עומסי עבודה ל-GKE.

כל מאגרי הצמתים החדשים שיוצרים מוגדרים כברירת מחדל לשימוש ב-איחוד זהויות של עומסי עבודה ל-GKE אם האפשרות הזו מופעלת באשכול. כדי ליצור מאגר צמתים חדש עם איחוד זהויות של עומסי עבודה ל-GKE, מריצים את הפקודה הבאה:

gcloud container node-pools create NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --workload-metadata=GKE_METADATA

מחליפים את מה שכתוב בשדות הבאים:

  • ‫NODEPOOL_NAME: השם של מאגר הצמתים החדש.
  • ‫CLUSTER_NAME: השם של האשכול הקיים שמופעל בו איחוד זהויות של עומסי עבודה ל-GKE.
  • ‫CONTROL_PLANE_LOCATION: האזור או התחום של מישור הבקרה של האשכול ב-Compute Engine, למשל us-central1 או us-central1-a.

הדגל --workload-metadata=GKE_METADATA מגדיר את מאגר הצמתים לשימוש בשרת המטא-נתונים של GKE.

שיטה מומלצת:

צריך לכלול את הדגל כדי שיצירת מאגר הצמתים תיכשל אם איחוד הזהויות של עומסי עבודה ל-GKE לא מופעל באשכול.

עדכון של מאגר צמתים קיים

אחרי שמפעילים את איחוד זהויות של עומסי עבודה ל-GKE באשכול, אפשר להפעיל אותו ידנית במאגרי צמתים קיימים.

gcloud

  1. מפעילים את Cloud Shell במסוף Google Cloud .

    הפעלת Cloud Shell

    בחלק התחתון של Google Cloud המסוף יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.

  2. כדי לשנות מאגר צמתים קיים כך שישתמש באיחוד זהויות של עומסי עבודה ל-GKE, מריצים את הפקודה הבאה:

    gcloud container node-pools update NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --workload-metadata=GKE_METADATA

    אם באשכול מופעל איחוד זהויות של עומסי עבודה ל-GKE, אפשר להשבית אותו באופן סלקטיבי במאגר צמתים ספציפי על ידי ציון מפורש של --workload-metadata=GCE_METADATA.

המסוף

כדי לשנות מאגר צמתים קיים כך שישתמש באיחוד זהויות של עומסי עבודה ל-GKE, מבצעים את השלבים הבאים:

  1. נכנסים לדף Google Kubernetes Engine במסוף Google Cloud .

    כניסה ל-Google Kubernetes Engine

  2. ברשימת האשכולות, לוחצים על שם האשכול שרוצים לשנות.

  3. לוחצים על הכרטיסייה Nodes (צמתים).

  4. בקטע Node Pools (מאגרי צמתים), לוחצים על השם של מאגר הצמתים שרוצים לשנות.

  5. בדף פרטי מאגר הצמתים, לוחצים על עריכה.

  6. בדף Edit node pool, בקטע Security, מסמנים את התיבה Enable GKE Metadata Server.

  7. לוחצים על Save.

הגדרת אפליקציות לשימוש באיחוד זהויות של עומסי עבודה ל-GKE

כדי לאפשר לאפליקציות GKE לבצע אימות ל- Google CloudAPIs באמצעות איחוד זהויות של עומסי עבודה ב-GKE, צריך ליצור כללי מדיניות של IAM עבור ה-APIs הספציפיים. חשבון המשתמש במדיניות הזו הוא מזהה חשבון משתמש ב-IAM שתואם לעומסי העבודה, למרחבי השמות או לחשבונות השירות של Kubernetes. התהליך הזה מחזיר אסימון גישה מאוחד שעומס העבודה יכול להשתמש בו בקריאות ל-API.

לחלופין, אתם יכולים להגדיר את Kubernetes ServiceAccounts להתחזות לחשבונות שירות של IAM, וכך להגדיר את GKE להחליף את אסימון הגישה המאומת באסימון גישה מ-IAM Service Account Credentials API. פרטים נוספים זמינים בקטע אפשרות חלופית: קישור חשבונות שירות של Kubernetes ל-IAM.

הגדרת הרשאות וחשבונות משתמשים

  1. מקבלים פרטי כניסה לאשכול:

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫CLUSTER_NAME: השם של האשכול שבו מופעל איחוד זהויות של עומסי עבודה ל-GKE.
    • ‫CONTROL_PLANE_LOCATION: האזור או התחום של מישור הבקרה של האשכול ב-Compute Engine, למשל us-central1 או us-central1-a.

  2. יוצרים מרחב שמות לשימוש בחשבון השירות של Kubernetes. אפשר גם להשתמש במרחב השמות default או בכל מרחב שמות קיים.

    kubectl create namespace NAMESPACE

  3. יוצרים Kubernetes ServiceAccount לשימוש באפליקציה. אפשר גם להשתמש בכל חשבון שירות קיים ב-Kubernetes בכל מרחב שמות. אם לא תקצו ServiceAccount לעומס העבודה, Kubernetes יקצה את ה-ServiceAccount שנקרא default במרחב השמות.

    kubectl create serviceaccount KSA_NAME \
    --namespace NAMESPACE

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫KSA_NAME: השם של חשבון השירות החדש של Kubernetes.
    • ‫NAMESPACE: השם של מרחב השמות ב-Kubernetes עבור חשבון השירות.

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

    לדוגמה, הפקודה הבאה מקצה את התפקיד Kubernetes Engine Cluster Viewer ‏(roles/container.clusterViewer) לחשבון השירות שיצרתם:

    gcloud projects add-iam-policy-binding projects/PROJECT_ID \
    --role=roles/container.clusterViewer \
    --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME \
    --condition=None

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫PROJECT_NUMBER: מספר הפרויקט Google Cloud.

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

אופציונלי: הגדרת אפשרויות של רשת שירותים

אם אתם משתמשים ב-Istio או ב-Cloud Service Mesh כדי לנהל את הסביבה, מוסיפים את ההערה הבאה לשדה metadata.annotations במפרט ה-Pod:

metadata:
  annotations:
    proxy.istio.io/config: '{ "holdApplicationUntilProxyStarts": true }'

האנוטציה הזו מונעת מהקונטיינרים להתחיל עד שהפרוקסי של Service mesh מוכן להפנות תעבורת נתונים מהאפליקציות שלכם.

אימות ההגדרה של איחוד זהויות של עומסי עבודה ל-GKE

בקטע הזה יוצרים קטגוריה של Cloud Storage ומעניקים לחשבון השירות של Kubernetes שנוצר בקטע הקודם גישת צפייה בקטגוריה. לאחר מכן פורסים את עומס העבודה ובודקים שהקונטיינר יכול להציג רשימה של אשכולות בפרויקט.

  1. יוצרים קטגוריה ריקה של Cloud Storage:

    gcloud storage buckets create gs://BUCKET

    מחליפים את BUCKET בשם של הקטגוריה החדשה.

  2. מקצים את התפקיד צפייה באובייקטים באחסון (roles/storage.objectViewer) לחשבון השירות שיצרתם:

    gcloud storage buckets add-iam-policy-binding gs://BUCKET \
    --role=roles/storage.objectViewer \
    --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME \
    --condition=None

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫PROJECT_NUMBER: מספר הפרויקט ב- Google Cloud.
    • ‫NAMESPACE: מרחב השמות של Kubernetes שמכיל את ServiceAccount.
    • ‫KSA_NAME: השם של ServiceAccount.

  3. שומרים את קובץ המניפסט הבא בשם test-app.yaml:

    apiVersion: v1
kind: Pod
metadata:
  name: test-pod
  namespace: NAMESPACE
spec:
  serviceAccountName: KSA_NAME
  containers:
  - name: test-pod
    image: google/cloud-sdk:slim
    command: ["sleep","infinity"]
    resources:
      requests:
        cpu: 500m
        memory: 512Mi
        ephemeral-storage: 10Mi

  4. באשכולות Standard בלבד, מוסיפים את השורה הבאה לשדה template.spec כדי למקם את ה-Pods במאגרי צמתים שמשתמשים באיחוד זהויות של עומסי עבודה ל-GKE.

    באשכולות Autopilot, אפשר לדלג על השלב הזה כי כל צומת משתמש באיחוד זהויות של עומסי עבודה ל-GKE, ולכן האשכול דוחה את nodeSelector הזה.

    spec:
  nodeSelector:
    iam.gke.io/gke-metadata-server-enabled: "true"

  5. מחילים את ההגדרה על האשכול:

    kubectl apply -f test-app.yaml

  6. מחכים שה-Pod יהיה מוכן. כדי לבדוק את הסטטוס של ה-Pod, מריצים את הפקודה הבאה:

    kubectl get pods --namespace=NAMESPACE

    כשה-Pod מוכן, הפלט אמור להיראות כך:

    NAME       READY   STATUS    RESTARTS   AGE
test-pod   1/1     Running   0          5m27s

  7. פותחים סשן של מעטפת ב-Pod:

    kubectl exec -it pods/test-pod --namespace=NAMESPACE -- /bin/bash

  8. כדי לקבל רשימה של אובייקטים בקטגוריה:

    curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    "https://storage.googleapis.com/storage/v1/b/BUCKET/o"

    הפלט שיתקבל:

    {
  "kind": "storage#objects"
}

    הפלט הזה מראה של-Pod יש גישה לאובייקטים בקטגוריה.

אפשרות חלופית: קישור של חשבונות שירות ב-Kubernetes ל-IAM

שיטה מומלצת:

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

  1. יוצרים מרחב שמות של Kubernetes:

    kubectl create namespace NAMESPACE

  2. יוצרים חשבון שירות ב-Kubernetes:

    kubectl create serviceaccount KSA_NAME \
    --namespace=NAMESPACE

  3. יוצרים חשבון שירות ב-IAM. אפשר גם להשתמש בכל חשבון שירות קיים של IAM בכל פרויקט בארגון.

    gcloud iam service-accounts create IAM_SA_NAME \
    --project=IAM_SA_PROJECT_ID

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫IAM_SA_NAME: שם לחשבון השירות החדש ב-IAM.
    • ‫IAM_SA_PROJECT_ID: מזהה הפרויקט של חשבון השירות שלכם ב-IAM.

    מידע על מתן הרשאה לחשבונות שירות ב-IAM לגשת לממשקי Google Cloud API זמין במאמר הסבר על חשבונות שירות.

  4. מקצים לחשבון השירות ב-IAM את התפקידים שהוא צריך בממשקי API ספציפיים Google Cloud :

    gcloud projects add-iam-policy-binding IAM_SA_PROJECT_ID \
    --member "serviceAccount:IAM_SA_NAME@IAM_SA_PROJECT_ID.iam.gserviceaccount.com" \
    --role "ROLE_NAME"

    מחליפים את ROLE_NAME בשם התפקיד, למשל roles/spanner.viewer.

  5. יוצרים מדיניות הרשאות ב-IAM שנותנת לחשבון השירות של Kubernetes גישה להתחזות לחשבון השירות של IAM:

    gcloud iam service-accounts add-iam-policy-binding IAM_SA_NAME@IAM_SA_PROJECT_ID.iam.gserviceaccount.com \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]"

    שם החבר חייב לכלול את מרחב השמות ואת שם חשבון השירות של Kubernetes. לדוגמה, serviceAccount:example-project.svc.id.goog[example-namespace/example-serviceaccount].

  6. מוסיפים הערה ל-ServiceAccount ב-Kubernetes כדי ש-GKE יראה את הקישור בין חשבונות השירות:

    kubectl annotate serviceaccount KSA_NAME \
    --namespace NAMESPACE \
    iam.gke.io/gcp-service-account=IAM_SA_NAME@IAM_SA_PROJECT_ID.iam.gserviceaccount.com

    כשמשתמשים בשיטה הזו, צריך גם את מדיניות ההרשאות של IAM וגם את ההערה.

  7. אופציונלי: מוסיפים הערה ל-ServiceAccount של Kubernetes כדי שהאפליקציות יקבלו את המזהה בתחביר של מזהה חשבון המשתמש ב-IAM:

    kubectl annotate serviceaccount KSA_NAME \
    --namespace=NAMESPACE \
    iam.gke.io/return-principal-id-as-email="true"

שימוש באיחוד זהויות של עומסי עבודה ל-GKE מהקוד

התהליך של אימות לשירותי Google Cloud מהקוד שלכם זהה לתהליך של אימות באמצעות שרת המטא-נתונים של Compute Engine. כשמשתמשים באיחוד זהויות של עומסי עבודה ל-GKE, הבקשות לשרת המטא-נתונים של המכונה מנותבות לשרת המטא-נתונים של GKE. קוד קיים שמבצע אימות באמצעות שרת המטא-נתונים של המופע (למשל קוד שמשתמש בספריות הלקוח שלGoogle Cloud ) אמור לפעול בלי שינויים.

שימוש במכסה מפרויקט אחר עם איחוד זהויות של עומסי עבודה ל-GKE

באשכולות שמופעלת בהם גרסה 1.24 של GKE ואילך, אתם יכולים להגדיר את חשבון השירות של Kubernetes כך שישתמש במכסת פרויקט אחר Google Cloud כשמתבצעות קריאות לשיטות GenerateAccessToken ו-GenerateIdToken ב-IAM Service Account Credentials API. כך תוכלו להימנע משימוש במכסת השימוש כולה בפרויקט הראשי, ובמקום זאת להשתמש במכסת שימוש מפרויקטים אחרים בשירותים האלה באשכול.

כדי להגדיר פרויקט לחיוב על מכסות באמצעות איחוד זהויות של עומסי עבודה ל-GKE:

  1. מקצים לחשבון השירות של Kubernetes את ההרשאה serviceusage.services.use בפרויקט להקצאת המכסות.

    gcloud projects add-iam-policy-binding QUOTA_PROJECT_ID \
    --role=roles/serviceusage.serviceUsageConsumer \
    --member='principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME' \

    מחליפים את QUOTA_PROJECT_ID במזהה הפרויקט לצורכי מכסה.

  2. מוסיפים הערה לחשבון השירות של Kubernetes עם פרויקט המכסה:

    kubectl annotate serviceaccount KSA_NAME \
    --namespace NAMESPACE \
    iam.gke.io/credential-quota-project=QUOTA_PROJECT_ID

כדי לוודא שההגדרה פועלת בצורה תקינה:

  1. יוצרים Pod ומתחילים סשן מעטפת. מידע נוסף זמין במסמכי התיעוד של Kubernetes בנושא קבלת מעטפת לקונטיינר שפועל.

  2. שולחים בקשה לשרת המטא-נתונים:

    curl -H "Metadata-Flavor: Google" http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token

  3. נכנסים לדף IAM Service Accounts Credentials API במסוף Google Cloud בפרויקט המכסה:

    לדף APIs

  4. בודקים אם יש שינויים בתנועה.

הסרת המשאבים

כדי להפסיק להשתמש באיחוד זהויות של עומסי עבודה ל-GKE, צריך לבטל את הגישה לחשבון השירות של IAM ולהשבית את איחוד הזהויות של עומסי עבודה ל-GKE באשכול.

ביטול גישה

כדי לבטל את הגישה לחשבון המשתמש, צריך להסיר את מדיניות ההרשאה ב-IAM שיצרתם בקטע הגדרת אפליקציות לשימוש באיחוד זהויות של עומסי עבודה ל-GKE.

לדוגמה, כדי לבטל את הגישה למאגר ב-Artifact Registry, מריצים את הפקודה הבאה:

gcloud artifacts repositories remove-iam-policy-binding REPOSITORY_NAME \
    --location=REPOSITORY_LOCATION \
    --member='principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME' \
    --role='roles/artifactregistry.reader' \
    --all

השבתת איחוד זהויות של עומסי עבודה ל-GKE

אפשר להשבית את איחוד הזהויות של עומסי עבודה ל-GKE רק באשכולות Standard.

gcloud

  1. במסוף Google Cloud , מפעילים את Cloud Shell.

    הפעלת Cloud Shell

    בחלק התחתון של מסוף Google Cloud יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.

  2. משביתים את איחוד הזהויות של עומסי עבודה ל-GKE בכל מאגר צמתים:

    gcloud container node-pools update NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --workload-metadata=GCE_METADATA

    חוזרים על הפקודה הזו לכל מאגר צמתים באשכול.

  3. משביתים את איחוד הזהויות של עומסי עבודה ל-GKE באשכול:

    gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --disable-workload-identity

המסוף

  1. נכנסים לדף Google Kubernetes Engine במסוף Google Cloud .

    מעבר אל Google Kubernetes Engine

  2. ברשימת האשכולות, לוחצים על שם האשכול שרוצים לשנות.

  3. לוחצים על הכרטיסייה Nodes (צמתים).

  4. כדי להשבית את איחוד הזהויות של עומסי עבודה ל-GKE בכל מאגר צמתים, מבצעים את הפעולות הבאות לכל מאגר צמתים בקטע Node Pools:

    1. לוחצים על השם של מאגר הצמתים שרוצים לשנות.
    2. בדף פרטים של מאגר הצמתים, לוחצים על עריכה.
    3. בדף Edit node pool, בקטע Security, מבטלים את הסימון בתיבה Enable GKE Metadata Server.
    4. לוחצים על Save.

  5. כדי להשבית את איחוד הזהויות של עומסי עבודה ל-GKE באשכול, מבצעים את הפעולות הבאות:

    1. לוחצים על הכרטיסייה פרטים.
    2. בקטע Security, ליד Workload Identity, לוחצים על Edit.
    3. בתיבת הדו-שיח Edit Workload Identity, מבטלים את הסימון בתיבה Enable Workload Identity.
    4. לוחצים על שמירת השינויים.

השבתה של איחוד זהויות של עומסי עבודה ל-GKE בארגון

השלבים בקטע קישור חשבונות שירות של Kubernetes ל-IAM מאפשרים לחשבונות שירות של Kubernetes להתחזות לזהות של חשבון השירות המקושר ב-IAM. אפשר להחליף אסימוני API לטווח ארוך של חשבונות שירות ב-Kubernetes בטוקני גישה לחשבון שירות התואמים ב-IAM.

יכול להיות שתרצו להשבית את איחוד שירותי אימות הזהות של עומסי עבודה ב-GKE עבור אשכולות בארגון, בתיקייה או בפרויקט, אם אתם רוצים לבודד עומסי עבודה מחשבונות שירות של IAM. לדוגמה, אם אתם מתכננים להשבית את יצירת חשבונות השירות או להשבית את יצירת המפתחות של חשבונות השירות, השבתת איחוד זהויות של עומסי עבודה ל-GKE תמנע את ההמרה של אסימוני ServiceAccount לטוקני גישה לחשבונות שירות של IAM.

מידע נוסף זמין במאמר השבתת יצירת אשכולות של Workload Identity.

פתרון בעיות

למידע על פתרון בעיות, עיינו במאמר פתרון בעיות באיחוד זהויות של עומסי עבודה ל-GKE.

המאמרים הבאים