פתרון בעיות באימות ב-GKE

בעיות באימות ב-Google Kubernetes Engine ‏ (GKE) יכולות למנוע מבעלי הרשאות, כמו משתמשים ועומסי עבודה, לגשת לשרת ה-API של Kubernetes, או להפריע לגישה בין משאבי GKE לבין שירותים אחרים של Google Cloud .

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

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

RBAC ו-IAM

חשבונות IAM מאומתים לא מצליחים לבצע פעולות בתוך האשכול

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

Error from server (Forbidden): roles.rbac.authorization.k8s.io is forbidden:
User "example-account@example-project.iam.gserviceaccount.com" cannot list resource "roles" in
API group "rbac.authorization.k8s.io" in the namespace "kube-system": requires
one of ["container.roles.list"] permission(s).

כדי לפתור את הבעיה, צריך להשתמש במדיניות RBAC כדי להעניק את ההרשאות לפעולה שניסיתם לבצע. לדוגמה, כדי לפתור את הבעיה בדוגמה הקודמת, צריך להקצות תפקיד עם ההרשאה list לאובייקטים roles במרחב השמות kube-system. הוראות מפורטות זמינות במאמר בנושא הרשאת פעולות באשכולות באמצעות בקרת גישה מבוססת-תפקידים.

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

ל-Pod אין אפשרות לאמת את Google Cloud

אם לא ניתן לאמת את האפליקציה ב- Google Cloud, צריך לוודא שההגדרות הבאות מוגדרות בצורה נכונה:

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

    gcloud container clusters describe CLUSTER_NAME \
    --format="value(workloadIdentityConfig.workloadPool)"

    מחליפים את CLUSTER_NAME בשם של אשכול GKE.

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

  2. מוודאים ששרת המטא-נתונים של GKE מוגדר במאגר הצמתים שבו האפליקציה פועלת:

    gcloud container node-pools describe NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --format="value(config.workloadMetadataConfig.mode)"

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

    • NODEPOOL_NAME בשם של מאגר הצמתים.
    • CLUSTER_NAME בשם של אשכול GKE.

  3. אם יש לכם מדיניות רשת ב-Kubernetes של אשכול, אתם צריכים לאפשר תעבורת נתונים יוצאת (egress) אל 169.254.169.252/32 ביציאה 988. באשכולות שמריצים GKE Dataplane V2, צריך לאפשר יציאה אל 169.254.169.254/32 ביציאה 80.

    kubectl describe networkpolicy NETWORK_POLICY_NAME

    מחליפים את NETWORK_POLICY_NAME בשם של מדיניות רשת ב-Kubernetes ב-GKE.

  4. אם ברשת ה-VPC שלכם מיושמים כללי יציאה שמונעים גישה כברירת מחדל או מכשירי ניתוב בהתאמה אישית, צריך לוודא שתעבורת HTTPS יוצאת מותרת לשירות האסימונים הציבורי של Google (sts.googleapis.com ביציאה 443).

    שרת המטא-נתונים של GKE פועל במרחב השמות של רשת המארח, ונדרשת לו גישה ישירה לנקודות קצה ציבוריות של Security Token Service כדי לתווך בהחלפות של אסימונים מאוחדים. אם כללי חומת האש ליציאה חוסמים את הנתיב הזה, בקשות האסימון נכשלות עם שגיאות כמו 504 Gateway Timeout או context deadline exceeded.

  5. מוודאים שמדיניות ההרשאה ב-IAM בפרויקט או במשאב היעד מעניקה את התפקיד הנדרש למזהה principal:// או principalSet:// של חשבון השירות של Kubernetes. לדוגמה, כדי לבדוק את קישורי התפקידים ברמת הפרויקט:

    gcloud projects get-iam-policy PROJECT_ID \
    --flatten="bindings[].members" \
    --filter="bindings.members:workloadIdentityPools/PROJECT_ID.svc.id.goog"

    מחליפים את PROJECT_ID במזהה הפרויקט ב- Google Cloud.

    הפלט הצפוי מכיל קשירת principal:// או principalSet:// שתואמת למספר הפרויקט, למרחב השמות ולשם חשבון השירות של Kubernetes:

    principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/SERVICEACCOUNT_NAME

אם ההגדרה שלכם מקשרת חשבונות שירות של Kubernetes לחשבונות שירות של IAM, צריך לוודא את הדברים הבאים:

  1. מוודאים שהפעלתם את IAM Service Account Credentials API בפרויקט שמכיל את אשכול GKE:

    הפעלת IAM Credentials API

  2. מוודאים שחשבון השירות של Kubernetes קיבל את ההערה הנכונה:

    kubectl describe serviceaccount \
    --namespace NAMESPACE SERVICEACCOUNT_NAME

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

    • ‫NAMESPACE עם מרחב השמות של אשכול GKE.
    • ‫SERVICEACCOUNT_NAME בשם של חשבון השירות שלכם ב-Kubernetes.

    הפלט הצפוי מכיל הערה שדומה לזו:

    iam.gke.io/gcp-service-account: GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

  3. בודקים שחשבון השירות ב-IAM מוגדר בצורה נכונה:

    gcloud iam service-accounts get-iam-policy \
    GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com

    הפלט הצפוי מכיל קישור שדומה לזה:

    - members:
  - serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/SERVICEACCOUNT_NAME]
  role: roles/iam.workloadIdentityUser

