במסמך הזה מוסבר על ההבדלים בין ניהול זהויות והרשאות גישה (IAM) לבין בקרת גישה מבוססת-תפקידים (RBAC) ב-Kubernetes ב-Google Kubernetes Engine, כדי לעזור לכם לנהל את הגישה למשאבים בפרויקט. במסמך הזה אנחנו יוצאים מנקודת הנחה שאתם מכירים את הנושאים הבאים:
המסמך הזה מיועד למומחי אבטחה שמנהלים את הגישה להרשאות ורוצים להבין את ההבדלים בין IAM לבין RBAC ואת נקודות החפיפה ביניהם. כדי לקבל מידע נוסף על תפקידים נפוצים ומשימות לדוגמה שאנחנו מתייחסים אליהם בGoogle Cloud תוכן, אפשר לעיין במאמר תפקידים נפוצים של משתמשים ומשימות ב-GKE.
ניהול הגישה למשאבי GKE
כשיוצרים Google Cloud פרויקט, אתם המשתמשים היחידים בפרויקט. כברירת מחדל, לאף משתמש אחר אין גישה לפרויקט או למשאבים שלו, כולל משאבי Google Kubernetes Engine (GKE). GKE תומך בכמה אפשרויות לניהול גישה למשאבים בפרויקט ובאשכולות שלו באמצעות בקרת גישה שמבוססת על תפקידים (RBAC).
יש חפיפה מסוימת בין המנגנונים האלה, אבל הם מיועדים לסוגים שונים של משאבים. כל אחת מהן מוסברת בקטע ייעודי בדף הזה, אבל בקצרה:
Kubernetes RBAC מובנה ב-Kubernetes, ומעניק הרשאות גרנולריות לאובייקטים באשכולות Kubernetes. ההרשאות קיימות כאובייקטים מסוג ClusterRole או Role בתוך האשכול. אובייקטים של RoleBinding מעניקים תפקידים למשתמשי Kubernetes, Google Cloud למשתמשים, לחשבונות שירות ב-IAM או לקבוצות Google.
אם אתם משתמשים בעיקר ב-GKE וצריכים הרשאות מפורטות לכל אובייקט ופעולה באשכול, כדאי להשתמש ב-Kubernetes RBAC.
IAM מנהל משאבים, כולל אשכולות וסוגי אובייקטים באשכולות. Google Cloud ההרשאות מוקצות לחשבונות משתמשים ב-IAM.
אין מנגנון למתן הרשאות לאובייקטים ספציפיים של Kubernetes ב-IAM. לדוגמה, אפשר לתת למשתמש הרשאת משתמש ליצור CustomResourceDefinitions (CRDs), אבל אי אפשר לתת למשתמש הרשאת משתמש ליצור רק CustomResourceDefinition ספציפי אחד, או להגביל את היצירה ל-Namespace ספציפי או לאשכול ספציפי בפרויקט. תפקיד IAM מעניק הרשאות בכל האשכולות בפרויקט, או בכל האשכולות בכל פרויקטי הצאצא אם התפקיד מוחל ברמת התיקייה.
אם אתם משתמשים בכמה רכיבים של Google Cloud ואתם לא צריכים לנהל הרשאות ספציפיות ל-Kubernetes ברמת גרנולריות גבוהה, IAM הוא בחירה טובה.
Kubernetes RBAC
ל-Kubernetes יש תמיכה מובנית ב-RBAC שמאפשרת ליצור תפקידים עם הרשאות מפורטות, שקיימים באשכול Kubernetes. היקף התפקיד יכול להיות אובייקט ספציפי ב-Kubernetes או סוג של אובייקט ב-Kubernetes, והוא מגדיר אילו פעולות (שנקראות פעלים) התפקיד מאפשר ביחס לאובייקט הזה. RoleBinding הוא גם אובייקט Kubernetes, והוא מעניק תפקידים למשתמשים. משתמש GKE יכול להיות כל אחד מהבאים:
- Google Cloud user
- חשבון שירות ב-IAM
- Kubernetes ServiceAccount
- משתמש ב-Google Workspace
- קבוצת Google Workspace
- משתמשים שעברו אימות באמצעות אישורי לקוח X509
מידע נוסף מופיע במאמר בנושא בקרת גישה מבוססת-תפקידים.
IAM
ב-IAM אפשר להעניק תפקידים לחשבונות משתמשים. תפקיד הוא אוסף של הרשאות, וכשנותנים אותו לחשבון משתמש, הוא מאפשר לחשבון המשתמש לגשת ל Google Cloud משאב אחד או יותר. מידע נוסף על חשבונות משתמשים, תפקידים ומונחים אחרים ב-IAM זמין במאמר סקירה כללית של IAM.
ב-GKE, גורם ראשי יכול להיות כל אחת מהאפשרויות הבאות:
- חשבון משתמש
- חשבון שירות
- קבוצת Google Workspace
- דומיין Google Workspace
- דומיין ב-Cloud Identity
מידע נוסף על שימוש ב-IAM כדי לשלוט בגישה ב-GKE זמין במאמר יצירת מדיניות הרשאות ב-IAM.
סוגים של מדיניות IAM
IAM תומך בסוגי המדיניות הבאים:
- כללי מדיניות הרשאות: הקצאת תפקידים לחשבונות משתמשים. פרטים נוספים זמינים במאמר בנושא מדיניות הרשאות.
- כללי מדיניות הדחייה: מונעים מחשבונות משתמשים להשתמש בהרשאות ספציפיות ב-IAM, ללא קשר לתפקידים שהוקצו להם. פרטים נוספים זמינים במאמר בנושא מדיניות דחייה.
אפשר להשתמש בכללי מדיניות דחייה כדי להגביל חשבונות משתמשים מסוימים מלבצע פעולות מסוימות בפרויקט, בתיקייה או בארגון, גם אם מדיניות הרשאות של IAM מעניקה לחשבונות המשתמשים האלה תפקיד שמכיל את ההרשאות הרלוונטיות.
המלצות IAM
כדאי להשתמש בתפקידי ה-IAM המוגדרים מראש הבאים כדי להקל על תרחישים נפוצים:
- Kubernetes Engine Cluster Viewer (
roles/container.clusterViewer): מהנדסי DevOps, מהנדסים ומפתחי אפליקציות שצריכים רק להתחבר לאשכול. - אדמין אשכול של Kubernetes Engine (
roles/container.clusterAdmin): אדמינים של פלטפורמות ומפעילים של אשכולות שצריכים לנהל אשכול אחד או יותר בפרויקט Google Cloud .
רשימת התפקידים המוגדרים מראש ב-IAM זמינה במאמר תפקידים מוגדרים מראש ב-GKE.
GKE משתמש בחשבונות שירות של IAM שמצורפים לצמתים כדי להריץ משימות מערכת כמו רישום ביומן ומעקב. לפחות, חשבונות השירות של הצמתים צריכים לקבל את התפקיד Kubernetes Engine Default Node Service Account (roles/container.defaultNodeServiceAccount) בפרויקט. כברירת מחדל, GKE משתמש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine, שנוצר באופן אוטומטי בפרויקט, כחשבון השירות של הצומת.
אינטראקציה של IAM עם Kubernetes RBAC
IAM ו-Kubernetes RBAC פועלים יחד כדי לעזור לכם לנהל את הגישה לאשכול. RBAC שולט בגישה ברמת האשכול ומרחב השמות, בעוד ש-IAM פועל ברמת הפרויקט. לישות צריכות להיות הרשאות מספיקות באחת מהרמות כדי לעבוד עם משאבים באשכול.
המאמרים הבאים
- סקירה כללית על אבטחה ב-GKE
- איך משתמשים ב-Kubernetes RBAC
- איך יוצרים כללי מדיניות IAM ל-GKE
- איך משתמשים בתנאי IAM למאזני עומסים