שימוש בספקי זהויות חיצוניים לאימות ב-GKE

טייס אוטומטי רגילה

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

הדף הזה מיועד לאדמינים ולמפעילים של פלטפורמות ולאדמינים של זהויות וחשבונות שמשתמשים בספק זהויות (IdP) חיצוני שתומך ב-OpenID Connect ‏(OIDC) או ב-Security Assertion Markup Language ‏(SAML) 2.0.

לפני שקוראים את הדף הזה, חשוב לוודא שמכירים את המושגים הבאים שקשורים לאימות ול-OpenID:

• OAuth 2.0
• SAML 2.0
• OpenID Connect
• היקפים וטענות של OIDC
• Kubernetes RBAC

שיטות אימות של ספקי IdP חיצוניים ב-GKE

מומלץ – איחוד שירותי אימות הזהות של כוח עבודה

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

לא מומלץ – Identity Service ל-GKE

באשכולות GKE Standard בלבד, GKE תומך גם ב-Identity Service for GKE. שירות הזהויות ל-GKE מוגבל לספקי זהויות שתומכים ב-OIDC, והוא מתקין רכיבים נוספים באשכול. מומלץ מאוד להשתמש ב-Workforce Identity Federation ב-GKE במקום ב-Identity Service for GKE. חשוב גם לשים לב למגבלה ידועה ב-Identity Service for GKE שמונעת התאמה אוטומטית לעומס.

שימו לב: החל מ-1 ביולי 2025, לא תהיה תמיכה בשירות הזהות ל-GKE ב Google Cloud ארגונים חדשים שתיצרו.

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

לפני שמתחילים, חשוב לוודא שביצעתם את הפעולות הבאות:

• מפעילים את ממשק Google Kubernetes Engine API.
הפעלת Google Kubernetes Engine API
• כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את gcloud CLI. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
  הערה: אם כבר התקנתם את ה-CLI של gcloud, הקפידו להגדיר את compute/region המאפיין. אם אתם משתמשים בעיקר באשכולות אזוריים, עליכם להגדיר את compute/zone במקום זאת. אם מגדירים מיקום ברירת מחדל, אפשר להימנע משגיאות ב-CLI של gcloud כמו השגיאה הבאה: One of [--zone, --region] must be supplied: Please specify location. יכול להיות שתצטרכו לציין את המיקום בפקודות מסוימות אם המיקום של האשכול שונה מברירת המחדל שהגדרתם.

לתשומת ליבכם

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

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

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

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

3. מגדירים את גישת המשתמשים באמצעות אחד ממנגנוני ההרשאה הבאים:

   • Kubernetes RBAC
   • מדיניות הרשאות ב-IAM

4. כדי שהמשתמשים יוכלו לגשת לאשכולות, הם צריכים לפעול לפי השלבים הבאים:

   1. כניסה ל-CLI של gcloud באמצעות הזהות המאוחדת
   2. מגדירים את kubectl לאימות לאשכול ספציפי באמצעות הפקודה gcloud container clusters get-credentials.

הגדרת גישת משתמשים לאשכולות באמצעות RBAC

‫Google Cloud משתמש במזהים של חשבונות משתמשים (principal identifiers) כדי לזהות משתמשים במאגרי הזהויות של כוח העבודה. אפשר להפנות למזהי החשבונות הראשיים האלה במדיניות RBAC של Kubernetes או במדיניות IAM, כדי להעניק הרשאות לאנשים פרטיים או לקבוצות של משתמשים. עם RBAC, אי אפשר להפנות לטענות מותאמות אישית אחרות שאסימוני ה-IdP מכילים. ב-RBAC יש תמיכה במזהי ישויות רק למשתמשים ולקבוצות.

בטבלה הבאה מפורטים מזהי חשבונות ראשיים לדוגמה של משתמשים בודדים ושל קבוצות:

זהות	מזהה של חשבון משתמש
משתמש יחיד	principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_IDENTITY_POOL/subject/SUBJECT_ATTRIBUTE_VALUE מחליפים את מה שכתוב בשדות הבאים: ‫WORKFORCE_IDENTITY_POOL: השם של מאגר הזהויות של כוח העבודה. SUBJECT_ATTRIBUTE_VALUE: הערך של מאפיין בהצהרת הנושא של אסימון הזהות. לדוגמה, יכול להיות שזה הערך של השדה NameID בטענת נכוֹנוּת (assertion) של SAML 2.0. לדוגמה: principal://iam.googleapis.com/locations/global/workforcePools/full-time-employees/subject/[e-mail]
כל המשתמשים בקבוצה	principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_IDENTITY_POOL/group/GROUP_NAME מחליפים את מה שכתוב בשדות הבאים: ‫WORKFORCE_IDENTITY_POOL: השם של מאגר הזהויות של כוח העבודה. ‫GROUP_NAME: השם של קבוצה שהמשתמש שמבצע את האימות חבר בה. באסימון ה-IdP צריך להיות מיפוי מאפיינים למאפיין Google Cloud google.groups. לדוגמה: principalSet://iam.googleapis.com/locations/global/workforcePools/full-time-employees/group/sre

