הגדרת שער Connect

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

  • אפשר להשתמש במסוף Google Cloud כדי להיכנס לאשכולות רשומים מחוץ ל-Google Cloud באמצעות הזהות שלהם ב- Google Cloud .

  • משתמשים ב-kubectl כדי לגשת לאשכולות דרך Connect gateway.

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

אם אתם לא מכירים את שער Connect, תוכלו לעיין בסקירה הכללית שלנו כדי לקבל הסבר על המושגים הבסיסיים ועל אופן הפעולה שלו.

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

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

    • הגרסה האחרונה של Google Cloud CLI, כלי שורת הפקודה לאינטראקציה עם Google Cloud.
    • ‫kubectl להרצת פקודות באשכולות Kubernetes. אם אתם צריכים להתקין את kubectl, אתם יכולים לפעול לפי ההוראות האלה.

    אם אתם משתמשים ב-Cloud Shell כסביבת מעטפת לאינטראקציה עםGoogle Cloud, הכלים האלה מותקנים אצלכם.

  2. מאותחלים את ה-CLI של gcloud לשימוש בפרויקט, או מריצים את הפקודות הבאות כדי לתת הרשאה ל-CLI של gcloud ולהגדיר את הפרויקט כברירת מחדל:

    gcloud auth login
gcloud config set project PROJECT_ID

התפקידים שצריך ב-IAM כדי להגדיר את התכונה

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

  • כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable, שכלולה בתפקיד Service Usage Admin ‏ (roles/serviceusage.serviceUsageAdmin). בעלי הפרויקט יכולים ליצור תפקיד בהתאמה אישית עם ההרשאה serviceusage.services.enable, או להעניק לכם את התפקיד roles/serviceusage.serviceUsageAdmin, באופן הבא:

    gcloud projects add-iam-policy-binding PROJECT_ID \
   --member user:USER_EMAIL_ADDRESS \
   --role='roles/serviceusage.serviceUsageAdmin'

  • כדי להעניק הרשאות IAM למשתמשים ולחשבונות שירות כדי שיוכלו להשתמש בשער Connect, צריך את התפקיד Project IAM Admin (roles/resourcemanager.projectIamAdmin), שבעל הפרויקט יכול להעניק באמצעות הפקודה הבאה:

    gcloud projects add-iam-policy-binding PROJECT_ID \
   --member user:USER_EMAIL_ADDRESS \
   --role='roles/resourcemanager.projectIamAdmin'

הפעלת ממשקי ה-API

כדי להוסיף את שער Connect לפרויקט, צריך להפעיל את Connect gateway API ואת ממשקי ה-API של התלות הנדרשים שלו. אם המשתמשים רוצים לבצע אימות לאשכולות רק באמצעות מסוף Google Cloud , אתם לא צריכים להפעיל את connectgateway.googleapis.com, אבל אתם כן צריכים להפעיל את ממשקי ה-API האחרים.

gcloud services enable --project=PROJECT_ID  \
    connectgateway.googleapis.com \
    gkeconnect.googleapis.com \
    gkehub.googleapis.com \
    cloudresourcemanager.googleapis.com

אימות אשכולות רשומים

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

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

gcloud container fleet memberships list

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

NAME         EXTERNAL_ID
cluster-1    0192893d-ee0d-11e9-9c03-42010a8001c1
cluster-2    f0e2ea35-ee0c-11e9-be79-42010a8400c2

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

הגישה לאשכולות נשלטת על ידי ניהול הזהויות והרשאות הגישה (IAM). תפקידי ה-IAM שנדרשים לגישה לאשכולות באמצעות kubectl שונים מעט מהתפקידים שנדרשים לגישה לאשכולות במסוף Google Cloud , כמו שמוסבר בקטעים הבאים.

הקצאת תפקידים לגישה דרך kubectl

