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

במאמר הזה מוסבר על איחוד זהויות של עומסי עבודה ב-GKE, כולל איך הוא פועל, איך ההפעלה שלו משפיעה על אשכולות GKE ואיך מעניקים תפקידים לישויות Kubernetes במדיניות של ניהול זהויות והרשאות גישה (IAM). ברוב המקרים, מומלץ להשתמש ב-Workload Identity Federation for GKE כדי לאבטח ולנהל את הגישה של עומסי העבודה שפועלים ב-GKE לשירותי Google Cloud .

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

הסברים על המונחים

בדף הזה מוסבר ההבדל בין חשבונות שירות של Kubernetes לבין חשבונות שירות של ניהול זהויות והרשאות גישה (IAM).

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

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

יכול להיות שאפליקציות שפועלות ב-GKE יצטרכו גישה ל-Google Cloud API כמו Compute Engine API,‏ BigQuery Storage API או Machine Learning APIs.

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

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

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

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

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

  • יוצר מאגר זהויות של עומסי עבודה קבוע עבור פרויקט Google Cloudשל האשכול בפורמט הבא:

    PROJECT_ID.svc.id.goog

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

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

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

יצירה של מדיניות הרשאות ב-IAM Google Cloud למשאבים

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

במאמר סוגי משאבים שמקבלים מדיניות הרשאות מפורטת רשימה של משאבים שתומכים במדיניות הרשאות.

שימוש בתנאים במדיניות IAM

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

תנאים יכולים להיות שימושיים גם אם מגדירים את מדיניות ההרשאות ברמת הפרויקט, התיקייה או הארגון, במקום במשאבים ספציפיים כמו סודות ב-Secret Manager או קטגוריות ב-Cloud Storage.

כדי להוסיף תנאי למדיניות ההרשאות, אפשר להיעזר במקורות המידע הבאים:

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

ביטויי תנאי לדוגמה
מתן גישה לפני השעה שצוינה 
request.time < timestamp('TIMESTAMP')

מחליפים את TIMESTAMP בחותמת זמן ב-UTC, כמו 2024-08-30T00:00:00.000Z.
מתן גישה אם למשאב בבקשה יש את התג שצוין 
resource.matchTag('TAG_KEY', 'TAG_VALUE')

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

  • ‫TAG_KEY: מפתח התג להתאמה, כמו env
  • ‫TAG_VALUE: הערך של התג, כמו dev

הפניה למשאבי Kubernetes בכללי מדיניות IAM

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

PREFIX://iam.googleapis.com/projects/1234567890/locations/global/workloadIdentityPools/example-project.svc.id.goog/SELECTOR

בדוגמה הזו, צריך להתייחס לשדות הבאים:

  • ‫PREFIX: הערך צריך להיות principal או principalSet, בהתאם למשאב שבוחרים. ‫principal הוא משאב ספציפי, כמו ServiceAccount יחיד. ‫principalSet מיועד למספר משאבים ששייכים למשאב שצוין, כמו כל ה-Pods באשכול ספציפי.
  • ‫SELECTOR: מחרוזת שבוחרת סוג של חשבון משתמש. לדוגמה, kubernetes.serviceaccount.uid/SERVICEACCOUNT_UID בוחר ServiceAccount לפי ה-UID שלו.

בטבלה הבאה מוצגים סוגי הגורמים המורשים הנתמכים ב-GKE:

סוג המזהה של חשבון המשתמש תחביר
כל קבוצות ה-Pod שמשתמשות בחשבון שירות ספציפי ב-Kubernetes בוחרים את ServiceAccount לפי שם: 
principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/SERVICEACCOUNT

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

  • ‫PROJECT_NUMBER: מספר הפרויקט. כדי לקבל את מספר הפרויקט, אפשר לעיין במאמר בנושא זיהוי פרויקטים.
  • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
  • ‫NAMESPACE: מרחב השמות של Kubernetes.
  • ‫SERVICEACCOUNT: השם של חשבון השירות ב-Kubernetes.
Select the ServiceAccount by UID: 
principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/kubernetes.serviceaccount.uid/SERVICEACCOUNT_UID

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

  • ‫PROJECT_NUMBER: מספר הפרויקט. כדי לקבל את מספר הפרויקט, אפשר לעיין במאמר בנושא זיהוי פרויקטים.
  • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
  • ‫SERVICEACCOUNT_UID: ה-UID של אובייקט ServiceAccount בשרת ה-API.
כל ה-Pods במרחב שמות, ללא קשר לחשבון השירות או לאשכול 
principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/namespace/NAMESPACE

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

  • ‫PROJECT_NUMBER: מספר הפרויקט. כדי לקבל את מספר הפרויקט, אפשר לעיין במאמר בנושא זיהוי פרויקטים.
  • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
  • ‫NAMESPACE: מרחב השמות של Kubernetes.