לכל מזהה חשבון משתמש שאיחוד שירותי אימות הזהות של כוח העבודה תומך בו, אפשר לעיין במאמר ייצוג משתמשים במאגר זהויות של כוח עבודה ב-IAM.

בדוגמה הבאה מוצג איך לתת גישת קריאה בלבד ל-Secrets בכל האשכול לכל ישות במאגר כוח העבודה full-time-employees ששייכת לקבוצה sre באסימון ספק הזהויות שלה.

1. שומרים את מניפסט ה-ClusterRole הבא בשם secret-viewer-cluster-role.yaml:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: secret-viewer
   rules:
   - apiGroups: [""]
     resources: ["secrets"]
     verbs: ["get", "watch", "list"]
   

   כל גורם שקושרים אליו את ה-ClusterRole הזה יכול לראות את הסודות.

2. שומרים את מניפסט ה-ClusterRoleBinding הבא בשם secret-viewer-cluster-role-binding.yaml:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name:  users-view-secrets
   subjects:
   - kind: Group
     name: principalSet://iam.googleapis.com/locations/global/workforcePools/full-time-employees/group/sre
     apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: ClusterRole
     name: secret-viewer
     apiGroup: rbac.authorization.k8s.io
   

   ה-ClusterRoleBinding הזה מעניק את ה-ClusterRole‏ secret-viewer לכל משתמש ששייך לקבוצה sre.

3. פריסת ClusterRole ו-ClusterRoleBinding:

   kubectl apply -f secret-viewer-cluster-role.yaml
   kubectl apply -f secret-viewer-cluster-role-binding.yaml
   

כניסה ואימות לאשכול

1. מבקשים מהמשתמש להיכנס באמצעות Google Cloud CLI.

2. המשתמש יכול להגדיר את kubectl כדי לבצע אימות לאשכול באמצעות:

   gcloud container clusters get-credentials
   

העברת Identity Service לאשכולות GKE אל איחוד שירותי אימות הזהות של כוח העבודה

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

תחביר של Identity Service for GKE	תחביר של איחוד שירותי אימות הזהות של כוח העבודה
[e-mail]	principal://iam.googleapis.com/locations/global/workforcePools/full-time-employees/subject/[e-mail]
sre-group	principalSet://iam.googleapis.com/locations/global/workforcePools/full-time-employees/group/sre-group

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

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

2. מעדכנים את קובצי המניפסט של כל RoleBinding ו-ClusterRoleBinding באשכולות כדי להשתמש בתחביר של מזהה איחוד שירותי אימות הזהות של כוח העבודה. אפשר לבחור באחת מהאפשרויות הבאות:

   • עדכונים פרוגרמטיים: מתקינים ומריצים את כלי השירות gke-identity-service-migrator. הוראות מפורטות מופיעות בקובץ README של מאגר GoogleCloudPlatform/gke-utilities.

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

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

3. מחילים את המניפסטים המעודכנים של RoleBindings ו-ClusterRoleBindings על האשכול.

4. בודקים שהמשתמשים יכולים לגשת לאותם משאבים כשהם מבצעים אימות באמצעות איחוד שירותי אימות הזהות של כוח העבודה.

5. מסירים את הקישורים המיושנים של RBAC מהאשכול.

6. השבתה של Identity Service ל-GKE

שימוש ב-Identity Service ל-GKE

שימו לב: החל מ-1 ביולי 2025, לא תהיה תמיכה בשירות הזהות ל-GKE ב Google Cloud ארגונים חדשים שתיצרו.

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

1. הפעלת שירות הזהויות ל-GKE באשכול.
2. הגדרת Identity Service ל-GKE
3. יצירת מדיניות RBAC לאשכול

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

אובייקטים של Kubernetes שנוצרו על ידי Identity Service for GKE

בטבלה הבאה מפורטים אובייקטים של Kubernetes שנוצרים כשמפעילים את שירות הזהויות ל-GKE באשכול:

אובייקטים של Kubernetes
anthos-identity-service	‫Namespace משמש לשירות הזהויות לפריסות GKE.
kube-public	Namespace משמש לקובץ ההגדרות של לקוח default.
gke-oidc-envoy	LoadBalancer נקודת הקצה (endpoint) לבקשות OIDC. חיצוני כברירת מחדל. אם נוצר באשכול ללא נקודת קצה חיצונית של כתובת IP, נקודת הקצה היא פנימית לענן הווירטואלי הפרטי של האשכול. נוצר במרחב השמות anthos-identity-service.
gke-oidc-service	ClusterIP מתווך בתקשורת בין gke-oidc-envoy הפריסה לבין פריסת gke-oidc-service. נוצר במרחב השמות anthos-identity-service.
gke-oidc-envoy	Deployment מפעיל שרת proxy שחשוף ל-gke-oidc-envoy LoadBalancer. מתקשר עם gke-oidc-service כדי לאמת אסימוני זהות. פועל כשרת proxy לשרת ה-API של Kubernetes, ומתחזה למשתמשים כשמעביר בקשות לשרת ה-API. נוצר במרחב השמות anthos-identity-service.
gke-oidc-service	‫Deployment מאמת אסימוני זהות ומספק webhook לאימות כניסה למשאבי ClientConfig. נוצר במרחב השמות anthos-identity-service.
gke-oidc-operator	Deployment מבצע התאמה בין הגדרות הלקוח לבין gke-oidc-envoy LoadBalancer. נוצר במרחב השמות anthos-identity-service.
gke-oidc-certs	Secret מכיל את רשות האישורים (CA) של האשכול ואת אישורי ה-TLS של מאזן העומסים. נוצר במרחב השמות anthos-identity-service
default	‫ClientConfig CRD מכיל פרמטרים של OIDC כמו שיטת האימות המועדפת, הגדרת ספק הזהויות ומיפויים של טענות לגבי משתמשים וקבוצות. משמש לאימות של טוקן הזהות. משמש אדמינים של אשכולות להגדרת OIDC לפני הפצה למפתחים. נוצר במרחב השמות kube-public

הפעלת שירות הזהויות ל-GKE באשכול

כברירת מחדל, ניהול הזהויות והרשאות הגישה (IAM) מוגדר כספק הזהויות לאימות של אשכולות. אם רוצים להשתמש ב-OIDC עם ספקי זהויות של צד שלישי, אפשר להפעיל את Identity Service ל-GKE באשכולות חדשים או קיימים באמצעות Google Cloud CLI.

הערה: כדי ש-Identity Service for GKE יפעל בצורה תקינה, GKE פורס Pods בצמתים עם הרשאות RBAC מורחבות, כמו היכולת להתחזות למשתמשים ולקבוצות. ההרשאות האלה נדרשות כדי ש-Identity Service for GKE יוכל לאמת את הזהות ולתקשר על סמך ההגדרה שלכם.

הפעלת שירות הזהויות ל-GKE באשכול חדש

כדי ליצור אשכול עם Identity Service for GKE מופעל, מריצים את הפקודה הבאה:

gcloud container clusters create CLUSTER_NAME \
    --enable-identity-service

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

הפעלת Identity Service for GKE באשכול קיים

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

gcloud container clusters update CLUSTER_NAME \
    --enable-identity-service

מחליפים את CLUSTER_NAME בשם האשכול.

הגדרת Identity Service ל-GKE

כדי להגדיר פרמטרים של שירות הזהויות ל-GKE, צריך להוריד ולשנות את default ClientConfig.

1. מורידים את הקובץ default ClientConfig:

   kubectl get clientconfig default -n kube-public -o yaml > client-config.yaml
   

