عمليات Kubernetes المتقدمة

التحكم في الوصول المبني على الأدوار بعمق

18 دقيقة الدرس 1 من 30

التحكم في الوصول المبني على الأدوار بعمق

التحكم في الوصول المبني على الأدوار (RBAC) هو آلية التفويض الرئيسية في Kubernetes. كل مجموعة عقد إنتاجية — من نشر شركة ناشئة بعشرة عقد إلى أساطيل تضم آلاف العقد في كبرى شركات الحوسبة السحابية — تعتمد على صحة إعداد RBAC. الخطأ في هذا الإعداد إما يحجب المهندسين عن مجموعاتهم، أو ما هو أشد خطورةً: يمنح الحمولات المخترقة صلاحية قراءة الأسرار عبر كل نطاق أو الوصول إلى مستوى التحكم.

يبني هذا الدرس نموذجاً ذهنياً متكاملاً: ما الذي يفحصه RBAC، وكيف يقيّمه خادم API، وكيف يصمم مهندسو SRE كبار سياسات أدنى صلاحية تصمد أمام مراجعات الأمان.

كيف يقيّم خادم API الطلبات

كل طلب يصل إلى خادم Kubernetes API يمر عبر مسار: المصادقة → التفويض → التحكم في القبول. يقع RBAC في مرحلة التفويض. يطرح خادم API سؤالاً واحداً: "هل تملك هذه الهوية، التي تعمل على هذا المورد في هذا النطاق، صلاحية تنفيذ هذا الفعل؟"

Kubernetes يرفض بشكل افتراضي. لا يُسمح بأي طلب إلا إذا منحته سياسة RBAC صراحةً. لا يوجد مفهوم لقواعد الرفض — تُنمّذج القيود ببساطة بعدم منح الصلاحية أصلاً.

مسار طلب Kubernetes API: المصادقة → تفويض RBAC → التحكم في القبول → etcd.

الكائنات الأربعة الأساسية لـ RBAC

يستخدم RBAC أربعة أنواع من الموارد مرتبة في زوجين:

Role — يمنح صلاحيات داخل نطاق واحد.
ClusterRole — يمنح صلاحيات على مستوى المجموعة كاملة، أو على الموارد غير المحددة بنطاق كالعقد وحجوم التخزين الدائمة والنطاقات ذاتها.
RoleBinding — يربط Role أو ClusterRole بالمستخدمين داخل نطاق واحد.
ClusterRoleBinding — يربط ClusterRole بالمستخدمين على مستوى المجموعة كاملة.

النمط الشائع في بيئات الإنتاج هو تعريف ClusterRole مرة واحدة (مثلاً pod-reader) ثم استخدام RoleBinding لكل نطاق لمنحه فقط حيثما تقتضي الحاجة، مما يتفادى تكرار مانيفستات الأدوار عبر عشرات النطاقات.

الكيانات: المستخدمون والمجموعات وحسابات الخدمة

تُربط الصلاحيات بثلاثة أنواع من الكيانات:

User — هوية إنسانية تؤكدها آلية المصادقة (حقل CN في الشهادة أو مطالبة sub في OIDC). لا يوجد مورد User في Kubernetes؛ الاسم مجرد نص.
Group — مجموعة مستخدمين، تستند عادةً إلى مطالبات مجموعات OIDC أو حقل Organization في الشهادة. الارتباط بالمجموعات (مثل team-platform) أسهل صيانةً بكثير من الارتباط بمستخدمين فرديين.
ServiceAccount — كائن Kubernetes محدد بنطاق، يُثبَّت تلقائياً كرمز JWT مسقط في كل حاوية. هذه هي الطريقة التي تتحقق بها الحمولات من هويتها لخادم API وقت التشغيل.

البادئة system: محجوزة. الكيانات المدمجة مثل system:authenticated وsystem:serviceaccounts:kube-system وsystem:masters يديرها Kubernetes. لا تنشئ مستخدمين أو مجموعات مخصصة بهذه البادئة — قد تتعارض مع الارتباطات الداخلية أو تتسبب في كسر ترقية المجموعة.

كتابة مانيفستات أدنى صلاحية

الخط الأساسي في الإنتاج: تعمل كل حمولة تحت حساب خدمة خاص بها مع الأفعال التي تحتاجها فعلياً فحسب. يثبّت default ServiceAccount في كل نطاق رمزاً تلقائياً — عطّل هذا السلوك للحمولات التي لا تستدعي Kubernetes API.

# إنشاء ServiceAccount مخصص
kubectl create serviceaccount metrics-reader -n monitoring

---
# Role: وصول للقراءة فقط على الحاويات وسجلاتها في نطاق monitoring
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-log-reader
  namespace: monitoring
rules:
  - apiGroups: [""]          # مجموعة API الأساسية
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]

---
# ربط الدور بحساب الخدمة
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: metrics-reader-pod-logs
  namespace: monitoring
subjects:
  - kind: ServiceAccount
    name: metrics-reader
    namespace: monitoring
roleRef:
  kind: Role
  name: pod-log-reader
  apiGroup: rbac.authorization.k8s.io

---
# Deployment يستخدم حساب الخدمة
apiVersion: apps/v1
kind: Deployment
metadata:
  name: metrics-collector
  namespace: monitoring