לפחות, משתמשים וחשבונות שירות צריכים את תפקידי ה-IAM הבאים כדי להשתמש ב-kubectl כדי ליצור אינטראקציה עם אשכולות דרך שער Connect, אלא אם למשתמש יש roles/owner בפרויקט:

  • ‫roles/gkehub.gatewayAdmin: התפקיד הזה מאפשר למשתמש לגשת ל-Connect gateway API כדי להשתמש ב-kubectl לניהול האשכול. התפקיד הזה כולל את ההרשאה gkehub.gateway.stream, שמאפשרת למשתמשים להריץ את הפקודות attach, cp ו-exec kubectl. מידע נוסף על הדרישות להרצת הפקודות האלה זמין במאמר תמיכה בתצוגה מקדימה בפקודות.

    • אם משתמש צריך גישת קריאה בלבד לאשכולות מקושרים, אפשר להעניק לו הרשאה מסוג roles/gkehub.gatewayReader.

    • אם משתמש צריך גישת קריאה / כתיבה לאשכולות מחוברים, אפשר להעניק לו את ההרשאה roles/gkehub.gatewayEditor.

  • ‫roles/gkehub.viewer: התפקיד הזה מאפשר למשתמש לאחזר את kubeconfigs של האשכול.

פרטים על ההרשאות שכלולות בתפקידים האלה מופיעים במאמר תפקידים ב-GKE Hub במסמכי ה-IAM.

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

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=GATEWAY_ROLE
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=roles/gkehub.viewer

where:

  • ‫MEMBER הוא המשתמש או חשבון השירות, בפורמט user|serviceAccount:emailID, לדוגמה:

    • user:alice@example.com
    • serviceAccount:test_sa@example-project.iam.gserviceaccount.com

  • ‫GATEWAY_ROLE הוא roles/gkehub.gatewayAdmin,‏ roles/gkehub.gatewayReader או roles/gkehub.gatewayEditor.

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

הקצאת תפקידים לגישה דרך מסוף Google Cloud

משתמשים שרוצים ליצור אינטראקציה עם אשכולות מחוץ ל- Google Cloudבאמצעות המסוף Google Cloud צריכים לפחות את תפקידי ה-IAM הבאים כדי להציג אשכולות:

  • roles/container.viewer. התפקיד הזה מאפשר למשתמשים לצפות בדף GKE Clusters ובמשאבי קונטיינרים אחרים במסוף Google Cloud . במאמר תפקידים ב-Kubernetes Engine שבמסמכי IAM מפורטות ההרשאות שכלולות בתפקיד הזה.

  • ‫roles/gkehub.viewer. התפקיד הזה מאפשר למשתמשים להציג אשכולות מחוץ ל-Google Cloud במסוף. Google Cloud שימו לב: זה אחד מהתפקידים שנדרשים לגישה אל kubectl. אם כבר הענקתם את התפקיד הזה למשתמש, אין צורך להעניק אותו שוב. פרטים על ההרשאות שכלולות בתפקיד הזה זמינים במאמר תפקידים ב-GKE Hub במאמרי העזרה בנושא IAM.

    בפקודות הבאות, מחליפים את PROJECT_ID במזהה הפרויקט המארח של הצי. בנוסף, מחליפים את MEMBER בכתובת האימייל של המשתמש או בחשבון השירות בפורמט user|serviceAccount:emailID, לדוגמה:

    • user:alice@example.com
    • serviceAccount:test_sa@example-project.iam.gserviceaccount.com
    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=roles/container.viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=roles/gkehub.viewer

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

הגדרת הרשאות RBAC