כל ה-Pods באשכול מסוים 
principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/kubernetes.cluster/https://container.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME

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

  • ‫PROJECT_NUMBER: מספר הפרויקט. כדי לקבל את מספר הפרויקט, אפשר לעיין במאמר בנושא זיהוי פרויקטים.
  • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
  • ‫CLUSTER_NAME: השם של אשכול GKE.
  • ‫LOCATION: המיקום של האשכול.

תהליך פרטי הכניסה

כשעומס עבודה שולח בקשה לגישה ל-API של Google Cloud , למשל כשמשתמשים ב Google Cloud ספריית לקוח, מתבצעים שלבי האימות הבאים:

איך עומס עבודה מקבל אסימון של חשבון שירות ב-IAM באמצעות Workload Identity.
איור 1: איך עומס עבודה מקבל אסימון גישה מאוחד באמצעות איחוד זהויות של עומסי עבודה ל-GKE.
  1. Application Default Credentials‏ (ADC) מבקש אסימון גישה של Google Cloud משרת המטא-נתונים של Compute Engine שפועל במכונה הווירטואלית.
  2. שרת המטא-נתונים של GKE מיירט את בקשת הטוקן ומבקש משרת ה-API של Kubernetes טוקן Kubernetes ServiceAccount שמזהה את עומס העבודה ששלח את הבקשה. פרטי הכניסה האלה הם אסימון אינטרנט מסוג JSON‏ (JWT) שחתום על ידי שרת ה-API.
  3. שרת המטא-נתונים של GKE משתמש ב-Security Token Service כדי להחליף את ה-JWT באסימון גישה מאוחד לזמן קצר, שמפנה לזהות של עומס העבודה ב-Kubernetes.

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

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

מכסה ל-Exchange Token API ב-Security Token Service

ל-Exchange Token API ב-Security Token Service יש מגבלת מכסה של 6,000 בקשות לדקה. אם מוצגות שגיאות QUOTA_EXCEEDED, אפשר לבקש להגדיל את המכסה Token exchange requests per minute דרך הדף Quotas & System Limits.

זהות זהה

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

לדוגמה, נבחן את התרשים הבא. קלאסטרים A ו-B שייכים לאותו מאגר זהויות של עומסי עבודה. Google Cloud מזהה אפליקציות שמשתמשות ב-back-ksa ServiceAccount במרחב השמות backend של קלאסטר A ושל קלאסטר B כאותה זהות. מערכת IAM לא מבדילה בין האשכולות שמבצעים את הקריאות.

דיאגרמה שממחישה את הזהות במאגר זהויות של עומסי עבודה
איור 2: גישה לממשקי API באמצעות איחוד שירותי אימות הזהות של עומסי עבודה ב-GKE. Google Cloud

הזהות האחידה הזו גם אומרת שצריך להיות לכם אמון בכל אשכול במאגר זהויות של עומסי עבודה ספציפי. לדוגמה, אם אשכול חדש, Cluster C בדוגמה הקודמת, היה בבעלות צוות לא מהימן, הוא יכול היה ליצור מרחב שמות backendולגשת לממשקי API Google Cloud באמצעות back-ksaServiceAccount, בדיוק כמו Cluster A ו-Cluster B.

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

שרת מטא-נתונים של GKE

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

שרת המטא-נתונים של GKE פועל כ-DaemonSet, עם Pod אחד בכל צומת Linux או שירות Windows מקורי בכל צומת Windows באשכול. שרת המטא-נתונים מיירט בקשות HTTP אל http://metadata.google.internal (169.254.169.254:80). לדוגמה, הבקשה GET /computeMetadata/v1/instance/service-accounts/default/token מאחזרת אסימון לחשבון השירות של IAM שה-Pod מוגדר להתחזות אליו. התעבורה לשרת המטא-נתונים של GKE אף פעם לא יוצאת מהמכונה הווירטואלית שמארחת את ה-Pod.

משך החיים של הטוקן

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

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

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

  1. בודקים אם תוקף אסימון הגישה פג אחרי תקופה של 3 דקות ו-45 שניות. הפרמטר exp במטען הייעודי (payload) של האסימון מציין את חותמת הזמן של תפוגת האסימון.
  2. אם התוקף של האסימון יפוג בעוד 3 דקות ו-45 שניות, צריך לשלוח בקשה לאסימון.

בטבלאות הבאות מתואר קבוצת המשנה של נקודות הקצה של שרת המטא-נתונים של Compute Engine שזמינות בשרת המטא-נתונים של GKE. רשימה מלאה של נקודות הקצה שזמינות בשרת המטא-נתונים של Compute Engine מופיעה במאמר בנושא ערכי ברירת מחדל של מטא-נתונים של מכונות וירטואליות.

מטא-נתונים של מופע

מטא-נתונים של מופע מאוחסנים בספרייה הבאה.

http://metadata.google.internal/computeMetadata/v1/instance/

הערך תיאור
hostname

שם המארח של הצומת.
id

