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

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

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

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

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

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

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

איך זה עובד

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

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

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

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

דיאגרמה שמציגה את התהליך של שער קבוצות Google

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

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

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

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

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

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

    gcloud init

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

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

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

    כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים 

    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. מפעילים את Connect Gateway,‏ GKE Connect,‏ GKE Hub,‏ Anthos Identity Service ו-Cloud Resource Manager APIs:

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

    כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים 

    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. בודקים אם יש לכם מדיניות רשת שמחייבת שתעבורת נתונים יוצאת מהאשכול תעבור דרך שרת proxy.

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

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

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

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

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

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

כדי שקבוצות יוכלו ליצור אינטראקציה עם אשכולות מקושרים דרך השער, הן צריכות את התפקידים הנוספים הבאים 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.

מה השלב הבא?