ניהול משתמשים ב-Distributed Cloud במודל מחובר

בדף הזה מוסבר איך לנהל משתמשים ב-Distributed Cloud מחובר.

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

• מתן ההרשאות הנדרשות באמצעות Kubernetes RBAC
• שימוש ב-Connect Gateway כדי לגשת לאשכול

מתן ההרשאות הנדרשות באמצעות Kubernetes RBAC

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

‫Distributed Cloud connected לא תומך בקבוצות לניהול זהויות והרשאות גישה (IAM) או בספקי זהויות של צד שלישי לשימוש עם Kubernetes RBAC באשכולות של Distributed Cloud connected.

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

• ‫ClusterRole: מאפשר להחיל קבוצת הרשאות על כל מרחב שמות באשכול, וגם מעניק גישה למשאבים ברמת האשכול.
• ‫ClusterRoleBinding: מקשר משאב ClusterRole לחשבון משתמש.
• ‫Role: מאפשרת להחיל קבוצה של הרשאות על מרחב שמות ספציפי.
• ‫RoleBinding: מקשרת משאב Role או ClusterRole לחשבון משתמש במרחב שמות ספציפי.

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

כשיוצרים אשכול מחובר של Distributed Cloud, חשבון המשתמש שבו משתמשים כדי לעשות זאת הופך אוטומטית לאדמין של האשכול. כדי להעניק הרשאות אדמין של אשכול למשתמשים נוספים, צריך לקשר את חשבון המשתמש הרצוי לתפקיד cluster-admin על ידי יצירת משאב ClusterRoleBinding והחלת המשאב על האשכול:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: BINDING_NAME
subjects:
  kind: User
  name: ACCOUNT_NAME
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

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

• ‫BINDING_NAME: שם שמזהה באופן ייחודי את קישור התפקיד הזה.
• ‫ACCOUNT_NAME: השם של חשבון המשתמש של היעד.

אפשר גם להשתמש בפקודה kubectl הבאה:

kubectl create clusterrolebinding "BINDING_NAME" \
  --clusterrole cluster-admin --user "ACCOUNT_NAME"

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

• ‫BINDING_NAME: שם שמזהה באופן ייחודי את קישור התפקיד הזה.
• ‫ACCOUNT_NAME: השם של חשבון המשתמש של היעד.

הענקת הרשאות למפתח אפליקציות

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

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

   apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      namespace: NAMESPACE
      name: ROLE_NAME
    rules:
      apiGroups: ["apps", ""]
      resources: ["pods", "deployments", "services"]
      verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
   

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

   • ‫NAMESPACE: השם של מרחב השמות של היעד.
   • ‫ROLE_NAME: שם שמזהה באופן ייחודי את התפקיד הזה.

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

   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
    namespace: NAMESPACE
    name: BINDING_NAME
   subjects:
    kind: User
    name: ACCOUNT_NAME
    kind: User
    name: ACCOUNT_NAME
   roleRef:
    kind: Role
    name: ROLE_NAME
    apiGroup: rbac.authorization.k8s.io
   

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

   • ‫BINDING_NAME: שם שמזהה באופן ייחודי את קישור התפקיד הזה.
   • ‫NAMESPACE: השם של מרחב השמות של היעד.
   • ‫ACCOUNT_NAME: השם של חשבון המשתמש של היעד.
   • ‫ROLE_NAME: השם של תפקיד היעד.