2. מעדכנים את הקטע spec.authentication עם ההגדרות המועדפות:

   apiVersion: authentication.gke.io/v2alpha1
   kind: ClientConfig
   metadata:
     name: default
     namespace: kube-public
   spec:
     name: cluster-name
     server: https://192.168.0.1:6443
     authentication:
     - name: oidc
       oidc:
         clientID: CLIENT_ID
         certificateAuthorityData: OIDC_PROVIDER_CERTIFICATE
         extraParams: EXTRA_PARAMS
         issuerURI:  ISSUER_URI
         cloudConsoleRedirectURI: https://console.cloud.google.com/kubernetes/oidc
         kubectlRedirectURI: KUBECTL_REDIRECT_URL
         scopes: SCOPES
         userClaim: USER
         groupsClaim: GROUPS
         userPrefix: USER_PREFIX
         groupPrefix: GROUP_PREFIX
   

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

   • ‫CLIENT_ID: המזהה של אפליקציית הלקוח ששולחת בקשות אימות לספק OIDC.
   • ‫OIDC_PROVIDER_CERTIFICATE: (אופציונלי) אישור PEM לספק OIDC. השדה הזה יכול להיות שימושי אם ספק ה-OIDC שלכם משתמש באישורים בחתימה עצמית. שירות הזהויות ל-GKE כולל קבוצה של שורשים ציבוריים כברירת מחדל.
   • ‫EXTRA_PARAMS: פרמטרים נוספים של מפתח/ערך לשליחה לספק OIDC.
     • כדי לתת הרשאה לקבוצות, משתמשים בפונקציה resource=token-groups-claim.
     • כדי לאמת את Microsoft Azure ואת Okta, משתמשים ב-prompt=consent.
     • ב-Cloud Identity, משתמשים ב-prompt=consent,access_type=offline.
   • ‫ISSUER_URI: כתובת ה-URL לשליחת בקשות הרשאה של OIDC, כמו https://example.com/adfs. שרת ה-API של Kubernetes משתמש בכתובת ה-URL הזו כדי לגלות מפתחות ציבוריים לאימות אסימונים. חובה להשתמש ב-HTTPS ב-URI. ב-Cloud Identity, משתמשים ב-https://accounts.google.com.
   • ‫KUBECTL_REDIRECT_URL: כתובת ה-URL להפניה אוטומטית שמשמשת את kubectl oidc login לאישור. בדרך כלל הפורמט הוא http://localhost:PORT/callback, כאשר PORT הוא כל יציאה שגדולה מ-1024 שתהיה זמינה בתחנות עבודה של מפתחים, למשל http://localhost:10000/callback. צריך לרשום את כתובת ה-URL אצל ספק OIDC ככתובת URL מורשית להפניה אוטומטית לאפליקציית הלקוח. אם אתם משתמשים ב-Google Identity כספק OIDC, תוכלו לקרוא את ההוראות במאמר בנושא הגדרת URI להפניה אוטומטית.
   • ‫SCOPES: היקפי ההרשאות הנוספים לשליחה לספק OIDC.
     • ב-Microsoft Azure וב-Okta נדרשת הרשאה offline_access.
     • ב-Cloud Identity, משתמשים ב-openid, email כדי לקבל אסימוני מזהה שמכילים את כתובת האימייל בטענה email.
   • ‫USER: טענת המשתמש מאסימון הזהות.
   • ‫GROUPS: הצהרת הקבוצה מאסימון הזהות.
   • ‫USER_PREFIX: קידומת שמוספת לתביעות של משתמשים כדי למנוע התנגשויות עם שמות קיימים. כברירת מחדל, תחילית של מנפיק מצורפת ל-userID שמועבר לשרת Kubernetes API (אלא אם טענת המשתמש היא email). מזהה המשתמש שמתקבל הוא ISSUER_URI#USER. מומלץ להשתמש בקידומת, אבל אפשר להשבית את הקידומת על ידי הגדרת USER_PREFIX ל--.
   • ‫GROUP_PREFIX: קידומת שנוספת לפני הצהרות של קבוצות כדי למנוע התנגשויות עם שמות קיימים. לדוגמה, אם יש לכם שתי קבוצות בשם foobar, מוסיפים את הקידומת gid-. הקבוצה שתתקבל היא gid-foobar.

3. החלת ההגדרות המעודכנות:

   kubectl apply -f client-config.yaml
   

   אחרי שמחילים את ההגדרה הזו, Identity Service for GKE פועל בתוך האשכול וממלא בקשות מאחורי איזון העומסים gke-oidc-envoy. כתובת ה-IP בשדה spec.server צריכה להיות כתובת ה-IP של מאזן העומסים. אם משנים את השדה spec.server, יכול להיות שהפקודות kubectl ייכשלו.

4. יוצרים עותק של קובץ ההגדרות client-config.yaml:

   cp client-config.yaml login-config.yaml
   

5. מעדכנים את קובץ התצורה login-config.yaml עם ההגדרה clientSecret בקטע spec.authentication.oidc.

   clientSecret: CLIENT_SECRET
   

   מחליפים את CLIENT_SECRET בסוד המשותף בין אפליקציית הלקוח של OIDC לבין ספק OIDC.

6. מפיצים את קובץ login-config.yaml המעודכן למפתחים.

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

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

1. מוסיפים כלל לחומת האש ליציאת TCP‏ 15000 כדי לאפשר למישור הבקרה לתקשר עם ה-webhook של האימות ClientConfig.
2. אם gke-oidc-envoy נוצר כמאזן עומסים פנימי, צריך לחשוף אותו ב-VPC.
3. אם יש לכם מדיניות שחוסמת תעבורה בתוך האשכול, צריך להוסיף כלל חומת אש ליציאת TCP 8443 כדי לאפשר לפריסת gke-oidc-envoy לתקשר עם פריסת gke-oidc-service.

