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

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

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

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

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

• 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, משתמשים של צד שלישי מיוצגים על ידי חשבון ראשי (principal) של ניהול זהויות והרשאות גישה (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 .

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

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

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

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

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

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

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

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

gcloud init

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

מפעילים את Connect Gateway,‏ GKE Connect,‏ GKE Hub,‏ Anthos Identity Service ו-Cloud Resource Manager APIs:

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

כדי להפעיל ממשקי API, נדרשת ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק Service Usage' (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

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

מפעילים את Connect Gateway,‏ GKE Connect,‏ GKE Hub,‏ Anthos Identity Service ו-Cloud Resource Manager APIs:

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

כדי להפעיל ממשקי API, נדרשת ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק Service Usage' (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. בודקים אם יש לכם מדיניות רשת שמחייבת שתעבורת היציאה מהאשכול תעבור דרך שרת proxy.

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

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

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

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

כדי לוודא שיש מאגר זהויות של כוח עבודה וספק זהויות שהוגדרו עבור הארגון שלכם ב- 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 של האשכול.

אם האשכול או הצי שלכם כבר מוגדרים לתמיכה בקבוצות 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 הזה.

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

המסוף

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 דרך שרת 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. לדוגמה: http://user:password@10.10.10.10:8888

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

   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. לדוגמה: http://user:password@10.10.10.10:8888

הענקת תפקידי IAM למשתמשים ולקבוצות של צד שלישי

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

• ‫roles/gkehub.gatewayAdmin. התפקיד הזה מאפשר למשתמשים לגשת ל-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 כחלק מאוטומציית DevOps.