סקירה כללית של Workload Identity

Workload Identity מאפשרת להקצות זהויות והרשאות שונות ומפורטות לכל אפליקציה באשכול. הדרך המומלצת לאפליקציות שפועלות ב-GKE ב-Azure לגשת ל-Azure ול Google Cloud שירותים.

בכל אשכולות ה-GKE מופעלת Workload Identity.

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

‫Workload Identity מיישם איחוד שירותי אימות זהויות, או הקצאת הרשאות או תפקידים לספק חיצוני. לכל אשכול יש ספק OpenID Connect ‏ (OIDC) מובנה. כשקבוצת Pod פועלת באשכול, היא פועלת באמצעות חשבון שירות של Kubernetes. אפשר להגדיר את ה-Pod כך שיקבל אסימון עם פרטי כניסה לטווח קצר לחשבון השירות שלו ב-Kubernetes באמצעות כרך של אסימון חשבון שירות מאוגד.

ספקי OpenID Connect

כל אשכול יכול לשמש כספק OpenID Connect‏ (OIDC). באמצעות הספק הזה, אתם יכולים לספק פרטי כניסה של חשבון שירות של Kubernetes לשירותים שתומכים באיחוד זהויות באמצעות OIDC.

מזהה ה-URI של המנפיק של הספק הזה משמש גם כנקודת קצה (endpoint) לגילוי OIDC. שירותים יכולים להשתמש בנקודת הקצה הזו של גילוי כדי לקבל את JSON Web Key Set‏ (JWKS), שמספק מידע על מפתח ציבורי שמאפשר להם לאמת את פרטי הכניסה של חשבון שירות Kubernetes.

Google Cloud מאגרי זהויות וספקים של IAM

‫Google Cloud IAM תומך באיחוד זהויות באמצעות OIDC. כל אשכולות GKE מוגדרים כספקי זהויות במאגר הזהויות של עומסי העבודה PROJECT_ID.svc.id.goog.

כדי לקבל את השם של מאגר הזהויות של עומסי עבודה והספקים, אפשר לעיין במאמר בנושא שימוש ב-Workload Identity עם Google Cloud.

חלופות ל-Workload Identity

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

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

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

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