הגדרת Connect gateway באמצעות קבוצות Google

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

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

התכונה הזו משתמשת בקבוצות Google שמשויכות ל-Google Workspace או למהדורה כלשהי של Cloud Identity.

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

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

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

איך זה עובד

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

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

  1. המשתמש alice@example.com נכלל כחבר בקבוצה.

  2. היא קבוצה בתוך קבוצה של gke-security-groups@example.com.

תרשים שמציג את התהליך של שער Google Groups

  1. המשתמש alice@example.com מתחבר באמצעות Google Identity, ואם הוא מתכנן להשתמש באשכול משורת הפקודה, הוא מקבל את השער של האשכול kubeconfig כמו שמתואר במאמר שימוש בשער החיבור.
  2. המשתמש שולח בקשה על ידי הפעלת פקודת kubectl או פתיחת הדפים Workloads או חלונית האובייקטים של Google Kubernetes Engine במסוףGoogle Cloud .
  3. הבקשה מתקבלת על ידי שירות Connect, שמבצע בדיקת הרשאה באמצעות IAM.
  4. שירות Connect מעביר את הבקשה לסוכן Connect שפועל באשכול. הבקשה מלווה בפרטי הכניסה של המשתמש לצורך אימות והרשאה באשכול.
  5. סוכן Connect מעביר את הבקשה לשרת ה-API של Kubernetes.
  6. שרת ה-API של Kubernetes מעביר את הבקשה לפוד של anthos-identity-service באשכול, שמאמת את הבקשה.
  7. ה-Pod של anthos-identity-service מחזיר את פרטי המשתמש והקבוצה לשרת ה-API של Kubernetes. לאחר מכן, שרת ה-API של Kubernetes יכול להשתמש במידע הזה כדי לאשר את הבקשה על סמך מדיניות ה-RBAC שהוגדרה באשכול.

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

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

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

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

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

    gcloud init

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

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

    תפקידים שנדרשים להפעלת ממשקי 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

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

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

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

    gcloud init

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

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

    תפקידים שנדרשים להפעלת ממשקי 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
    12.
  12. במקרה של אשכולות מחוץ ל- Google Cloud, רכיבי האימות באשכול צריכים לקרוא ל-Cloud Identity API. בודקים אם יש לכם מדיניות רשת ב-Kubernetes שמחייבת שתעבורת נתונים יוצאת (egress) מהאשכול תעבור דרך שרת proxy.

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

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

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

הגדרת משתמשים וקבוצות

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

  1. צריך לוודא שיש קבוצה ב-Google Workspace של הארגון בפורמט gke-security-groups@YOUR-DOMAIN. אם אין לכם קבוצה כזו, אתם יכולים ליצור אותה באמצעות מסוף Google Admin לפי ההוראות במאמר יצירת קבוצה בארגון.
  2. פועלים לפי ההוראות במאמר איך מוסיפים קבוצה לקבוצה אחרת כדי להוסיף את הקבוצות שרוצים להשתמש בהן לבקרת גישה כקבוצות משנה של gke-security-groups. אל תוסיפו משתמשים בנפרד כחברים ב-gke-security-groups.

בחשבונות המשתמשים שבהם רוצים להשתמש בתכונה הזו צריך להיות אותו שם דומיין כמו בקבוצה.

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

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

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

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

  • ‫Distributed Cloud במודל מחובר: אשכולות נפרדים בלבד. אין תמיכה בהגדרה ברמת הצי.
  • ‫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.

אחרי שמגדירים תמיכה בקבוצות ברמת ה-fleet, בקר ה-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 Identity דרך שרת 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

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

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

כדי להקצות את התפקידים האלה, משתמשים בפקודה gcloud projects add-iam-policy-binding באופן הבא:

gcloud projects add-iam-policy-binding --member=group:GROUP_NAME@DOMAIN --role=GATEWAY_ROLE PROJECT_ID
gcloud projects add-iam-policy-binding --member=group:GROUP_NAME@DOMAIN --role=roles/gkehub.viewer PROJECT_ID

איפה

  • ‫GROUP_NAME היא קבוצת Google שרוצים להקצות לה את התפקיד
  • ‫DOMAIN הוא הדומיין שלכם ב-Google Workspace
  • ‫GROUP_NAME@DOMAIN היא קבוצה בתוך קבוצה, מתחת ל-gke-security-groups@DOMAIN
  • ‫GATEWAY_ROLE הוא אחד מהערכים roles/gkehub.gatewayAdmin, roles/gkehub.gatewayReader או gkehub.gatewayEditor.
  • ‫PROJECT_ID הוא הפרויקט

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

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

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

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

cat <<EOF > /tmp/admin-permission.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gateway-cluster-admin-group
subjects:
- kind: Group
  name: cluster-admin-team@example.com
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.

מה השלב הבא?