המזהה הייחודי של הצומת.
service-accounts/

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

  • aliases
  • email: כתובת האימייל בחשבון השירות.
  • ‫identity: אסימון JWT (‏JSON Web Token) ייחודי לצומת. צריך לכלול את הפרמטר audience בבקשה. לדוגמה, ?audience=http://www.example.com.
  • ‫scopes: היקפי הגישה שהוקצו לחשבון השירות.
  • ‫token: אסימון הגישה מסוג OAuth 2.0 לאימות של עומסי העבודה.
zone

התחום (zone) של Compute Engine שבו נמצא הצומת של GKE.

מאפייני המכונה

מאפייני המופע מאוחסנים בספרייה הבאה.

http://metadata.google.internal/computeMetadata/v1/instance/attributes/

הערך תיאור
cluster-location

התחום או האזור של Compute Engine שבהם נמצא האשכול.
cluster-name

השם של אשכול GKE.
cluster-uid

המזהה הייחודי (UID) של אשכול GKE.

המאפיינים שמפורטים בטבלה הם המאפיינים הנתמכים היחידים. אם תנסו לגשת למאפיינים שלא נתמכים, יחידת ה-Pod‏ gke-metadata-server במרחב השמות kube-system תיצור שגיאה 404 ותתעד אותה. השגיאה דומה לזו:

HTTP/404: generic::not_found: no child "", Reason: "NOT_FOUND", UserMessage: "Not Found"

אם אתם משתמשים ב-istio-proxy, תופיע הודעת שגיאה כמו זו:

Error fetching GCP Metadata property gcp_gce_instance_template: metadata: GCE metadata "instance/attributes/UNSUPPORTED_ATTRIBUTE" not defined

מטא-נתונים של פרויקט

המטא-נתונים של פרויקט האשכול מאוחסנים בספרייה הבאה.

http://metadata.google.internal/computeMetadata/v1/project/

הערך תיאור
project-id

מזהה הפרויקט ב- Google Cloud .
numeric-project-id

מספר הפרויקט Google Cloud .

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

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

  • אם מקשרים חשבונות שירות של Kubernetes לחשבונות שירות של IAM כדי להגדיר איחוד זהויות של עומסי עבודה ל-GKE, שרת המטא-נתונים של GKE מחזיר את הערך SERVICEACCOUNT_NAME.svc.id.goog כמזהה של חשבון השירות. המזהה הזה לא משתמש בתחביר הרגיל של מזהה חשבון ראשי ב-IAM, ולכן יכול להיות שייגרמו שגיאות בפעולות תכנותיות מסוימות. כדי לקבל את מזהה חשבון השירות כמזהה של חשבון משתמש ב-IAM, מוסיפים את ההערה iam.gke.io/return-principal-id-as-email: "true" ל-ServiceAccount של Kubernetes.

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

  • כשמשתמשים במנהל התקן ה-CSI של Cloud Storage FUSE עם אשכולות GKE רגילים בגרסה 1.33.3-gke.1226000 ואילך, קבוצות ה-Pod שפועלות ברשת המארחת (hostNetwork: true) יכולות לבצע אימות באמצעות חשבון השירות שלהן ב-Kubernetes. מידע נוסף זמין במאמר בנושא הגדרת גישה ל-Pods עם רשת מארחת.

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

  • סוכני הרישום ביומן והניטור המובנים של GKE ממשיכים להשתמש בחשבון השירות של הצומת.

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

  • איחוד זהויות של עומסי עבודה ל-GKE מגדיר מגבלה של 500 חיבורים בו-זמניים לשרת המטא-נתונים של GKE לכל צומת. שיחות נוספות בו-זמניות שחורגות מהמגבלה הזו מוכנסות לתור המתנה לעיבוד מאוחר יותר. מנגנון התור הזה עלול לגרום לשגיאות HTTP/499 אם פסק הזמן של הלקוח יגיע לפני ששרת המטא-נתונים של GKE יוכל לעבד את הבקשה.

  • שרת המטא-נתונים של GKE משתמש במשאבי זיכרון באופן יחסי למספר הכולל של חשבונות השירות של Kubernetes באשכול. אם באשכול יש יותר מ-3,000 חשבונות שירות של Kubernetes, יכול להיות ש-kubelet יסיים את הפעולה של קבוצות ה-Pod של שרת המטא-נתונים. אפשר למצוא פתרונות אפשריים במאמר פתרון בעיות.

  • איחוד זהויות של עומסי עבודה ל-GKE פועל בתוך גבולות גזרה של VPC Service Controls, ומאפשר גישה למשאבים בתוכו. עם זאת, VPC Service Controls לא אוכף בבקשות חוצות-גבולות את בקרת הגישה שמבוססת על הזהויות המאוחדות האלה. אפשר להשתמש בהתחזות לחשבון שירות כדי לגשת למשאבים בהיקף אחר.

חלופות ל-Workload Identity Federation ל-GKE

אפשר להשתמש באחת מהחלופות הבאות ל-Workload Identity Federation for GKE כדי לגשת ל-Google Cloud APIs מ-GKE. מומלץ להשתמש באיחוד שירותי אימות הזהות של עומסי עבודה ב-GKE, כי החלופות האלה מחייבות אתכם להתפשר על אבטחה מסוימת.

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