אבטחת הגישה למשאבים באמצעות IAM

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

המשאבים שיכולים להפנות ל-IAMPolicy ול-IAMPolicyMember מפורטים בהפניה למשאבים. למשאבים האלה יש את המאפיין "Can Be Referenced by IAMPolicy/IAMPolicyMember".

במאמר הזה מוסבר איך לאבטח את הגישה למשאבי Google Cloud באמצעות ניהול זהויות והרשאות גישה (IAM).

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

מתקינים את Config Connector באשכול.

אבטחת הגישה למישור הבקרה באמצעות RBAC

בדוגמה הזו, תיצרו חשבון שירות ותתנו לו הרשאות לנהל PubSubTopic. חשבון השירות הזה לא יכול לנהל סוגים אחרים של משאבי Config Connector.

1. יוצרים קובץ בשם pubsub-topic-service-account.yaml עם התוכן הבא:

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: pubsub-topic-service-account
     namespace: default
   

   מחילים את הקובץ כדי ליצור את חשבון השירות pubsub-topic-service-account:

   kubectl apply -f pubsub-topic-service-account.yaml --namespace CC_NAMESPACE

   מחליפים את CC_NAMESPACE במרחב השמות שבו Config Connector מנהל את המשאבים.

2. כדי לוודא ש-pubsub-topic-service-account לא יכול ליצור משאבים מסוג PubSubTopic, מריצים את הפקודה הבאה ובודקים שהפלט מכיל את הערך no:

   kubectl auth can-i get pubsubtopics --as=system:serviceaccount:default:pubsub-topic-service-account

3. אחר כך יוצרים ClusterRole שמאפשרת ליצור נושא Pub/Sub.

   ה-ClusterRole יכול לנהל רק משאבים שיש להם ערכים שצוינו ב-rules.apiGroups וב-rules.resources. כדי למצוא ערכים ל-apiGroups ול-resources, עיינו בחומר העזר של המשאבים.

   יוצרים קובץ בשם pubsub-topic-editor-role.yaml עם התוכן הבא:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     creationTimestamp: null
     name: pubsub-topic-editor
   rules:
   - apiGroups:
     - pubsub.cnrm.cloud.google.com
     resources:
     - pubsubtopics
     verbs:
     - get
     - list
     - watch
     - create
     - update
     - patch
     - delete
   

   מפעילים את pubsub-topic-editor.yaml כדי ליצור את ClusterRole:

   kubectl apply -f pubsub-topic-editor-role.yaml --namespace CC_NAMESPACE

   מחליפים את CC_NAMESPACE במרחב השמות שבו Config Connector מנהל את המשאבים.

4. אחר כך יוצרים RoleBinding בין ClusterRole לבין חשבון השירות. יוצרים קובץ בשם pubsub-topic-editor-rolebinding.yaml עם התוכן הבא:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: pubsub-topic-editor-rolebinding.
   subjects:
   - kind: ServiceAccount
     name: pubsub-topic-service-account
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: pubsub-topic-editor
   

5. מחילים את pubsub-topic-editor-rolebinding.yaml על האשכול.

   kubectl apply -f pubsub-topic-editor-rolebinding.yaml --namespace CC_NAMESPACE

   מחליפים את CC_NAMESPACE במרחב השמות שבו Config Connector מנהל את המשאבים.

6. כדי לוודא של-pubsub-topic-service-account יש הרשאה ליצור משאבי PubSubTopic, מריצים את הפקודה הבאה ובודקים שהפלט הוא yes:

   kubectl auth can-i get pubsubtopics \
     --as=system:serviceaccount:default:pubsub-topic-service-account

סידור וארגון

משתמשים ב-kubectl delete כדי להסיר את חשבון השירות, את תפקיד ה-IAM ואת ה-Rolebinding.

kubectl delete -f pubsub-topic-editor-rolebinding.yaml --namespace CC_NAMESPACE
kubectl delete -f pubsub-topic-editor-role.yaml --namespace CC_NAMESPACE
kubectl delete -f pubsub-topic-service-account.yaml --namespace CC_NAMESPACE

מחליפים את CC_NAMESPACE במרחב השמות שבו Config Connector מנהל את המשאבים.

אבטחת מישור הנתונים באמצעות מדיניות IAM

בדוגמה הזו, אתם משתמשים בהרשאות שניתנו קודם כדי ליצור PubSubTopic ולהגביל את הגישה אליו באמצעות משאב IAMPolicyMember.

