מידע על חשבונות שירות ב-GKE

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

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

חשבונות שירות של Kubernetes וחשבונות שירות של IAM

בטבלה הבאה מפורטים ההבדלים העיקריים בין חשבונות שירות ב-Kubernetes לבין חשבונות שירות ב-IAM:

Kubernetes ServiceAccounts

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

יוצרים Kubernetes ServiceAccount במרחב שמות, ואז מקצים את ה-ServiceAccount הזה ל-Pod באמצעות השדה serviceAccountName במניפסט של ה-Pod. תהליך kubelet בצומת מקבל אסימון Bearer לטווח קצר עבור חשבון השירות שהוקצה, ומטמיע את האסימון כנפח מוטל ב-Pod. כברירת מחדל, השם של הנפח המשוער הזה מתחיל בקידומת kube-api-access-. כרכים שמתחילים בקידומת הזו מנוהלים על ידי GKE, ולכן אי אפשר לשנות את הגודל שלהם. כדי לקבל נתונים מדויקים יותר על השימוש בדיסק, כדאי להחריג מהגדרות המעקב את אמצעי האחסון שמתחילים בקידומת kube-api-access-.

אסימון הגישה לטווח קצר הוא אסימון JWT (‏JSON Web Token) שחתום על ידי שרת ה-API, שהוא ספק OpenID Connect ‏ (OIDC). כדי לאמת את טוקן ה-Bearer, צריך לקבל את מפתח האימות הציבורי של האשכול על ידי קריאה לשיטה projects.locations.clusters.getJwks ב-GKE API.

• במאמר חשבונות שירות במסמכי התיעוד של Kubernetes מוסבר על היסודות של חשבונות שירות ב-Kubernetes.
• במאמר הגדרת חשבונות שירות ל-Pods מוסבר איך ליצור חשבונות שירות חדשים, לתת הרשאות באמצעות בקרת גישה מבוססת-תפקידים (RBAC) ולהקצות חשבונות שירות ל-Pods.
• שיטות מומלצות ל-RBAC
• כדי לקרוא את הגדרת OIDC של שרת Kubernetes API עבור אשכול, מפעילים את השיטה projects.locations.clusters.well-known.getOpenid-configuration ב-GKE API.

פרטי כניסה שנחשפו של חשבון שירות ב-Kubernetes

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

• צריך ליצור מחדש את ה-Pods: טוקן ה-Bearer קשור לכל UID ייחודי של Pod, ולכן יצירה מחדש של ה-Pods מבטלת את תוקף האישורים הקודמים.
• יוצרים מחדש את חשבון השירות של Kubernetes: אסימון ה-Bearer קשור ל-UID של אובייקט ServiceAccount ב-Kubernetes API. מוחקים את ServiceAccount ויוצרים ServiceAccount חדש באותו שם. הטוקנים הקודמים הופכים ללא תקפים כי ה-UID של חשבון השירות החדש שונה.
• ביצוע רוטציה של פרטי הכניסה: הפעולה הזו מבטלת את כל פרטי הכניסה של חשבון השירות של Kubernetes באשכול. הרוטציה משנה גם את אישור ה-CA ואת כתובת ה-IP של האשכול. פרטים נוספים זמינים במאמר בנושא רוטציה של פרטי כניסה.

חשבונות שירות ב-IAM

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

לסקירה כללית על חשבונות שירות ב-IAM

סוכני שירות של GKE

סוכן שירות ב-IAM הוא חשבון שירות ב-IAM ש Google Cloud מנהל. ‫GKE משתמש בשני סוכני השירות הבאים:

• סוכן שירות של Kubernetes Engine
• סוכן שירות של צומת ברירת המחדל של Kubernetes Engine

סוכן שירות של Kubernetes Engine

‫GKE משתמש בסוכן השירות של Kubernetes Engine כדי לנהל בשמכם את מחזור החיים של משאבי האשכול, כמו צמתים, דיסקים ומאזני עומסים. לסוכן השירות הזה יש את הדומיין container-engine-robot.iam.gserviceaccount.com, והוא מקבל את התפקיד סוכן שירות של Kubernetes Engine (roles/container.serviceAgent) בפרויקט כשמפעילים את GKE API.

המזהה של סוכן השירות הזה הוא:

service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com

‫CLUSTER_PROJECT_NUMBER הוא מספר הפרויקט שמכיל את אשכול GKE.

סוכן שירות של צומת ברירת המחדל של Kubernetes Engine

