הגדרת RBAC ב-Kubernetes: מדריך DevOps מעשי

מפתח מקבל גישה לאשכול הייצור ובטעות מוחק את מסד הנתונים תוך שעה. הסיבה—הרשאות RBAC מוגזמות. תקריות כאלה הן המציאות היומיומית שלנו. לפי הסטטיסטיקות שלנו, 7 מתוך 10 תקריות Kubernetes נגרמות כתוצאה מהגדרת גישה שגויה. הגדרת RBAC נכונה מפחיתה את סיכון התקריות פי 10. מדריך זה מכיל תצורות מוכחות שאנו משתמשים בהן בפרויקטים מסחריים. הזמינו ביקורת RBAC סוהרית—נעריך את התצורה שלכם תוך 2-3 ימים.

למה RBAC הוא התקן לבקרת גישה ב-Kubernetes

בניגוד ל-ABAC (בקרת גישה מבוססת תכונות), הדורשת הפעלה מחדש של שרת ה-API בכל שינוי, RBAC מתעדכן תוך כדי תנועה. זה מפחית את זמן התצורה ב-40% ומפשט את הביקורת. יתר על כן, RBAC מהיר פי 3 בניהול הרשאות.

איך RBAC עובד: נושאים, תפקידים, קישורים

RBAC הוא מנגנון בקרת גישה מבוססת תפקידים. ב-Kubernetes, הוא מורכב משלושה גורמים:

• נושאים: משתמש (אדם עם תעודה או טוקן), קבוצה (אוסף משתמשים), ServiceAccount (זהות עבור פודים).
• תפקידים: Role (הרשאות בתוך namespace אחד) ו-ClusterRole (הרשאות ברמת האשכול או למשאבים ברמת האשכול).
• קישורים: RoleBinding (מקשר נושא ל-Role או ClusterRole ב-namespace) ו-ClusterRoleBinding (מקשר נושא ל-ClusterRole ברמת האשכול).

טעות אופיינית היא שימוש ב-ClusterRoleBinding במקום שבו RoleBinding היה מספיק. אם מפתח צריך רק גישה ל-namespace של staging—השתמשו ב-RoleBinding, לא ב-ClusterRoleBinding. ClusterRoleBinding מעניק זכויות על פני כל האשכול—כמו שיש מפתחות לכל הדירות בבניין כאשר רק גישה לאחת נדרשת.

מתי להשתמש ב-ClusterRole במקום Role?

ClusterRole משמש למשאבים ברמת האשכול (nodes, PersistentVolumes) או לתפקידים סטנדרטיים (view, edit, admin) שניתן לקשר ל-namespace ספציפי דרך RoleBinding. Role מיועד רק למשאבים בתוך namespace. אם משאב אינו מוגבל ל-namespace (למשל, StorageClass), השתמשו ב-ClusterRole.

הגדרת RBAC שלב אחר שלב

שלב 1: זיהוי נושאים וצרכיהם

רשמו את כל המשתמשים, הקבוצות וה-ServiceAccounts שדורשים גישה. עבור כל אחד, ציינו את ה-namespace, המשאבים והפעולות (get, list, create, update, delete). השתמשו בעקרון ההרשאות המינימליות—זה מפחית את שטח התקיפה ב-80%.

שלב 2: יצירת תפקידים מינימליים

לעולם אל תשתמשו ב-"*" בפעלים או במשאבים. דוגמה למפתח—גישת קריאה בלבד ל-namespace של staging:

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer-readonly
  namespace: staging