שגיאה: פורמט לא תקין של מזהה החשבון

השגיאה הבאה מתרחשת כשמנסים לבצע פעולה שנדרשת בה כתובת האימייל בחשבון שירות ב-IAM, כמו יצירה ידנית של כתובת URL חתומה ב-Cloud Storage:

ERROR: Error: Invalid form of account ID test_account.svc.id.goog. Should be [Gaia ID |Email |Unique ID |] of the account
# Multiple lines are omitted here
command terminated with exit code 137

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

כברירת מחדל, שרת המטא-נתונים של GKE מחזיר את הערך SERVICEACCOUNT_NAME.svc.id.goog כמזהה של חשבון השירות עבור חשבונות שירות מקושרים. המזהה הזה לא משתמש בתחביר של מזהה חשבון ראשי ב-IAM.

כדי לפתור את השגיאה, מוסיפים את ההערה iam.gke.io/return-principal-id-as-email="true" ל-Kubernetes ServiceAccount של ה-Pod:

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

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

  • ‫SERVICEACCOUNT_NAME: השם של חשבון השירות ב-Kubernetes.
  • ‫NAMESPACE: מרחב השמות של ServiceAccount.

הגישה לחשבון שירות ב-IAM נדחתה

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

HTTP/403: generic::permission_denied: loading: GenerateAccessToken("SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com", ""): googleapi: Error 403: Permission 'iam.serviceAccounts.getAccessToken' denied on resource (or it may not exist).

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

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

בעיות בפענוח DNS

בקטע הזה מוסבר איך לזהות ולפתור שגיאות בחיבורים מ-Pods ל-APIs Google Cloud שנגרמות מבעיות בפענוח DNS. אם השלבים בקטע הזה לא פותרים את שגיאות החיבור, כדאי לעיין בקטע שגיאות של פסק זמן בהפעלה של Pod.

חלק Google Cloud מספריות הלקוח מוגדרות להתחבר לשרתי המטא-נתונים של GKE ו-Compute Engine על ידי פתרון שם ה-DNS ‏metadata.google.internal. בספריות האלה, פתרון תקין של DNS בתוך האשכול הוא תלות קריטית כדי שעומסי העבודה יוכלו לבצע אימות לשירותיםGoogle Cloud .

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

לדוגמה, הודעת השגיאה הבאה עשויה להצביע על בעיה בפתרון DNS:

ComputeEngineCredentials cannot find the metadata server. This is likely because code is not running on Google Compute Engine

אם נתקלתם בבעיות בפענוח DNS של metadata.google.internal, אפשר להגדיר לספריות לקוח מסוימות Google Cloud לדלג על פענוח DNS על ידי הגדרת משתנה הסביבה GCE_METADATA_HOST ל-169.254.169.254:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
  namespace: default
spec:
  containers:
  - image: debian
    name: main
    command: ["sleep", "infinity"]
    env:
    - name: GCE_METADATA_HOST
      value: "169.254.169.254"

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

יש תמיכה בספריות הבאות: Google Cloud

  • Python
  • Java
  • Node.js

  • Golang

    כברירת מחדל, ספריית הלקוח של Go מתחברת באמצעות כתובת ה-IP.

שגיאות שקשורות לזמן קצוב לתפוגה בהפעלה של Pod

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

אם נתקלתם בשגיאות שקשורות לזמן קצוב לתפוגה, נסו את הפעולות הבאות:

  • מעדכנים את ספריות הלקוח Google Cloud שעומסי העבודה משתמשים בהן.
  • משנים את קוד האפליקציה כך שימתין כמה שניות וינסה שוב.

  • פריסת initContainer שממתין עד ששרת המטא-נתונים של GKE מוכן לפני הפעלת הקונטיינר הראשי של ה-Pod.

    לדוגמה, המניפסט הבא הוא של Pod עם initContainer:

    apiVersion: v1
kind: Pod
metadata:
  name: pod-with-initcontainer