שרת Kubernetes API של כל אשכול צריך להיות מסוגל לאשר בקשות שמגיעות מהמסוף או מפקודות kubectl שמגיעות דרך שער Connect מהמשתמשים ומחשבונות השירות שצוינו. Google Cloud כדי לוודא זאת, צריך לעדכן את כללי המדיניות של בקרת הגישה מבוססת-תפקידים (RBAC) בכל אשכול שרוצים להפוך לנגיש דרך השער. צריך להוסיף או לעדכן את כללי המדיניות הבאים:

  • מדיניות התחזות שמאשרת לסוכן Connect לשלוח בקשות לשרת Kubernetes API בשם משתמש.
  • מדיניות הרשאות שמציינת אילו הרשאות יש למשתמש באשכול. זה יכול להיות תפקיד ברמת האשכול כמו clusterrole/cluster-admin או clusterrole/cloud-console-reader, או תפקיד ברמת מרחב השמות כמו role/default/pod-reader.

(אופציונלי) יצירת תפקיד cloud-console-reader

משתמשים מאומתים שרוצים לגשת למשאבים של אשכול במסוף Google Cloud צריכים לקבל את ההרשאות הרלוונטיות ב-Kubernetes כדי לעשות זאת. אם אתם לא רוצים להעניק למשתמשים האלה הרשאות נרחבות יותר, כמו הרשאות של אדמין באשכול, אתם יכולים ליצור תפקיד RBAC בהתאמה אישית שכולל את ההרשאות המינימליות לצפייה בצמתים, בכרכים מתמשכים, בתרמילים ובסוגי האחסון של האשכול. כדי להגדיר את קבוצת ההרשאות הזו, צריך ליצור משאב ClusterRole RBAC,‏ cloud-console-reader, באשכול.

‫cloud-console-reader מעניק למשתמשים שלו את ההרשאות get,‏ list ו-watch בצמתים של האשכול, בכרכים מתמשכים, בתרמילים ובסוגי האחסון, מה שמאפשר להם לראות פרטים על המשאבים האלה.

kubectl

כדי ליצור את cloud-console-reader ClusterRole ולהחיל אותו על האשכול, מריצים את הפקודה הבאה:

