הגדרת Connect gateway עם זהויות של צד שלישי

המדריך הזה מיועד לאדמינים של פלטפורמות שצריכים להגדיר את שער החיבור בפרויקט שמכיל משתמשים שאין להם Google Identity והם לא שייכים ל-Google Workspace. במדריך הזה, הזהויות האלה נקראות 'זהויות של צד שלישי'. לפני שתקראו את המדריך הזה, כדאי שתכירו את המושגים שמופיעים בסקירה הכללית על שער Connect. כדי לאשר חשבונות Google ספציפיים, קראו את המאמר הגדרת שער הקישור. לקבלת תמיכה בנושא קבוצות Google, אפשר לעיין במאמר בנושא הגדרת שער החיבור באמצעות קבוצות Google.

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

סוגי אשכולות נתמכים

אתם יכולים להגדיר בקרת גישה עם זהויות של צד שלישי באמצעות שער הקישור, לסוגי האשכולות הבאים:

• GKE on Google Cloud: כל הגרסאות הזמינות. כדי להגדיר את שער הקישור, מגדירים את קבוצות Google ל-RBAC ואז מקצים תפקידי IAM לקבוצות Google.
• ‫Google Distributed Cloud (תוכנה בלבד) ב-VMware ובשרת פיזי: כל הגרסאות הזמינות.
• ‫Google Distributed Cloud במודל מחובר: כל הגרסאות הזמינות.
• אשכולות GKE מצורפים: גרסה ‎1.28.0-gke.2 ואילך.

• ‫GKE ב-AWS ו-GKE ב-Azure: כל הגרסאות הזמינות.

  אזהרה: הוצאנו משימוש את GKE ב-AWS ואת GKE ב-Azure. מידע נוסף זמין בהודעה על הוצאה משימוש של GKE ב-AWS ובהודעה על הוצאה משימוש של GKE ב-Azure.

כדי להשתמש בתכונה הזו בסביבות שלא מופיעות ברשימה שלמעלה, פנו אל Cloud Customer Care או אל צוות שער הקישור.

איך זה עובד

כמו שמתואר בסקירה הכללית, יכול להיות שהמשתמשים משתמשים בספקי זהויות שהם לא Google Workspace או Cloud Identity. באמצעות איחוד שירותי אימות הזהות של כוח העבודה, המשתמשים יכולים להשתמש בספקי זהויות של צד שלישי, כמו Okta או Azure Active Directory, כדי לקבל גישה לאשכולות שלהם דרך שער הקישור. בניגוד לחשבונות Google, משתמשים של צד שלישי מיוצגים על ידי חשבון משתמש לניהול זהויות והרשאות גישה (IAM) בפורמט הבא:

principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/subject/SUBJECT_VALUE

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

• ‫SUBJECT_VALUE הוא המיפוי של הזהות של הצד השלישי לנושא ב-Google.

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

principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP_VALUE

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

למשתמשים פרטיים, צריכה להיות באשכול מדיניות RBAC שמשתמשת בשם המלא של חשבון המשתמש ב-IAM.

אם משתמשים בפונקציונליות של קבוצות, צריכה להיות באשכול מדיניות RBAC שמשתמשת בשם המלא של משתמש ה-IAM בשביל קבוצה ש:

1. מכילה את המשתמש [e-mail] כחבר קבוצה.

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

הערה: כדי שהפונקציונליות של קבוצות של צד שלישי תפעל באשכולות של חברי צי מחוץ ל- Google Cloud, צריך להגדיר אימות מזהויות של צד שלישי.

