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

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

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

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

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

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

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

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

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

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

הכנת הסביבה

מתן הרשאות לגישה לאשכול רגיל

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

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

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

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

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

  2. כדי ליצור קובץ 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: השם של הפרויקט שבו קיים האשכול הרגיל.

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