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

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

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

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

‫RBAC ו-IAM

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

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

Error from server (Forbidden): roles.rbac.authorization.k8s.io is forbidden:
User "example-account@example-project.s3ns.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. הוראות מפורטות זמינות במאמר בנושא הרשאת פעולות באשכולות באמצעות בקרת גישה המבוססת על תפקידים (RBAC).

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

ל-Pod אין אפשרות לאמת את Cloud de Confiance by S3NS

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

  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 שלכם מוגדרים כללי תעבורת נתונים יוצאת (egress) שדוחים כברירת מחדל, או מכשירי ניתוב בהתאמה אישית, ודאו שתעבורת הנתונים היוצאת ב-HTTPS מותרת לשירות הציבורי של Google לאימות אסימוני אבטחה (sts.googleapis.com ביציאה 443).

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

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

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

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

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

    principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.s3ns.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.s3ns.iam.gserviceaccount.com

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

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

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

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

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

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

ERROR: Error: Invalid form of account ID test_account.s3ns.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.s3ns.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. כשל בגישה צפוי להתרחש בצינורות עיבוד נתונים לפריסה או בהגדרות הצהרתיות של Cloud de Confiance , שבהן משאבים כמו מדיניות הרשאות של IAM, קישורי תפקידים ו-Pods של Kubernetes נוצרים ביחד. הודעת השגיאה הבאה מופיעה ביומני הרישום של הפוד:

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

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

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

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

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

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

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

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

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

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

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 שמוגדרת בהארדקוד, שבה שירות המטא-נתונים תמיד זמין בפלטפורמות מחשוב של Cloud de Confiance .

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

  • Python
  • Java
  • Node.js

  • Golang

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

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

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

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

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

  • פריסת 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 של Cloud de Confiance נכשל. אם לא תגדירו את האפליקציות כך שינסו לשלוח את הבקשות מחדש, יכול להיות שעומסי העבודה ייכשלו.

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

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

    כניסה לדף 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.

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

gke-metadata-server Pod is crashing

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

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

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

  1. חיפוש Pods של gke-metadata-server שקורסים במרחב השמות 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 באשכולות, GKE משתמש בסוכן השירות של Kubernetes Engine שמנוהל על ידי Cloud de Confiance.כשמפעילים את Kubernetes Engine API, המערכת של Cloud de Confiance נותנת באופן אוטומטי לסוכן השירות הזה את התפקיד "סוכן השירות של Kubernetes Engine" (roles/container.serviceAgent) בפרויקט.

אם תנסו להפעיל את איחוד זהויות של עומסי עבודה ל-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 במזהה הפרויקט ב- Cloud de Confiance.

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

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

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

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

    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.s3ns-system.iam.gserviceaccount.com \
    --role=roles/container.serviceAgent \
    --condition=None

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

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

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