spec:
  serviceAccountName: SERVICEACCOUNT_NAME
  initContainers:
  - image:  gcr.io/google.com/cloudsdktool/cloud-sdk:alpine
    name: workload-identity-initcontainer
    command:
    - '/bin/bash'
    - '-c'
    - |
      curl -sS -H 'Metadata-Flavor: Google' 'http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token' --retry 30 --retry-connrefused --retry-max-time 60 --connect-timeout 3 --fail --retry-all-errors > /dev/null && exit 0 || echo 'Retry limit exceeded. Failed to wait for metadata server to be available. Check if the gke-metadata-server Pod in the kube-system namespace is healthy.' >&2; exit 1
  containers:
  - image: gcr.io/your-project/your-image
    name: your-main-application-container

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

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

רשומה ביומן יכולה להיראות כך בכלי Logs Explorer:

dial tcp 35.232.136.58:443: connect: connection refused

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

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

אימות באמצעות איחוד זהויות של עומסי עבודה ל-GKE נכשל באשכולות שמשתמשים ב-Cloud Service Mesh או ב-OSS Istio

יכול להיות שיוצגו שגיאות דומות לאלה כשמפעילים את האפליקציה באשכולות באמצעות Cloud Service Mesh או Istio sidecars ומנסים לתקשר עם נקודת קצה:

Connection refused (169.254.169.254:80)

Connection timeout

השגיאות האלה יכולות להתרחש כשהאפליקציה מנסה ליצור חיבור לרשת לפני שהמאגר istio-proxy מוכן. כברירת מחדל, Istio ו-Cloud Service Mesh מאפשרים לעומסי עבודה לשלוח בקשות ברגע שהם מתחילים לפעול, בלי קשר לשאלה אם עומס העבודה של פרוקסי רשת השירות שמיירט את התנועה ומפנה אותה פועל. ב-Pods שמשתמשים באיחוד זהויות של עומסי עבודה ל-GKE, יכול להיות שהבקשות הראשוניות האלה שמתרחשות לפני שהפרוקסי מתחיל לפעול לא יגיעו לשרת המטא-נתונים של GKE. כתוצאה מכך, האימות לממשקי ה-API של Google Cloud נכשל. אם לא תגדירו את האפליקציות כך שינסו לשלוח את הבקשות מחדש, יכול להיות שעומסי העבודה ייכשלו.

כדי לוודא שהבעיה הזו היא הגורם לשגיאות, צריך לעיין ביומנים ולבדוק אם קונטיינר istio-proxy הופעל בהצלחה:

  1. נכנסים לדף Logs Explorer במסוף Google Cloud .

    כניסה לדף Logs Explorer

  2. בחלונית השאילתה, מזינים את השאילתה הבאה:

    (resource.type="k8s_container"
resource.labels.pod_name="POD_NAME"
textPayload:"Envoy proxy is ready" OR textPayload:"ERROR_MESSAGE")
OR
(resource.type="k8s_pod"
logName:"events"
jsonPayload.involvedObject.name="POD_NAME")

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

    • ‫POD_NAME: השם של ה-Pod עם עומס העבודה המושפע.
    • ‫ERROR_MESSAGE: השגיאה שהאפליקציה קיבלה (connection timeout או connection refused).

  3. לוחצים על Run query.

  4. בודקים את הפלט ומחפשים את השורה שבה מצוין מתי מאגר התגים istio-proxy מוכן.

    בדוגמה הבאה, האפליקציה ניסתה לבצע קריאת gRPC. עם זאת, בגלל שמאגר התגים istio-proxy עדיין היה בתהליך אתחול, האפליקציה קיבלה שגיאה Connection refused. חותמת הזמן שליד ההודעה Envoy proxy is ready מציינת מתי מאגר התגים istio-proxy היה מוכן לבקשות חיבור:

    2024-11-11T18:37:03Z started container istio-init
2024-11-11T18:37:12Z started container gcs-fetch
2024-11-11T18:37:42Z Initializing environment
2024-11-11T18:37:55Z Started container istio-proxy
2024-11-11T18:38:06Z StatusCode="Unavailable", Detail="Error starting gRPC call. HttpRequestException: Connection refused (169.254.169.254:80)
2024-11-11T18:38:13Z Envoy proxy is ready

כדי לפתור את הבעיה ולמנוע את חזרתה, אפשר להשתמש באחת מהשיטות הבאות:

  • ל-Cloud Service Mesh ול-Istio בקוד פתוח:

    • כדי למנוע ממכלי אפליקציות לשלוח בקשות עד שכוח העבודה של ה-proxy מוכן, מוסיפים את ההערה הבאה לשדה metadata.annotations במפרט ה-Pod:

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

    • כדי להגדיר את Istio או את Cloud Service Mesh כך שכתובת ה-IP של שרת המטא-נתונים של GKE לא תופנה מחדש, מוסיפים את ההערה הבאה לשדה metadata.annotations במפרט של ה-Pod:169.254.169.254/32

      traffic.sidecar.istio.io/excludeOutboundIPRanges: 169.254.169.254/32

  • ב-Istio בקוד פתוח בלבד, אפשר לצמצם את הבעיה הזו לכל ה-Pods באשכול על ידי הגדרת אחת מאפשרויות התצורה הגלובליות הבאות:

    • כדי לא לכלול את כתובת ה-IP של שרת המטא-נתונים של GKE בהפניה אוטומטית, צריך לעדכן את אפשרות ההגדרה הגלובלית global.proxy.excludeIPRanges כדי להוסיף את טווח כתובות ה-IP‏ 169.254.169.254/32.

    • כדי למנוע מאפליקציות לשלוח בקשות עד שהפרוקסי יתחיל לפעול, מוסיפים את אפשרות ההגדרה הגלובלית global.proxy.holdApplicationUntilProxyStarts עם הערך true להגדרה של Istio. האפשרות הזו לא חלה על initContainers. אם יש לכם initContainers שצריך לאמת, עדיף להשתמש באפשרות global.proxy.excludeIPRanges.

