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

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

במאמר הזה מוסבר איך לאבחן בעיות באימות, לתקן שגיאות ב-Kubernetes RBAC וב-IAM, ולפתור בעיות ב-Workload Identity Federation ל-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. צריך לוודא שהפעלתם את IAM Service Account Credentials API בפרויקט שמכיל את אשכול GKE.

    הפעלת IAM Credentials API

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

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

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

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

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

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

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

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

  4. אם יש לכם מדיניות רשת של אשכול, אתם צריכים לאפשר תעבורת נתונים יוצאת (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 בשם של מדיניות הרשת ב-GKE.

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

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

    kubectl describe serviceaccount \
    --namespace NAMESPACE KSA_NAME

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

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

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

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

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

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

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

    - members:
  - serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_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 KSA_NAME \
    --namespace=NAMESPACE \
    iam.gke.io/return-principal-id-as-email="true"

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

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

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

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

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 Google שנגרמות מבעיות בפענוח DNS. אם השלבים שבקטע הזה לא פותרים את שגיאות החיבור, אפשר לעיין בקטע שגיאות של זמן קצוב לתפוגה בהפעלת ה-Pod.

חלק מספריות הלקוח מוגדרות להתחבר לשרתי המטא-נתונים של GKE ו-Compute Engine על ידי פתרון שם ה-DNS ‏metadata.google.internal. בספריות האלה, פתרון DNS תקין בתוך האשכול הוא תלות קריטית כדי שעומסי העבודה יוכלו לעבור אימות לשירותיםGoogle Cloud . 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: KSA_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, עומסי עבודה יכולים לשלוח בקשות ברגע שהם מתחילים לפעול, בלי קשר לשאלה אם עומס העבודה של ה-proxy של רשת השירות, שמיירט את התנועה ומפנה אותה מחדש, פועל. ב-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 קורס

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

הבעיה הבאה מתרחשת כששימוש המשאבים של gke-metadata-server Pod חורג מהמגבלות שלו. ה-kubelet מוציא את ה-Pod עם שגיאה של חוסר זיכרון. הבעיה הזו יכולה להתרחש אם באשכול יש יותר מ-3,000 חשבונות שירות של Kubernetes.

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

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

    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 Cloud שמנוהל על ידי Google כדי להקל על השימוש ב-איחוד זהויות של עומסי עבודה ל-GKE באשכולות שלכם.המערכת מעניקה לסוכן השירות הזה באופן אוטומטי את התפקיד Kubernetes Engine Service Agent ‏(roles/container.serviceAgent) בפרויקט שלכם כשאתם מפעילים את Google Kubernetes Engine API.

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

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. כדי להעניק את התפקיד הזה, צריך לבצע את השלבים הבאים.

  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.

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