‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

ניהול הגישה לאשכולות רגילים

רגילה

במאמר הזה מוסבר איך להעניק גישה ולנהל הרשאות באשכולות רגילים ב-Google Distributed Cloud (GDC) air-gapped. אשכולות רגילים הם סביבות Kubernetes שמוגדרות ברמת הפרויקט, עם שירותי ברירת מחדל מינימליים שמציעים גמישות ושליטה רבות יותר לעומסי עבודה מותאמים אישית.

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

מידע נוסף על אשכולות רגילים וסוגים אחרים של אשכולות זמין במאמר הגדרות של אשכול Kubernetes.

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

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

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

שליחת בקשה לתפקידים ב-IAM

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

כדי להעניק ולנהל קשירות של מדיניות IAM ברמת הפרויקט עבור אשכולות רגילים, צריך לפנות לאדמין IAM בארגון ולבקש את התפקיד אדמין IAM של פרויקט (project-iam-admin).
כדי לנהל בקרת גישה מבוססת-תפקידים (RBAC) ב-Kubernetes באשכול ולפרוס עומסי עבודה באשכול רגיל, צריך לבקש מאדמין IAM של הפרויקט להקצות לכם את התפקיד Cluster Admin (אדמין של אשכול) (cluster-admin).

הכנת הסביבה

מורידים ומתקינים את ה-CLI של gcloud, אם עוד לא עשיתם זאת.
מתקינים את kubectl CLI.

הענקת הרשאות לגישה לאשכול רגיל

משתמש עם תפקיד אדמין בפרויקט IAM‏ (project-iam-admin) יכול להעניק למשתמשים אחרים את התפקידים הנדרשים לניהול גישה באשכולות רגילים:

נכנסים באמצעות ספק הזהויות שהגדרתם באמצעות ה-CLI של gcloud.
נותנים למשתמש את התפקיד Cluster Admin ‏ (cluster-admin) בפרויקט. הפקודה הזו מקשרת את המשתמש לתפקיד, ומאפשרת לו לנהל את הגישה באשכול הרגיל.

מידע נוסף על התפקידים מופיע במאמרים תיאורים של תפקידים מוגדרים מראש והגדרות של תפקידים בפרויקטים.
```
gdcloud projects add-iam-policy-binding PROJECT \
  --role=ROLE \
  --member=user:USER_ACCOUNT
```
מחליפים את המשתנים הבאים:
- ‫PROJECT: השם של הפרויקט שבו קיים האשכול הרגיל.
- ‫ROLE: שם התפקיד שרוצים להקצות (למשל cluster-admin).
- ‫USER_ACCOUNT: חשבון המשתמש שרוצים להקצות לו את התפקיד, כולל הקידומת של ספק הזהויות שמשויכת לארגון (למשל idpprefix-user@example.com). הקידומת הספציפית שמשמשת תלויה בהגדרת ה-IdP של הארגון. מידע נוסף זמין במאמר בנושא התחברות לספק זהויות.
בדוגמה הבאה, התפקיד Cluster Admin מוקצה ל-user@example.com, בהנחה שהקידומת של ספק הזהויות היא fop- בפרויקט foo:
```
gdcloud projects add-iam-policy-binding foo \
  --role=cluster-admin \
  --member=user:fop-user@example.com
```

ניהול הגישה באשכול הרגיל

משתמש עם תפקיד אדמין של אשכול (cluster-admin) יכול להעניק גישה באשכול רגיל:

נכנסים באמצעות ספק הזהויות שהגדרתם באמצעות ה-CLI של gcloud.
כדי ליצור קובץ kubeconfig עבור אשכול רגיל, משתמשים בדגל --standard. הדגל הזה נדרש כדי לטרגט אשכול רגיל.
```
export KUBECONFIG=KUBECONFIG_FILE
gdcloud clusters get-credentials STANDARD_CLUSTER_NAME --standard --project=PROJECT
```
מחליפים את המשתנים הבאים:
- ‫KUBECONFIG_FILE: הנתיב לקובץ kubeconfig, לדוגמה standard-cluster-kubeconfig.yaml.
- ‫STANDARD_CLUSTER_NAME: השם של אשכול התקנים.
- ‫PROJECT: השם של הפרויקט שבו קיים האשכול הרגיל.
מגדירים הרשאות באשכול הרגיל באמצעות kubectl.

משתמשים עם הרשאות cluster-admin יכולים ליצור אובייקטים של Role ושל ClusterRole בהתאמה אישית. כדי להעניק את ההרשאות האלה, הם יכולים ליצור את האובייקטים התואמים Rolebinding ו-ClusterRoleBinding כדי לקשר את התפקידים לנושאים ספציפיים, כמו משתמשים או חשבונות שירות.

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

בדוגמה הבאה נעשה שימוש ב-kubectl כדי ליצור Role בהתאמה אישית בשם test-role במרחב השמות test:
```
kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: test-role
  namespace: test
rules:
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - get
EOF
```
בדוגמה הבאה נוצר RoleBinding עבור Role בשם test-role במרחב השמות test. הפקודה מעניקה הרשאות למשתמש alice@example.com עם הקידומת של ספק הזהויות fop-, וגם ל-ServiceAccount בשם my-service-account במרחב השמות default:
```
kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: test-role-binding
  namespace: test
subjects:
- kind: User
  name: fop-alice@example.com
  apiGroup: rbac.authorization.k8s.io
- kind: ServiceAccount
  name: my-service-account
  namespace: default
roleRef:
  kind: Role
  name: test-role
  apiGroup: rbac.authorization.k8s.io
EOF
```