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

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

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

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

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

סוגי חשבונות שירות ב-GKE
Kubernetes ServiceAccount
  • אובייקט ServiceAccount בשרת ה-API של Kubernetes
  • מוגדר למרחב שמות של Kubernetes באשכול
  • מספק זהות ל-Pods לשימוש בתוך האשכול
חשבון שירות ב-IAM
  • ניהול באמצעות IAM API
  • ההגדרה מוגבלת לפרויקט Cloud de Confiance
  • מספק זהות לאפליקציות בפרויקט

Kubernetes ServiceAccounts

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

יוצרים ServiceAccount של Kubernetes במרחב שמות, ואז מקצים את ה-ServiceAccount הזה ל-Pod באמצעות השדה serviceAccountName במניפסט של ה-Pod. תהליך ה-kubelet בצומת מקבל טוקן למוכ"ז לטווח קצר עבור חשבון השירות שהוקצה, ומטמיע את הטוקן כנפח מושלך ב-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: טוקן למוכ"ז קשור לכל UID ייחודי של Pod, ולכן יצירה מחדש של ה-Pods מבטלת את התוקף של פרטי הכניסה הקודמים.
  • יוצרים מחדש את חשבון השירות של Kubernetes: טוקן למוכ"ז קשור ל-UID של אובייקט ServiceAccount ב-Kubernetes API. מוחקים את ServiceAccount ויוצרים ServiceAccount חדש באותו שם. הטוקנים הקודמים הופכים ללא תקפים כי ה-UID של חשבון השירות החדש שונה.
  • ביצוע רוטציית פרטי כניסה: הפעולה הזו מבטלת את כל פרטי הכניסה של חשבון השירות של Kubernetes באשכול. הרוטציה משנה גם את אישור ה-CA ואת כתובת ה-IP של האשכול. פרטים נוספים זמינים במאמר בנושא רוטציית פרטי כניסה.

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

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

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

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

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

Kubernetes Engine Service Agent

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

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

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

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

Kubernetes Engine Default Node Service Agent

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

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

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

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

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

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

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

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

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

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

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

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

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

    CLUSTER_PROJECT_NUMBER-compute@developer.s3ns-system.iam.gserviceaccount.com

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

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

    SERVICE_ACCOUNT_NAME@SERVICE_ACCOUNT_PROJECT_ID.s3ns.iam.gserviceaccount.com

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

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

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

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

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

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

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

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

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

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

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