גרסה 0.2.20 ואילך של רכיב Identity Service for GKE לא משתמשת ביציאת TCP‏ 15000. אם גרסת הרכיב היא 0.2.20 או גרסה מתקדמת יותר, לא צריך להוסיף כלל חומת אש ליציאה 15000. כדי לבדוק את גרסת הרכיב, מריצים את הפקודה הבאה:

kubectl describe deployment gke-oidc-envoy -n anthos-identity-service \
    | grep "components.gke.io/component-name: gke-oidc" -A1

הוספת מאפיינים מותאמים אישית למאזן העומסים

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

kubectl edit service gke-oidc-envoy -n anthos-identity-service

מידע נוסף על הגדרת איזון עומסים ב-TCP/UDP ב-GKE זמין במאמר פרמטרים של שירות LoadBalancer.

יצירת מדיניות RBAC לאשכול

אדמינים יכולים להשתמש בבקרת גישה מבוססת-תפקידים (RBAC) ב-Kubernetes כדי להעניק גישה למשתמשים מאומתים באשכול. כדי להגדיר RBAC עבור האשכול, צריך להקצות תפקידי RBAC לכל מפתח. כדי להעניק גישה למשאבים במרחב שמות מסוים, יוצרים תפקיד וRoleBinding. כדי להעניק גישה למשאבים בכל האשכול, צריך ליצור ClusterRole ו-ClusterRoleBinding.

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

1. שומרים את מניפסט ClusterRole הבא בשם secret-viewer-cluster-role.yaml. אדם שמקבל את התפקיד הזה יכול לקבל, לצפות ולרשום כל סוד באשכול.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: secret-viewer
   rules:
   - apiGroups: [""]
     # The resource type for which access is granted
     resources: ["secrets"]
     # The permissions granted by the ClusterRole
     verbs: ["get", "watch", "list"]
   

2. מחילים את מניפסט ClusterRole:

   kubectl apply -f secret-viewer-cluster-role.yaml
   

3. שומרים את המניפסט הבא של ClusterRoleBinding בשם secret-viewer-cluster-role-binding.yaml. הקישור מעניק את התפקיד secret-viewer לשם משתמש שמוגדר בקובץ התצורה של הלקוח.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name:  people-who-view-secrets
   subjects:
   - kind: User
     name: ISSUER_URI#USER
     apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: ClusterRole
     name: secret-viewer
     apiGroup: rbac.authorization.k8s.io
   

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

   • ‫ISSUER_URI: ה-URI של המנפיק מ-spec.authentication.oidc.issuerURI בקובץ התצורה של הלקוח.
   • ‫USER: מזהה המשתמש בטוקן, בשם הטענה שהוגדר ב-spec.authentication.oidc.userClaim בקובץ ההגדרות של הלקוח.

4. מחילים את מניפסט ClusterRoleBinding:

   kubectl apply -f secret-viewer-cluster-role-binding.yaml
   

כניסה ואימות לאשכול

מפתחים שמקבלים את קובץ ההגדרות של OIDC מהאדמין יכולים לבצע אימות לאשכולות שלהם.

1. מורידים את הקובץ login-config.yaml שקיבלתם מהאדמין.

2. מתקינים את ה-SDK של Google Cloud CLI, שכולל רכיב OIDC נפרד. כדי להתקין אותו, מריצים את הפקודה הבאה:

   gcloud components install kubectl-oidc
   

3. אימות לאשכול:

   kubectl oidc login --cluster=CLUSTER_NAME --login-config=login-config.yaml
   

   ייפתח דפדפן אינטרנט כדי להשלים את תהליך האימות.

4. אחרי האימות, אפשר להריץ פקודות של kubectl, לדוגמה:

   kubectl get pods
   

השבתה של Identity Service ל-GKE

אפשר להשבית את שירות הזהויות ל-GKE באמצעות ה-CLI של gcloud. כדי להשבית את שירות הזהויות ל-GKE, מריצים את הפקודה הבאה:

gcloud container clusters update CLUSTER_NAME \
    --no-enable-identity-service

מגבלות ידועות

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

אי אפשר לשנות את גודל הפריסה של gke-oidc-envoy באופן ישיר. מומלץ מאוד לעבור לאיחוד שירותי אימות הזהות של כוח עבודה כדי לקבל פתרון חזק יותר וניתן להרחבה.

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

• מידע נוסף על איחוד שירותי אימות הזהות של כוח עבודה
• מידע נוסף על פריסת עומסי עבודה