ניהול זהויות באמצעות שירות הזהויות של GKE

‫Google Distributed Cloud תומך ב-OpenID Connect ‏(OIDC) וב-Lightweight Directory Access Protocol ‏ (LDAP) כמנגנוני אימות לאינטראקציה עם שרת ה-API של Kubernetes באשכול, באמצעות שירות הזהויות של GKE. שירות הזהויות של GKE הוא שירות אימות שמאפשר לכם להשתמש בפתרונות הזהויות הקיימים שלכם לאימות באשכולות. המשתמשים יכולים להיכנס לאשכולות ולהשתמש בהם משורת הפקודה (כל הספקים) או ממסוף Google Cloud (OIDC בלבד), והכול באמצעות ספק הזהויות הקיים שלכם.

שירות הזהויות של GKE פועל עם כל סוג של אשכול Bare Metal: אדמין, משתמש, היברידי או עצמאי. אפשר להשתמש בספקי זהויות מקומיים ובספקי זהויות שאפשר לגשת אליהם באופן ציבורי. לדוגמה, אם בארגון שלכם מופעל שרת Active Directory Federation Services (ADFS), שרת ה-ADFS יכול לשמש כספק OpenID. אפשר גם להשתמש בשירותים של ספקי זהויות שאפשר לגשת אליהם באופן ציבורי, כמו Okta. יכול להיות שאישורים של ספק זהויות יונפקו על ידי רשות אישורים (CA) ציבורית מוכרת, או על ידי רשות אישורים פרטית.

הערה: שירות הזהויות של GKE פועל כ-Pod בתוך מישור הבקרה של האשכול. במהלך שלבי מחזור החיים של האשכול, שרת ה-API מוגדר באופן דינמי להשתמש בשירות הזהויות של GKE בתוך האשכול כ-webhook לאימות לכל הבקשות הנכנסות. שרת ה-API לא יכול להשתמש ב-DNS בתוך האשכול. כתוצאה מכך, שרת ה-API מוגדר לגשת ל-GKE Identity Service כגישה למשאב REST. ביומני הביקורת, הקריאה הזו מתועדת כCREATEבקשה למשאב Services או proxy על ידי משתמש system:anonymous.

סקירה כללית על אופן הפעולה של שירות הזהויות של GKE זמינה במאמר היכרות עם שירות הזהויות של GKE.

אם אתם כבר משתמשים במזהי Google כדי להיכנס לאשכולות GKE או רוצים להשתמש בהם במקום בספק OIDC או LDAP, מומלץ להשתמש בשער Connect לאימות. מידע נוסף זמין במאמר חיבור לאשכולות רשומים באמצעות שער החיבור.

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

לפני שמתחילים

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

• כדי לבצע אימות דרך Google Cloud המסוף, כל אשכול שרוצים להגדיר צריך להיות רשום ב-Fleet של הפרויקט.

תהליך ההגדרה ואפשרויות ההגדרה

שירות הזהויות של GKE תומך בספקי זהויות באמצעות הפרוטוקולים הבאים:

• ‫OpenID Connect (OIDC). אנחנו מספקים הוראות ספציפיות להגדרה של כמה ספקי OpenID פופולריים, כולל Microsoft, אבל אפשר להשתמש בכל ספק שמטמיע OIDC.

• ‫Lightweight Directory Access Protocol ‏(LDAP). אתם יכולים להשתמש ב-GKE Identity Service כדי לבצע אימות באמצעות LDAP עם Active Directory או שרת LDAP.

OIDC

1. רושמים את GKE Identity Service כלקוח אצל ספק OIDC לפי ההוראות במאמר הגדרת ספקים ל-GKE Identity Service.

2. בוחרים מבין אפשרויות ההגדרה הבאות של האשכול:

   • (מומלץ) מגדירים את האשכולות ברמת הצי לפי ההוראות במאמר הגדרת אשכולות ל-GKE Identity Service ברמת הצי. באפשרות הזו, הגדרת האימות מנוהלת באופן מרכזי על ידי Google Cloud.

   • מגדירים כל אשכול בנפרד לפי ההוראות במאמר הגדרת אשכולות ל-GKE Identity Service באמצעות OIDC.

3. מגדירים גישת משתמשים לאשכולות, כולל בקרת גישה מבוססת-תפקידים (RBAC), לפי ההוראות במאמר הגדרת גישת משתמשים ל-GKE Identity Service.

LDAP

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

גישה לאשכולות

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

• (מומלץ) במאמר גישה לאשכולות באמצעות GKE Identity Service מוסבר איך להיכנס לאשכולות רשומים באמצעות מזהה OIDC או LDAP.

• איך עובדים עם אשכולות מ-Google Cloud Console (OIDC בלבד) Google Cloud

פתרון בעיות בתהליך הכניסה

כדי לפתור בעיות בתהליכי כניסה שמאמתים ישירות בשרת GKE Identity Service באמצעות שם דומיין מוגדר במלואו (FQDN), אפשר להשתמש בכלי האבחון של GKE Identity Service. כלי האבחון מדמה תהליכי כניסה עם ספק OIDC כדי לזהות במהירות בעיות בהגדרות. הכלי הזה דורש אשכול בגרסה 1.32 ומעלה, והוא תומך רק ב-OIDC. מידע נוסף זמין במאמר כלי האבחון של GKE Identity Service.