1. יוצרים קובץ בשם pubsub-topic-sample.yaml עם התוכן הבא:

   apiVersion: pubsub.cnrm.cloud.google.com/v1beta1
   kind: PubSubTopic
   metadata:
     name: pubsubtopic-sample
   

   החלת pubsub-topic-sample.yaml עם kubectl:

   kubectl apply -f pubsub-topic-sample.yaml --namespace CC_NAMESPACE

   מחליפים את CC_NAMESPACE במרחב השמות שבו Config Connector מנהל את המשאבים.

2. יוצרים קובץ בשם iampolicymember.yaml עם התוכן הבא, ומחליפים את EMAIL_ADDRESS בכתובת האימייל של חשבון Google Cloud :

   apiVersion: iam.cnrm.cloud.google.com/v1beta1
   kind: IAMPolicyMember
   metadata:
     name: iampolicymember-sample
   spec:
     resourceRef:
       apiVersion: pubsub.cnrm.cloud.google.com/v1beta1
       kind: PubSubTopic
       name: pubsubtopic-sample
     role: roles/pubsub.admin
     member: "user:EMAIL_ADDRESS"
   

3. מחילים את iampolicymember.yaml.

   kubectl apply -f iampolicymember.yaml  --namespace CC_NAMESPACE 

   מחליפים את CC_NAMESPACE במרחב השמות שבו Config Connector מנהל את המשאבים.

4. כדי לוודא שהמדיניות הוחלה על Google Cloud , מריצים את הפקודה הבאה ומחפשים את כתובת האימייל בפלט. מחליפים את PROJECT_ID במזהה הפרויקט:

   gcloud beta pubsub topics get-iam-policy projects/PROJECT_ID/topics/pubsubtopic-sample

הגישה לנושאי Pub/Sub מוגנת עכשיו באמצעות IAMPolicyMember.

סידור וארגון

משתמשים ב-kubectl delete כדי להסיר את נושא Pub/Sub ואת IAMPolicyMember מהפרויקט ב- Google Cloud .

kubectl delete -f iampolicymember.yaml --namespace CC_NAMESPACE
kubectl delete -f pubsub-topic-sample.yaml --namespace CC_NAMESPACE

שיטות מומלצות לאבטחה בבידוד של מספר דיירים

כדי למנוע הרחבת הרשאות לא מורשית ולאכוף בידוד דיירים, מומלץ לפעול לפי השיטות המומלצות הבאות:

• אכיפת מצב מרחב שמות: הימנעו ממצב אשכול בסביבות עם כמה דיירים. במצב אשכול, כל מרחבי השמות משתפים חשבון שירות אחד ב-IAM. כל משתמש שיכול ליצור משאבים של Config Connector בכל מרחב שמות יכול לפעול עם הרשאות ה-IAM המלאות של אותו חשבון שירות.

• הגבלת RBAC למשאבי IAM: הגבלת הרשאות היצירה והשינוי של משאבי IAMPolicy,‏ IAMPartialPolicy ו-IAMPolicyMember באמצעות בקרת גישה מבוססת-תפקידים (RBAC) של Kubernetes. אם למפתחים יש גישת כתיבה רחבה למשאבים האלה, הם יכולים לשנות את הקישורים של Google Cloud ל-IAM.

• היקף הקישורים של IAM לאיחוד זהויות של עומסי עבודה ל-GKE: מגדירים את הקישורים האלה רק לחשבונות שירות ייעודיים של Kubernetes במרחבי שמות ספציפיים. במצב מרחב שמות, מקשרים כל חשבון שירות של IAM רק ל-Config Connector Kubernetes ServiceAccount של מרחב השמות שלו:

  gcloud iam service-accounts add-iam-policy-binding \
      GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
      --member="serviceAccount:PROJECT_ID.svc.id.goog[cnrm-system/cnrm-controller-manager-CC_NAMESPACE]" \
      --role="roles/iam.workloadIdentityUser"
  

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

  • ‫GSA_NAME: השם של חשבון השירות ב-IAM שבו Config Connector משתמש למרחב השמות.
  • ‫PROJECT_ID: מזהה הפרויקט שמכיל את האשכול ואת חשבון השירות ב-IAM.
  • ‫CC_NAMESPACE: מרחב השמות שבו Config Connector מנהל את המשאבים.

  אל תקצו את התפקיד roles/iam.workloadIdentityUser לקבוצת חשבונות משתמשים, כמו כל ה-Pods במרחב השמות cnrm-system. במצב מרחב שמות, הבקרים של Config Connector לכל מרחבי השמות פועלים ב-cnrm-system, כך שסוג הקישור הזה מאפשר לבקר של כל מרחב שמות להתחזות לחשבון השירות של IAM.

המאמרים הבאים

אפשר להשתמש בסודות כדי להעביר מידע בצורה מאובטחת למשאבי Google Cloud .