gke-metadata-server Pod is crashing

ה-Pod של DaemonSet במערכת gke-metadata-server מאפשר איחוד זהויות של עומסי עבודה ל-GKE בצמתים. ה-Pod משתמש במשאבי זיכרון באופן יחסי למספר חשבונות השירות של Kubernetes באשכול.

הבעיה הבאה מתרחשת כששימוש המשאבים של gke-metadata-server Pod חורג מהמגבלות שלו. ‫kubelet מפנה את ה-Pod עם שגיאה של אין זיכרון פנוי (OOM). יכול להיות שתיתקלו בבעיה הזו אם באשכול שלכם יש יותר מ-3,000 חשבונות שירות של Kubernetes.

כדי לזהות את הבעיה:

  1. חיפוש של gke-metadata-server Pods שקורסים במרחב השמות kube-system:

    kubectl get pods -n=kube-system | grep CrashLoopBackOff

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

    NAMESPACE     NAME                        READY     STATUS             RESTARTS   AGE
kube-system   gke-metadata-server-8sm2l   0/1       CrashLoopBackOff   194        16h
kube-system   gke-metadata-server-hfs6l   0/1       CrashLoopBackOff   1369       111d
kube-system   gke-metadata-server-hvtzn   0/1       CrashLoopBackOff   669        111d
kube-system   gke-metadata-server-swhbb   0/1       CrashLoopBackOff   30         136m
kube-system   gke-metadata-server-x4bl4   0/1       CrashLoopBackOff   7          15m

  2. מתארים את ה-Pod שקורס כדי לאשר שהסיבה הייתה פינוי בגלל חוסר זיכרון (OOM):

    kubectl describe pod POD_NAME --namespace=kube-system | grep OOMKilled

    מחליפים את POD_NAME בשם של ה-Pod שרוצים לבדוק.

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

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

‫GKE משתמש ב Google Cloudסוכן השירות של Kubernetes Engine שמנוהל על ידי Google כדי להקל על איחוד זהויות של עומסי עבודה ב-GKE באשכולות שלכם. Google Cloud מעניק לסוכן השירות הזה באופן אוטומטי את התפקיד 'סוכן השירות של Kubernetes Engine' (roles/container.serviceAgent) בפרויקט שלכם כשאתם מפעילים את Kubernetes Engine API.

אם מנסים להפעיל איחוד שירותי אימות הזהות של עומסי עבודה ב-GKE באשכולות בפרויקט שבו לסוכן השירות אין את התפקיד Kubernetes Engine Service Agent, הפעולה נכשלת ומוצגת הודעת שגיאה שדומה להודעה הבאה:

Error waiting for updating GKE cluster workload identity config: DeployPatch failed

כדי לפתור את הבעיה, נסו את הפתרונות הבאים:

  1. בודקים אם סוכן השירות קיים בפרויקט ומוגדר בצורה נכונה:

    gcloud projects get-iam-policy PROJECT_ID \
    --flatten=bindings \
    --filter=bindings.role=roles/container.serviceAgent \
    --format="value[delimiter='\\n'](bindings.members)"

    מחליפים את PROJECT_ID במזהה הפרויקט ב- Google Cloud.

    אם סוכן השירות מוגדר בצורה נכונה, הפלט מציג את הזהות המלאה של סוכן השירות:

    serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com

    אם סוכן השירות לא מופיע בפלט, צריך להעניק לו את התפקיד Kubernetes Engine Service Agent. כדי להקצות את התפקיד הזה, צריך לבצע את השלבים הבאים.

  2. מציאת מספר הפרויקט ב- Google Cloud :

    gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)"

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

    123456789012

  3. נותנים לסוכן השירות את התפקיד:

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
    --role=roles/container.serviceAgent \
    --condition=None

    מחליפים את PROJECT_NUMBER במספר הפרויקט ב- Google Cloud.

  4. מנסים שוב להפעיל את איחוד הזהויות של עומסי עבודה ל-GKE.

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