cat <<EOF > cloud-console-reader.yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: cloud-console-reader
rules:
- apiGroups: [""]
  resources: ["nodes", "persistentvolumes", "pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
  resources: ["storageclasses"]
  verbs: ["get", "list", "watch"]
EOF
kubectl apply -f cloud-console-reader.yaml

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

יצירה והחלה של מדיניות RBAC נדרשת

בדוגמה הבאה אפשר לראות איך יוצרים את מדיניות ה-RBAC הנדרשת ומחילים אותה. הדרך הכי פשוטה לעשות את זה היא להשתמש ב-CLI של gcloud כדי ליצור ולהחיל את כללי המדיניות המתאימים. לחלופין, אם אתם מעדיפים, אתם יכולים ליצור קובץ מדיניות RBAC ולהחיל אותו באמצעות kubectl.

gcloud

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

gcloud container fleet memberships generate-gateway-rbac  \
    --membership=MEMBERSHIP_NAME \
    --role=ROLE \
    --users=USERS \
    --project=PROJECT_ID \
    --kubeconfig=KUBECONFIG_PATH \
    --context=KUBECONFIG_CONTEXT \
    --apply

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

  • ‫MEMBERSHIP_NAME: השם שמשמש לייצוג ייחודי של האשכול ב-Fleet. במאמר קבלת סטטוס החברות בצי מוסבר איך בודקים את שם החברות באשכול.
  • ‫ROLE: תפקיד Kubernetes שרוצים להקצות למשתמשים באשכול, לדוגמה, clusterrole/cluster-admin,‏ clusterrole/cloud-console-reader או role/mynamespace/namespace-reader. התפקיד הזה צריך להיות קיים לפני שמריצים את הפקודה.
  • ‫USERS: כתובות האימייל של המשתמשים (חשבונות משתמשים או חשבונות שירות) שרוצים להעניק להם את ההרשאות, כרשימה מופרדת בפסיקים. לדוגמה: --users=dana@example.com,test-acct@test-project.iam.gserviceaccount.com.
  • ‫PROJECT_ID: מזהה הפרויקט שבו האשכול רשום.
  • ‫KUBECONFIG_PATH: הנתיב המקומי של קובץ ה-kubeconfig שבו מאוחסן רשומה של האשכול. ברוב המקרים, זהו הסכום $HOME/.kube/config.

  • ‫KUBECONFIG_CONTEXT: ההקשר של האשכול כפי שהוא מופיע בקובץ kubeconfig. כדי לקבל את ההקשר הנוכחי משורת הפקודה, מריצים את הפקודה kubectl config current-context. בין אם משתמשים בהקשר הנוכחי ובין אם לא, חשוב לוודא שהגישה לאשכול פועלת על ידי הרצת הפקודה הבאה:

    kubectl get namespaces \
  --kubeconfig=KUBECONFIG_PATH \
  --context=KUBECONFIG_CONTEXT

אחרי שמריצים את gcloud container fleet memberships generate-gateway-rbac, בסוף הפלט מופיע משהו כזה, שקוצר כדי שיהיה קל לקרוא אותו

Validating input arguments.
Specified Cluster Role is: clusterrole/cluster-admin
Generated RBAC policy is:
--------------------------------------------
...
---
Applying the generate RBAC policy to cluster with kubeconfig: artifacts/kubeconfig, context: example-cluster-admin@example-cluster
Writing RBAC policy for user: 222larabrown@gmail.com to cluster.
Successfully applied the RBAC policy to cluster.

זהו ההקשר לגישה לאשכול דרך שער Connect.

למידע נוסף על הפקודה generate-gateway-rbac, אפשר לעיין במדריך העזר ל-CLI של gcloud.

kubectl

בדוגמה הבאה מוצגות דרכים ליצור מדיניות מתאימה למשתמש (dana@example.com) ולחשבון שירות (test@example-project.iam.gserviceaccount.com), להעניק לשניהם הרשאות cluster-admin באשכול ולשמור את קובץ המדיניות בשם /tmp/gateway-rbac.yaml. המדיניות מוחלת על האשכול שמשויך להקשר הנוכחי:

cat <<EOF > /tmp/gateway-rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: gateway-impersonate
rules:
- apiGroups:
  - ""
  resourceNames:
  - dana@example.com
  - test@example-project.iam.gserviceaccount.com
  resources:
  - users
  verbs:
  - impersonate
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gateway-impersonate
roleRef:
  kind: ClusterRole
  name: gateway-impersonate
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
  name: connect-agent-sa
  namespace: gke-connect
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gateway-cluster-admin
subjects:
- kind: User
  name: dana@example.com
- kind: User
  name: test@example-project.iam.gserviceaccount.com
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
EOF
# Apply policies to the cluster.
kubectl apply --kubeconfig=KUBECONFIG_PATH  -f /tmp/gateway-rbac.yaml

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

תמיכה ב-VPC Service Controls

‫VPC Service Controls מספק שכבת הגנה נוספת לשירותיGoogle Cloud , שהיא בלתי תלויה בניהול זהויות והרשאות גישה (IAM). בעוד ש-IAM מאפשר בקרת גישה מפורטת שמבוססת על זהויות, ‏ VPC Service Controls מאפשר אבטחת היקף רחבה יותר שמבוססת על הקשר, כולל שליטה בתעבורת נתונים יוצאת (egress) בהיקף – לדוגמה, אתם יכולים לציין שרק פרויקטים מסוימים יכולים לגשת לנתוני BigQuery שלכם. מידע נוסף על האופן שבו VPC Service Controls פועל כדי להגן על הנתונים זמין בסקירה הכללית על VPC Service Controls.

אפשר להשתמש ב-VPC Service Controls עם שער Connect כדי להוסיף אבטחת מידע, אחרי שמוודאים שאפשר לגשת לממשקי ה-API הנדרשים לשימוש בשער מתוך גבולות גזרה לשירות שצוינו.

מה השלב הבא?