1. המשתמש [e-mail] נכנס ל-CLI של gcloud באמצעות הזהות שלו מצד שלישי, באמצעות כניסה מבוססת-דפדפן מצד שלישי. כדי להשתמש באשכול משורת הפקודה, המשתמש מקבל את שער האשכול kubeconfig כמו שמתואר במאמר שימוש בשער החיבור.
2. המשתמש שולח בקשה על ידי הפעלת פקודה kubectl או פתיחת הדפים עומסי עבודה או חלונית האובייקטים ב-Google Kubernetes Engine במסוף Google Cloud .
3. הבקשה מתקבלת על ידי Connect Gateway, שמטפל באימות של צד שלישי באמצעות איחוד שירותי אימות הזהות של כוח העבודה.
4. שער הקישור מבצע בדיקת הרשאה באמצעות IAM.
5. שירות Connect מעביר את הבקשה לסוכן Connect שפועל באשכול. הבקשה מלווה בפרטי הכניסה של המשתמש, שמשמשים לאימות ולהרשאה באשכול.
6. הסוכן של Connect מעביר את הבקשה לשרת ה-API של Kubernetes.
7. שרת ה-API של Kubernetes מעביר את הבקשה לרכיב של שירות הזהויות באשכול, שמאמת את הבקשה.
8. רכיב שירות הזהויות מחזיר את פרטי המשתמשים והקבוצות של הצד השלישי לשרת ה-API של Kubernetes. שרת ה-API של Kubernetes יכול להשתמש במידע הזה כדי לאשר את הבקשה על סמך מדיניות ה-RBAC שהוגדרה באשכול.

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

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

התקינו את ה-CLI של Google Cloud.

הערה: אם התקנתם את ה-CLI של gcloud, השתמשו בפקודה gcloud components update כדי לבדוק אם הגרסה העדכנית מותקנת.

אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

כדי לאתחל את ה-CLI של gcloud, הריצו את הפקודה הבאה:

gcloud init

מוודאים שיש את ההרשאות הנדרשות כדי להשלים את ההדרכה.

מפעילים את ממשקי ה-API הבאים, אם הם עדיין לא מופעלים: Connect Gateway,‏ GKE Connect,‏ GKE Hub,‏ Anthos Identity Service ו-Cloud Resource Manager.

תפקידים שנדרשים להפעלת ממשקי API

כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד "בעלים" (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד "אדמין בממשק 'שימוש בשירות'" (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

gcloud services enable connectgateway.googleapis.com gkeconnect.googleapis.com gkehub.googleapis.com anthosidentityservice.googleapis.com cloudresourcemanager.googleapis.com

התקינו את ה-CLI של Google Cloud.

הערה: אם התקנתם את ה-CLI של gcloud, השתמשו בפקודה gcloud components update כדי לבדוק אם הגרסה העדכנית מותקנת.

אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

כדי לאתחל את ה-CLI של gcloud, הריצו את הפקודה הבאה:

gcloud init

מוודאים שיש את ההרשאות הנדרשות כדי להשלים את ההדרכה.

מפעילים את ממשקי ה-API הבאים, אם הם עדיין לא מופעלים: Connect Gateway,‏ GKE Connect,‏ GKE Hub,‏ Anthos Identity Service ו-Cloud Resource Manager.

תפקידים שנדרשים להפעלת ממשקי API

כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד "בעלים" (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד "אדמין בממשק 'שימוש בשירות'" (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

gcloud services enable connectgateway.googleapis.com gkeconnect.googleapis.com gkehub.googleapis.com anthosidentityservice.googleapis.com cloudresourcemanager.googleapis.com

1. במקרה של אשכולות מחוץ ל- Google Cloud, רכיבי האימות באשכול צריכים לקרוא ל-Cloud Identity API. בודקים אם יש לכם מדיניות רשת ב-Kubernetes שמחייבת שתעבורת נתונים יוצאת (egress) מהאשכול תעבור דרך שרת proxy.

התפקידים הנדרשים

כדי לקבל את ההרשאות שנדרשות להגדרת שער הקישור והאשכולות, צריך לבקש מהאדמין להקצות לכם את התפקיד עריכה (roles/editor) ב-IAM בפרויקט. כדי לקרוא הסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

יכול להיות שאפשר לקבל את ההרשאות הנדרשות גם באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש.

הגדרת מיפוי מאפייני זהות של צד שלישי באמצעות איחוד שירותי אימות הזהות של כוח העבודה

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

• ‫Azure AD
• ‫Okta
• עוד OIDC או SAML 2.0

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

הגדרת תמיכה בקבוצות

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

• ‫GKE on Google Cloud: מגדירים את קבוצות Google ל-RBAC, ואז מדלגים לקטע הקצאת תפקידי IAM לקבוצות.
• GKE attached clusters:
  • חיבור לאשכול המצורף של EKS
  • חיבור לאשכול המצורף של AKS
  • חיבור לסוגים אחרים של אשכולות

• ‫Google Distributed Cloud: כדי להפעיל תמיכה בקבוצות, צריך לעדכן את המשאב המותאם אישית ClientConfig באשכול. ‫Distributed Cloud יוצר באופן אוטומטי ClientConfig בשם default במרחב השמות kube-public בכל אשכול. כדי לוודא שהמשאב בהתאמה אישית קיים, מריצים את הפקודה הבאה:

  kubectl --kubeconfig CLUSTER_KUBECONFIG get ClientConfig default -n kube-public
  

  מחליפים את CLUSTER_KUBECONFIG בנתיב של קובץ ה-kubeconfig של האשכול.

אם האשכול או ה-fleet כבר מוגדרים לתמיכה בקבוצות Google, אין צורך לבצע שלבים נוספים ואפשר לדלג אל הקצאת תפקידי IAM למשתמשים ולקבוצות של צד שלישי.

בקטעים הבאים מוסבר איך לעדכן את המשאב המותאם אישית ClientConfig כדי להפעיל תמיכה בקבוצות. הקטעים האלה רלוונטיים רק לאשכולות של Google Distributed Cloud. בסוגים אחרים של אשכולות, כמו GKE ב-Google Cloud, ‏GKE ב-AWS ו-GKE ב-Azure, דלגו לקטע הקצאת תפקידי IAM לקבוצות.

ב-Distributed Cloud, אתם יכולים להגדיר תמיכה בקבוצות לאשכולות ספציפיים או ל-fleet. סוג האשכול שבו אתם משתמשים קובע את אופן ההגדרה של התמיכה בקבוצות, באופן הבא:

• Distributed Cloud connected: אשכולות נפרדים בלבד. אין תמיכה בהגדרה ברמת הצי.
• ‫Google Distributed Cloud (תוכנה בלבד) ב-VMware ובשרת פיזי: אשכולות או קבוצות אשכולות נפרדים.

הגדרת תמיכה בקבוצות באמצעות GKE Fleet API

ב-Google Distributed Cloud (תוכנה בלבד) ב-VMware ובשרת פיזי, אפשר להגדיר תמיכה בקבוצות ברמת ה-fleet. אם הגדרתם בעבר אימות ברמת הצי, למשל עבור ספק זהויות אחר, אימות קבוצתי כבר מופעל. עם זאת, אם מדיניות הרשת שלכם דורשת שתעבורת הנתונים היוצאת תעבור דרך שרת proxy, אתם צריכים לעדכן את ההגדרות הקיימות עם המידע על שרת ה-proxy הזה.

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

המסוף

1. נכנסים לדף GKE Identity Service במסוף Google Cloud .

   כניסה ל-GKE Identity Service

2. לוחצים על הפעלת שירות הזהויות.

3. בוחרים את Google Distributed Cloud (תוכנה בלבד) באשכולות VMware ושרתים פיזיים שרוצים להגדיר.

4. לוחצים על עדכון ההגדרה. החלונית Edit Identity Service Clusters Config תיפתח.

5. בקטע Configure Identity Providers, אפשר לבחור לשמור, להוסיף, לעדכן או להסיר ספק זהויות.

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

7. לוחצים על הפעלה כדי להפעיל את אימות Google עבור האשכולות שנבחרו. אם אתם צריכים לגשת ל-Google Identity דרך שרת Proxy, מזינים את פרטי ה-Proxy.

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

gcloud

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

2. בקובץ auth-config.yaml שמכיל את הגדרות ClientConfig, מוסיפים את השדה הבא:

   spec:
     authentication:
     - name: google-authentication-method
       google:
         disable: false
   

   הערך של false בשדה google.disable מאפשר תמיכה בקבוצות. כדי להשבית את התמיכה בקבוצות, משנים את הערך ל-true.

3. אופציונלי: אם אתם צריכים לגשת לספק הזהויות של Google דרך שרת proxy, מוסיפים את השדה proxy להגדרה הקודמת:

   spec:
     authentication:
     - name: google-authentication-method
       google:
         disable: false
       proxy: PROXY_URL
   

   מחליפים את PROXY_URL בכתובת של שרת ה-proxy שאליו רוצים להתחבר כדי לגשת ל-Google Identity. לדוגמה: http://user:password@10.10.10.10:8888

4. החלת ההגדרה על אשכול בצי:

   gcloud container fleet identity-service apply \
   --membership=CLUSTER_NAME \
   --config=/path/to/auth-config.yaml

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

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

הגדרת תמיכה בקבוצות לאשכולות ספציפיים

בכל האשכולות של Distributed Cloud, כולל Distributed Cloud במודל מחובר, צריך לעדכן את default ClientConfig בכל אשכול כדי להפעיל תמיכה בקבוצות:

1. כדי לקבל את פרטי המינוי של האשכול:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get memberships membership -o yaml
   

   מחליפים את הערך USER_CLUSTER_KUBECONFIG בנתיב לקובץ kubeconfig של האשכול. אם יש כמה הקשרים ב-kubeconfig, המערכת משתמשת בהקשר הנוכחי. יכול להיות שתצטרכו לאפס את ההקשר הנוכחי לאשכול הנכון לפני שתריצו את הפקודה.

   בתגובה, מעיינים בשדה spec.owner.id כדי לאחזר את פרטי החברות באשכול. מזהה החברות הוא בפורמט //gkehub.googleapis.com/projects/PROJECT_NUMBER/locations/global/memberships/MEMBERSHIP.

   הפלט אמור להיראות כך:

   id: //gkehub.googleapis.com/projects/123456789/locations/global/memberships/xy-ab12cd34ef
   

2. פותחים את default ClientConfig באשכול לעריכה:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-public edit clientconfig default
   

3. כדי להפעיל תמיכה בקבוצות, מוסיפים את השדה google לשדה spec.authentication:

   spec:
     internalServer: https://kubernetes.default.svc
     authentication:
     - google:
         audiences:
         - "CLUSTER_IDENTIFIER"
       name: google-authentication-method
   

   מחליפים את CLUSTER_IDENTIFIER בפרטי החברות של האשכול.

   מוודאים שהשדה internalServer מכיל את הערך https://kubernetes.default.svc.

4. אופציונלי: אם אתם צריכים לגשת לספק הזהויות של Google דרך שרת proxy, מוסיפים את השדה proxy להגדרה הקודמת:

   spec:
     internalServer: https://kubernetes.default.svc
     authentication:
     - google:
         audiences:
         - "CLUSTER_IDENTIFIER"
       name: google-authentication-method
       proxy: PROXY_URL
   

   מחליפים את PROXY_URL בכתובת של שרת ה-proxy שאליו רוצים להתחבר כדי לגשת ל-Google Identity. לדוגמה: http://user:password@10.10.10.10:8888

הקצאת תפקידים ב-IAM למשתמשים ולקבוצות מצד שלישי

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

• ‫roles/gkehub.gatewayAdmin. התפקיד הזה מאפשר למשתמשים לגשת ל-Connect Gateway API.
  • אם המשתמשים צריכים רק הרשאת קריאה בלבד לאשכולות המחוברים, אפשר להשתמש במקום זאת ב-roles/gkehub.gatewayReader.
  • אם המשתמשים צריכים גישת קריאה/כתיבה לאשכולות מקושרים, אפשר להשתמש ב-roles/gkehub.gatewayEditor במקום זאת.
• ‫roles/gkehub.viewer. התפקיד הזה מאפשר למשתמשים לראות את החברות הרשומות באשכול.

בהמשך מוסבר איך להוסיף את התפקידים הנדרשים לזהויות בודדות ולקבוצות ממופות:

זהויות בודדות

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

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=GATEWAY_ROLE \
    --member="principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/subject/SUBJECT_VALUE"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/gkehub.viewer \
    --member="principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/subject/SUBJECT_VALUE"

כאשר

• ‫PROJECT_ID: מזהה הפרויקט.
• ‫GATEWAY_ROLE הוא אחד מהערכים הבאים: roles/gkehub.gatewayAdmin, ‏ roles/gkehub.gatewayReader או gkehub.gatewayEditor.
• ‫WORKFORCE_POOL_ID: המזהה של מאגר הזהויות של כוח העבודה.
• ‫SUBJECT_VALUE: זהות המשתמש.

קבוצות

כדי להקצות את התפקידים הנדרשים לכל הזהויות בקבוצה ספציפית בפרויקט PROJECT_ID, מריצים את הפקודה הבאה:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=GATEWAY_ROLE \
    --member="principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP_ID"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/gkehub.viewer \
    --member="principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP_ID"

כאשר

• ‫PROJECT_ID: מזהה הפרויקט.
• ‫GATEWAY_ROLE הוא אחד מהערכים roles/gkehub.gatewayAdmin, roles/gkehub.gatewayReader או gkehub.gatewayEditor.
• ‫WORKFORCE_POOL_ID: מזהה המאגר של כוח העבודה.
• ‫GROUP_ID: קבוצה בהצהרה הממופה google.groups.

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

במאמר הענקה, שינוי וביטול גישה למשאבים תוכלו לקרוא מידע נוסף על הענקת הרשאות ותפקידים ב-IAM.

הגדרת כללי מדיניות של בקרת גישה מבוססת-תפקידים (RBAC)

לבסוף, שרת ה-API של Kubernetes בכל אשכול צריך להיות מסוגל לאשר פקודות kubectl שמגיעות דרך השער מהמשתמשים והקבוצות של צד שלישי שציינתם. לכל אשכול צריך להוסיף מדיניות הרשאות של RBAC שמציינת אילו הרשאות יש לנושא באשכול.

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

הנושאים במדיניות RBAC חייבים להשתמש באותו פורמט כמו הקישורים של IAM, כאשר משתמשים של צד שלישי מתחילים ב-principal://iam.googleapis.com/ וקבוצות של צד שלישי מתחילות ב-principalSet://iam.googleapis.com/. אם לא מוגדר באימות של האשכול זהויות חיצוניות של צד שלישי, תצטרכו מדיניות התחזות בנוסף לתפקידים או לתפקידים באשכול עבור משתמש צד שלישי. במקרה כזה, צריך לפעול לפי השלבים להגדרת RBAC ולהוסיף את הנציג של הצד השלישי שמתחיל ב-principal://iam.googleapis.com/ בתור המשתמש.

בדוגמה הבאה מוצגות הרשאות שניתנות לחברים בקבוצה של צד שלישי cluster-admin באשכול שבו מוגדר אימות מזהויות חיצוניות של צד שלישי. אחר כך אפשר לשמור את קובץ המדיניות כ-‎ /tmp/admin-permission.yaml ולהחיל אותו על האשכול שמשויך להקשר הנוכחי.

cat <<EOF > /tmp/admin-permission.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gateway-cluster-admin-group
subjects:
- kind: Group
  name: "principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP"
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
EOF
# Apply permission policy to the cluster.
kubectl apply --kubeconfig=KUBECONFIG_PATH -f /tmp/admin-permission.yaml

במאמר שימוש בהרשאות RBAC תוכלו לקרוא מידע נוסף על הגדרת הרשאות RBAC.

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

מה השלב הבא?

• איך משתמשים בשער Connect כדי להתחבר לאשכולות משורת הפקודה.
• במדריך שילוב עם Cloud Build יש דוגמה לשימוש ב-Connect gateway כחלק מאוטומציית DevOps.