Kyverno بالعربي: فرض سياسات Kubernetes بدون تعلم Rego

helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update
helm install kyverno kyverno/kyverno \
  --namespace kyverno \
  --create-namespace \
  --set replicaCount=3

الـ replicaCount=3 مش ترف — لو الـ webhook pod وقع، كل deploy في الـ cluster هيتعلّق. في production لازم 3 على الأقل موزّعين على nodes مختلفة.

أول سياسة فعلية: امنع image tag "latest"

ده policy بسيط بيرفض أي Pod containers بيستخدم :latest:

بعد kubectl apply -f policy.yaml، جرّب:

الرفض بيحصل في أقل من 20 ميلي ثانية، وسابق تمامًا لكتابة أي حاجة في etcd. يعني المطوّر بياخد feedback فوري بدل ما يكتشف بعد deploy.

Enforce vs Audit — الفرق اللي بيوفّر الـ incident

أي policy عنده وضعين أساسيين في validationFailureAction:

• Enforce: يرفض الـ resource فورًا. استخدمه في production بعد اختبار.
• Audit: يسجّل violation في PolicyReport بدون رفض. استخدمه أول يومين بعد إضافة policy جديدة.

من تجربة فريق عربي بيشتغل على cluster فيه 200 microservice: شغّلوا policy disallow-privileged بـ Audit لمدة 3 أيام الأول. الـ PolicyReport كشف 9 containers قديمة شغّالة بـ privileged: true بدون ما حد يعرف، واحد منهم في payment service. لو راحوا Enforce من أول يوم، كانوا هيوقفوا 9 services وقت الـ deploy الصبح. الـ Audit وفّرلهم incident كان هيكون P1.

3 سياسات هتحتاجها أول أسبوع

1. منع privileged containers: أي container فيه securityContext.privileged: true يترفض.
2. إلزام resource limits: كل container لازم يحدد cpu وmemory في resources.limits.
3. إلزام labels: كل Deployment لازم يحتوي app.kubernetes.io/name وowner علشان الـ cost allocation.

مثال على إلزام الـ limits:

الرمز ?* معناه "أي قيمة موجودة، ممنوع فاضي". بسيط، لكنه بيمنع أهم سبب في OOM kills وnoisy neighbor في cluster مشترك.

أرقام إنتاج حقيقية

القياس ده من cluster فيه 150 microservice و20 مهندس، بعد 60 يوم من Kyverno:

• عدد policies شغّالة: 23 policy، منها 18 Enforce و5 Audit.
• Latency مضاف على كل admission request: 12–18 ms P95.
• استهلاك memory لـ Kyverno controller: 380 MB لكل replica.
• Violations اتمنعت في 30 يوم: 47 حالة، منها 4 privileged containers.
• ساعات مراجعة يدوية اتوفّرت: حوالي 12 ساعة/أسبوع.

Trade-off ملموس: الـ 12–18 ms زيادة على كل request admission. لو عندك pipeline بيعمل deploy آلاف الـ Pods في الدقيقة (مثلًا batch jobs ضخمة)، الرقم ده ممكن يبقى ملحوظ. في الحالة دي فكّر في استثناء الـ namespace اللي بتشغّل الـ batch منه عبر exclude.

Mutation: مش بس رفض، Kyverno بيعدّل كمان

Kyverno مش Validator بس — بيقدر يضيف حاجات تلقائيًا. مثلًا سياسة بتضيف label environment: production لكل resource في namespace prod-*:

ده بيحل مشكلة "المطور نسي يضيف label"، بدون ما تعمل reject ويقطع عليه الـ flow.

متى لا تستخدم Kyverno

• Dev cluster صغير بمهندس واحد: overhead من غير قيمة.
• Kubernetes قديم أقل من 1.21: Kyverno الجديد مش مدعوم.
• سياسات محتاجة aggregation معقد عبر resources مختلفة: OPA Gatekeeper أقوى.
• بيئة بـ latency < 5 ms requirement على admission: الـ 12–18 ms ممكن يكون كتير.
• Clusters بـ batch jobs كثيفة جدًا (10K+ Pods/دقيقة) بدون تقسيم namespaces.

الخطوة التالية

ثبّت Kyverno في staging cluster النهارده، وطبّق disallow-latest-tag بوضع Audit. بعد 48 ساعة شغّل:

هتشوف بالظبط كام resource في cluster بيستخدم latest. لما تصلحهم واحد واحد، حوّل الـ policy لـ Enforce وعدّي على السياسة التانية. لو PolicyReport طلع فاضي من أول يوم، غالبًا الـ policy مش بيتطبّق صح — ابعتلي الـ output وهنشوفها سوا.

المصادر

• Kyverno Official Documentation — https://kyverno.io/docs/
• Kyverno Policies Library (سياسات جاهزة) — https://kyverno.io/policies/
• Kubernetes Admission Controllers Reference — kubernetes.io/docs
• Kyverno vs OPA Gatekeeper (CNCF Blog) — cncf.io/blog
• Pod Security Standards — kubernetes.io/docs/concepts/security
• Nirmata Production Case Studies مع Kyverno — nirmata.com/resources