‫GKE משתמש בסוכן שירות ברירת המחדל של צומת Kubernetes Engine כדי לתמוך ברישום ביומן ובמעקב של צומתי Kubernetes באשכולות שמשתמשים ב-Kubernetes גרסה 1.33 ואילך. לסוכן השירות הזה יש את הדומיין gcp-sa-gkenode.iam.gserviceaccount.com, והוא מקבל את התפקיד Kubernetes Engine Default Node Service Agent (roles/container.defaultNodeServiceAgent) בפרויקט כשמפעילים את GKE API.

המזהה של סוכן השירות הזה הוא:

service-CLUSTER_PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com

‫CLUSTER_PROJECT_NUMBER הוא מספר הפרויקט שמכיל את אשכול GKE.

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

חשבונות שירות של צמתים

‫GKE משתמש בחשבונות שירות של IAM שמצורפים לצמתים כדי להריץ משימות מערכת כמו רישום ביומן ומעקב. לפחות, חשבונות השירות של הצמתים צריכים לקבל את התפקיד Kubernetes Engine Default Node Service Account ‏(roles/container.defaultNodeServiceAccount) בפרויקט. כברירת מחדל, GKE משתמש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine, שנוצר באופן אוטומטי בפרויקט, כחשבון השירות של הצומת.

אם בארגון שלכם נאכף iam.automaticIamGrantsForDefaultServiceAccounts אילוץ מדיניות הארגון, יכול להיות שלחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine בפרויקט שלכם לא יוקצו באופן אוטומטי ההרשאות הנדרשות ל-GKE.

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

אל תשביתו את חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine, אלא אם אתם מבצעים מיגרציה לחשבונות שירות בניהול המשתמשים.

כתובות אימייל של חשבונות שירות של צמתים

כתובת האימייל של חשבון השירות של הצומת תלויה בסוג חשבון השירות, באופן הבא:

• חשבון השירות של Compute Engine שמוגדר כברירת מחדל:

  CLUSTER_PROJECT_NUMBER-compute@developer.gserviceaccount.com
  

  מחליפים את CLUSTER_PROJECT_NUMBER במספר הפרויקט שמכיל את האשכול, למשל 1234567890.

• חשבון שירות בהתאמה אישית:

  SERVICE_ACCOUNT_NAME@SERVICE_ACCOUNT_PROJECT_ID.iam.gserviceaccount.com
  

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

  • ‫SERVICE_ACCOUNT_NAME: השם של חשבון השירות.
  • ‫SERVICE_ACCOUNT_PROJECT_ID: מזהה הפרויקט של Google Cloud הפרויקט שמכיל את חשבון השירות.

חשבונות שירות של צמתים וסוכני שירות של פרויקטים

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

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

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

• יצירת אסימונים בחשבון שירות (roles/iam.serviceAccountTokenCreator) בחשבון השירות לסוכן השירות של Compute Engine בפרויקט של האשכול.
• ‫Service Account User ‏(roles/iam.serviceAccountUser) בחשבון השירות לסוכן השירות של GKE בפרויקט האשכול.

מידע נוסף זמין במאמר בנושא הגדרת השימוש בחשבונות שירות בפרויקטים.

מתי כדאי להשתמש בחשבון שירות ספציפי

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

• הקצאת זהות לקבוצות ה-Pod לשימוש באשכול: משתמשים ב-Kubernetes ServiceAccount. לכל מרחב שמות של Kubernetes יש defaultServiceAccount, אבל מומלץ ליצור ServiceAccount חדש עם הרשאות מינימליות לכל עומס עבודה בכל מרחב שמות.
• הקצאת זהות ל-Pods לשימוש מחוץ לאשכול: משתמשים באיחוד זהויות של עומסי עבודה ל-GKE. איחוד זהויות של עומסי עבודה ל-GKE מאפשר לכם לציין משאבי Kubernetes כמו ServiceAccounts כישויות מורשות במדיניות IAM. לדוגמה, כדאי להשתמש באיחוד זהויות של עומסי עבודה ל-GKE כשקוראים ל-APIs כמו Secret Manager או Spanner מקבוצות ה-Pod. Google Cloud
• הגדרת זהות ברירת מחדל לצמתים: כשיוצרים אשכולות או צמתים ב-GKE, כדאי להשתמש בחשבון שירות IAM עם הרשאות מינימליות בהתאמה אישית. אם לא משתמשים בחשבון שירות מותאם אישית של IAM, ‏ GKE משתמש בחשבון השירות שמוגדר כברירת מחדל של Compute Engine.

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

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