spec:
  template:
    spec:
      serviceAccountName: metrics-reader
      automountServiceAccountToken: true   # true فقط لأن هذه الحاوية تحتاج وصول API

عطّل التثبيت التلقائي عالمياً وفعّله لكل حاوية. في مواصفات ServiceAccount اضبط automountServiceAccountToken: false كقيمة افتراضية. ثم اضبط automountServiceAccountToken: true فقط على الحاويات التي تستدعي Kubernetes API فعلياً. هذا يزيل سطح الهجوم على رموز الحاويات الدفعية وواجهات المستخدم الأمامية وحمولات قواعد البيانات.

ClusterRoles المجمّعة

يُزوّد Kubernetes بثلاثة ClusterRoles افتراضية للبشر: view وedit وadmin. تستخدم التجميع — محدد تسميات يسحب تلقائياً قواعد أي ClusterRole يحمل تسمية مطابقة. عند تثبيت CRD وتريد رؤيته للمستخدمين الذين يملكون view، أضف هذا إلى ClusterRole الخاص بـ CRD:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: my-operator-view
  labels:
    rbac.authorization.k8s.io/aggregate-to-view: "true"   # يُدمج تلقائياً في دور view المدمج
rules:
  - apiGroups: ["mycompany.io"]
    resources: ["myresources"]
    verbs: ["get", "list", "watch"]

مراجعة الصلاحيات: من يستطيع فعل ماذا؟

قبل أي إطلاق إنتاجي أو مراجعة امتثال، عليك تعداد ما تستطيع كل هوية فعله بالضبط. kubectl auth can-i يجيب على أسئلة منفردة، بينما تمنحك إضافتا rakkess وkubectl-who-can عرضاً مصفوفياً شاملاً.

# هل يستطيع المستخدم الحالي إنشاء deployments في نطاق الإنتاج؟
kubectl auth can-i create deployments -n production

# انتحال هوية ServiceAccount لمراجعة صلاحياته
kubectl auth can-i list secrets \
  --as=system:serviceaccount:monitoring:metrics-reader \
  -n production

# سرد كل الكيانات القادرة على حذف الحاويات في نطاق الإنتاج
# (تتطلب إضافة kubectl-who-can: kubectl krew install who-can)
kubectl who-can delete pods -n production

# تعداد كل صلاحيات ServiceAccount (تتطلب إضافة rakkess)
kubectl rakkess --sa monitoring:metrics-reader

# التحقق من تفعيل RBAC على مستوى المجموعة
kubectl api-versions | grep authorization.k8s.io

احذر أحرف البدل * وأفعال escalate/bind. دور يحمل verbs: ["*"] أو resources: ["*"] هو مشرف مجموعة فعلي ضمن نطاقه. يتيح فعل escalate للكيان إنشاء Roles بصلاحيات أكبر مما يملكه؛ ويتيح فعل bind إرفاق ClusterRoles بكيانات اعتباطية. كلاهما ثغرة لرفع الصلاحيات يجب ألا تظهر في أدوار المطورين. اجعل مراجعتهما دورية.

مبادئ أدنى صلاحية على نطاق واسع

تُشغّل المؤسسات الكبيرة RBAC عبر أنماط مجرّبة:

إدارة كل مانيفستات RBAC عبر GitOps. خزّن كل Role وClusterRole وRoleBinding وClusterRoleBinding في Git. لا kubectl create role يدوي في الإنتاج — طلبات الدمج تفرض مراجعة الأقران، والانحراف يُكشف تلقائياً.
عزل نطاق لكل فريق. كل فريق يملك النطاقات المخصصة له فحسب؛ حسابات خدمته لا تملك صلاحيات عبر النطاقات. خدمات المنصة المشتركة تستخدم نطاقات مخصصة بارتباطات محددة النطاق.
تصعيد مؤقت محدود بوقت. في سيناريوهات كسر الزجاج، امنح cluster-admin عبر ClusterRoleBinding مرتبط بـ TTL، أو استخدم أدوات مثل Teleport للوصول في الوقت المناسب الذي يُلغى تلقائياً بعد انتهاء الجلسة.
مراجعات صلاحيات دورية. شغّل kubectl auth reconcile --dry-run لكشف الانحراف. جدوِل مراجعات ربع سنوية تقارن الارتباطات الحالية بالحالة المُعلنة في GitOps وتُعلّم حسابات الخدمة التي تملك صلاحيات secrets get أو create على مستوى النطاق.

RBAC لا يقيّد حركة مستوى البيانات. يستطيع Pod بلا صلاحيات RBAC فتح اتصالات TCP مع حاويات أخرى. سياسات الشبكة (الدرس الخامس في درس الشبكات) وشبكات الخدمة المتبادلة TLS تتولى تفويض الحمولة إلى الحمولة — RBAC يحكم وصول Kubernetes API فحسب.

إتقان RBAC هو ما يميز المهندسين القادرين على نشر Kubernetes عن أولئك القادرين على تشغيله بأمان. كل مفهوم في هذا الدرس — خطافات القبول، والمشغّلون المخصصون، وتعدد الإيجار — يرتكز على أساس RBAC الذي بنيته هنا.