كيف يعمل RBAC مع ServiceAccounts، وكيف تؤمّن عنقود (cluster) Kubernetes؟

Question

IT Interview Practice · Accepted Answer

يحكم الـ **RBAC (التحكّم في الوصول القائم على الأدوار)** *مَن يستطيع فعل ماذا* على واجهة الـ API. تُمنَح الصلاحيات لـ **الأشخاص/الكيانات (subjects)** (مستخدمين، مجموعات، **ServiceAccounts**) عبر **ربطهم (binding)** بـ **Roles** تسرد الأفعال (verbs) المسموح بها على الموارد. الـ RBAC طبقة واحدة من استراتيجية أوسع لتقوية العنقود (cluster-hardening).

## نموذج RBAC

```text
SUBJECT (user / group / ServiceAccount)
   │  bound by
   ▼
RoleBinding ───────► Role         (namespaced: permissions within ONE namespace)
ClusterRoleBinding ► ClusterRole  (cluster-wide, or reusable across namespaces)

Role/ClusterRole = a set of RULES: "these VERBS on these RESOURCES"
Bindings are ADDITIVE and there is NO deny — you grant only what's needed.
```

## مثال Role + RoleBinding

```yaml
# Role: وصول للقراءة فقط إلى الـ Pods في namespace اسمه "app"
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: app
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
---
# ربط ذلك الـ Role بـ ServiceAccount
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: app
  name: read-pods
subjects:
  - kind: ServiceAccount
    name: my-app
    namespace: app
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
```

## ServiceAccounts: هويّة للـ Pods

```text
A ServiceAccount is the IDENTITY a Pod uses to talk to the API server.
  → Every Pod gets one (the namespace "default" SA if unspecified).
  → A projected token is mounted into the Pod; RBAC decides what that token can do.
Best practice: give each workload its OWN SA with least-privilege RBAC,
and set automountServiceAccountToken: false when the Pod doesn't need API access.
```

```yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: my-app, namespace: app }
automountServiceAccountToken: false   # إلغاء الاشتراك إن لم تلزم استدعاءات API
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # تشغيل الـ Pods تحت هذه الهويّة
```

## الدفاع في العمق — ما وراء RBAC

```text
AUTH        → least-privilege RBAC; per-workload ServiceAccounts; audit access
NETWORK     → default-deny NetworkPolicies (Pods can't talk unless allowed)
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, drop capabilities
              seccomp profiles; Pod Security Admission (restricted) to enforce
SECRETS     → encryption at rest for etcd; external secret managers; tight RBAC on secrets
IMAGES      → scan images, use trusted registries, enforce with admission (e.g. policy engines)
API/etcd    → restrict & encrypt etcd; TLS everywhere; limit anonymous & cluster-admin access
SUPPLY CHAIN→ signed images, admission control (OPA/Gatekeeper, Kyverno)
```

```bash
kubectl auth can-i list pods --as=system:serviceaccount:app:my-app -n app
kubectl auth can-i --list -n app          # ماذا يستطيع المستخدم الحالي أن يفعل؟
```

## لماذا يهم

تأمين العنقود مسؤولية بمستوى كبير (senior)، والـ RBAC مع ServiceAccounts أساسها، لذا فإن فهم كليهما معرفة أمنية ضرورية. نموذج RBAC أنيق يستحقّ الاستيعاب: فالصلاحيات **تراكمية بحتة دون رفض (deny)**، تُمنَح بـ**ربط الأشخاص/الكيانات** (مستخدمين، مجموعات، وخصوصاً **ServiceAccounts**) بـ **Roles** (ضمن namespace) أو **ClusterRoles** (على مستوى العنقود) تُعدِّد **الأفعال المسموح بها على الموارد** — ما يعني أن الأمن الجيّد يأتي من منح ما يحتاجه كل workload فقط (**أقلّ امتياز، least privilege**) لا من الاعتماد على الرفض. إن فهم أن **الـ ServiceAccount هو الهويّة التي يستخدمها الـ Pod لاستدعاء الـ API** — وأن كل Pod يحصل على رمز (token)، وأن الـ SA الافتراضي `default` مصيدة امتياز مفرط شائعة، وأنه ينبغي منح كل workload الـ SA الخاص به بأقلّ امتياز (وتعطيل التركيب التلقائي للرمز حين لا يلزم وصول API) — أمرٌ عملي مباشرة ومصدر شائع لسوء الإعداد في الواقع. وبشكل حاسم، يعرف المهندس الكبير أن RBAC ليس سوى طبقة واحدة من **الدفاع في العمق**: فالـ **NetworkPolicies** بمبدأ الرفض الافتراضي، وإعدادات **securityContext** المُقوّاة (غير الجذر، نظام ملفات جذري للقراءة فقط، إسقاط القدرات، seccomp)، و**Pod Security Admission**، و**التشفير أثناء السكون** والمديرون الخارجيون للأسرار، وفحص الصور وتوقيعها، وأدوات القبول (OPA/Gatekeeper، Kyverno)، والوصول المُقيَّد إلى etcd/API، كلها تتضافر لحماية العنقود. ولأن عنقود Kubernetes هدف عالي القيمة حيث يمكن أن يؤدّي ServiceAccount مفرط الصلاحيات واحد أو NetworkPolicy مفتوح إلى اختراق كامل، فإن إتقان RBAC ومجموعة أدوات التقوية الأوسع أساسٌ لتشغيل العناقيد بأمان في الإنتاج.

نموذج RBAC

مثال Role + RoleBinding

ServiceAccounts: هويّة للـ Pods

الدفاع في العمق — ما وراء RBAC

لماذا يهم

أسئلة ذات صلة