rules:
  - apiGroups: [""]
    resources: ["pods", "services", "configmaps", "events"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["apps"]
    resources: ["deployments", "replicasets", "statefulsets"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["pods/log"]
    verbs: ["get", "list"]
  - apiGroups: [""]
    resources: ["pods/exec"]
    verbs: []

עבור ServiceAccount של CI/CD שמבצע פריסות לייצור, צרו תפקיד נפרד:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: deployer
  namespace: production
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "patch", "update"]
  - apiGroups: [""]
    resources: ["configmaps", "secrets"]
    verbs: ["get", "list", "create", "update", "patch"]
  - apiGroups: [""]
    resources: ["services"]
    verbs: ["get", "list", "create", "update", "patch"]
  - apiGroups: ["networking.k8s.io"]
    resources: ["ingresses"]
    verbs: ["get", "list", "create", "update", "patch"]

שלב 3: קישור נושאים לתפקידים

השתמשו ב-RoleBinding (עבור namespaces) או ב-ClusterRoleBinding (עבור כל האשכול). עבור מפתחים מקבוצת dev-team, העניקו את תפקיד edit דרך RoleBinding ב-namespace של dev:

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-team-edit
  namespace: dev
subjects:
- kind: Group
  name: dev-team
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io

למה חשוב להגביל הרשאות ServiceAccount

ServiceAccount עם הרשאות מוגזמות הוא הגורם העיקרי לתקריות אשכול. אם פוד נפרץ, התוקף מקבל גישה לכל המשאבים המותרים. לפי הנתונים שלנו, 70% מתקריות האבטחה של Kubernetes קשורות להגדרת RBAC שגויה. מזעור הרשאות מפחית סיכונים ב-80%.

איך להימנע מטעויות RBAC נפוצות

ביקורת ובדיקת הרשאות

apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: deployer namespace: production rules: - apiGroups: ["apps"] resources: ["deployments"] verbs: ["get", "list", "patch", "update"] - apiGroups: [""] resources: ["configmaps", "secrets"] verbs: ["get", "list", "create", "update", "patch"] - apiGroups: [""] resources: ["services"] verbs: ["get", "list", "create", "update", "patch"] - apiGroups: ["networking.k8s.io"] resources: ["ingresses"] verbs: ["get", "list", "create", "update", "patch"] הוא הכלי המרכזי. לבדיקה המונית, השתמשו ב-rbac-tool וב-rakkess:

# Что может ServiceAccount ci-deployer в namespace production?
kubectl auth can-i --list \
  --as=system:serviceaccount:production:ci-deployer \
  -n production

# Визуальный аудит через rbac-tool
rbac-tool lookup system:serviceaccount:production:ci-deployer

# Матрица доступа через rakkess
rakkess --as system:serviceaccount:production:ci-deployer -n production

השוואה בין Role ל-ClusterRole: מתי להשתמש באיזה

ClusterRole עם RoleBinding מעניק זכויות רק ב-namespace ספציפי—אידיאלי לתפקידים סטנדרטיים. ClusterRoleBinding—רק אם באמת נדרשות הרשאות גלובליות.

איך לשלב RBAC עם IdP חיצוני

Kubernetes אינו מאחסן משתמשים בעצמו—הוא סומך על IdP חיצוני. בעת שילוב עם Keycloak או Dex, קבוצות מ-OIDC ממוקמות ב-apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: dev-team-edit namespace: dev subjects: - kind: Group name: dev-team apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: edit apiGroup: rbac.authorization.k8s.io של הטוקן. RBAC עובד ישירות עם קבוצות אלה:

subjects: - kind: Group name: "oidc:backend-developers" apiGroup: rbac.authorization.k8s.io 

הגדרת kubectl auth can-i ב-kube-apiserver היא חובה למיפוי קבוצות נכון.

מה כלול בעבודת הגדרת RBAC

לצוות שלנו יש ניסיון של 7+ שנים ב-Kubernetes ו-50+ פרויקטי DevOps מיושמים. מנהלי Kubernetes המוסמכים שלנו מבטיחים ביקורת יסודית ותיקון. אנו מציעים:

1. ביקורת הרשאות נוכחיות—זיהוי הרשאות שאינן תואמות את עקרון ההרשאות המינימליות.
2. עיצוב תפקידים וקישורים לפי מבנה הצוות.
3. יצירת מניפסטים והחלתם על האשכול.
4. תיעוד: תיאורי תפקידים, מטריצת גישה, הוראות למפתחים.
5. הדרכת צוות—איך לבקש גישה ולהשתמש ב-kubectl auth can-i.
6. תמיכה—סיוע בהוספת משתמשים חדשים או שינוי הרשאות.

החיסכון הכספי מהגדרת RBAC נכונה יכול להגיע ל-50% מעלויות התקריות. עלות ביקורת RBAC מלאה מתחילה מ-500$ ומחושבת באופן אישי לאחר ניתוח התצורה והדרישות הנוכחיות. אנו נעריך את הפרויקט. הזמינו ביקורת RBAC סוהרית—צרו קשר לייעוץ.

לפי סקר משנת 2023, 60% מהארגונים חוו תקריות אבטחה ב-Kubernetes עקב RBAC שהוגדר שגוי. המומחיות שלנו בהגדרת בקרת גישה ל-Kubernetes עוזרת לכם להימנע מלהיות חלק מהסטטיסטיקה הזו.