מתן הרשאות לסוכן שירות של Cloud Build

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

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

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
    namespace: NAMESPACE
    name: ROLE_NAME
   rules:
    apiGroups: ["apps", ""]
    resources: ["pods", "deployments", "services"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
   

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

   • ‫NAMESPACE: השם של מרחב השמות של היעד.
   • ‫ROLE_NAME: שם שמזהה באופן ייחודי את התפקיד הזה.

2. יוצרים משאב RoleBinding שמקשר את חשבון סוכן השירות של Cloud Build אל התפקיד שיצרתם בשלב הקודם, ומחילים אותו על האשכול:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
    namespace: NAMESPACE
    name: BINDING_NAME
   subjects:
    kind: User
    name: [e-mail]
   roleRef:
    kind: Role
    name: ROLE_NAME
    apiGroup: rbac.authorization.k8s.io
   

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

   • ‫BINDING_NAME: שם שמזהה באופן ייחודי את קישור התפקיד הזה.
   • ‫NAMESPACE: השם של מרחב השמות של היעד.
   • ‫PROJECT_ID: המזהה של Google Cloud פרויקט היעד.
   • ‫ROLE_NAME: השם של תפקיד היעד.

אם אתם צריכים לתת לסוכן השירות של Cloud Build הרשאות לפריסה ולניהול של עומסי עבודה בכל מרחבי השמות באשכול היעד, אתם צריכים ליצור משאב ClusterRole ומשאב ClusterRoleBinding במקום משאב Role ומשאב RoleBinding.

מתן הרשאות לצפייה בפרטי האשכול

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

1. יוצרים משאב ClusterRole שמאפשר לסוכן Connect להתחזות למשתמש שצריך להציג את פרטי האשכול במסוף Google Cloud :

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
    name: ROLE_NAME
   rules:
    apiGroups: [""]
    resources: ["users"]
    verbs: ["impersonate"]
    resourceNames: ["ACCOUNT_NAME"]
   

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

   • ‫ROLE_NAME: השם של תפקיד היעד.
   • ‫ACCOUNT_NAME: השם של חשבון המשתמש של היעד.

2. יוצרים משאב ClusterRoleBinding שמקשר את חשבון הסוכן של Connect Agent Service לתפקיד שיצרתם בשלב הקודם, ומחילים אותו על האשכול:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
    name: BINDING_NAME
   subjects:
    kind: ServiceAccount
    name: ACCOUNT_NAME
   roleRef:
    kind: ClusterRole
    name: ROLE_NAME
    apiGroup: rbac.authorization.k8s.io
   

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

   • ‫BINDING_NAME: שם שמזהה באופן ייחודי את קישור התפקיד הזה.
   • ‫ACCOUNT_NAME: השם של חשבון המשתמש בשירות היעד.
   • ‫ROLE_NAME: השם של תפקיד היעד.

צריך ליצור צמד משאבים נפרד של ClusterRole ו-ClusterRoleBinding לכל משתמש מושפע.

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

1. יוצרים משאב ClusterRole שמאפשר לסוכן Connect להתחזות למשתמש שצריך להציג את פרטי האשכול במסוף Google Cloud :

   kubectl create clusterrole "ROLE_NAME" --verb impersonate \
    --resource users --resource-name "ACCOUNT_NAME"
   

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

   • ‫ROLE_NAME: השם של תפקיד היעד.
   • ‫ACCOUNT_NAME: השם של חשבון המשתמש בשירות היעד.

2. יוצרים משאב ClusterRoleBinding שמקשר את חשבון הסוכן של Connect Agent Service לתפקיד שיצרתם בשלב הקודם, ומחילים אותו על האשכול:

   kubectl create clusterrolebinding "BINDING_NAME" --clusterrole \
    "ROLE_NAME" --serviceaccount "ACCOUNT_NAME"
   

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

   • ‫BINDING_NAME: שם שמזהה באופן ייחודי את קישור התפקיד הזה.
   • ‫ACCOUNT_NAME: השם של חשבון המשתמש בשירות היעד.
   • ‫ROLE_NAME: השם של תפקיד היעד.

שימוש בשער חיבור כדי לגשת לאשכולות מחוברים של Distributed Cloud

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

• Connect Gateway Admin (roles/gkehub.gatewayAdmin): מעניקה גישה ל-Connect Gateway API. התפקיד הזה מאפשר להשתמש בכלי kubectl של שורת הפקודה כדי לנהל את האשכול.
• Connect Gateway Editor (roles/gkehub.gatewayEditor): מעניקה גישת קריאה וכתיבה לאשכול.
• Connect Gateway Reader (roles/gkehub.gatewayReader): מעניקה גישה לקריאה בלבד לאשכול.
• GKE Hub Viewer (roles/gkehub.viewer): מאפשרת לאחזר קובצי kubeconfig מהאשכול.

מידע נוסף על השימוש בשער לחיבור זמין במאמרים הבאים:

• הגדרת שער Connect
• שימוש בשער לחיבור