Kyverno 1.19.2: عالج 24 نشرة أمنية بأمان

يمثل Kyverno 1.19.2 خط الأساس الأمني لمسار الإصدارات 1.19. ويذكر مشرفو المشروع أن الإصدار يعالج 24 نشرة أمنية منشورة على GitHub: تسع حرجة و14 عالية وواحدة متوسطة. تعبر عدة مشكلات حدود Namespace عندما يدفع مؤلف Policy محدود الصلاحيات أحد Controllers المميزين في Kyverno إلى تنفيذ بيانات يتحكم فيها؛ وتمس مشكلات أخرى التحقق من الصور، والسياسات المولدة، ومعالجة Wildcards والمتغيرات، وأتمتة المشروع.

تكون أولوية التحديث مرتفعة عندما يستطيع مستأجرون غير موثوقين أو شبه موثوقين إنشاء كائنات سياسات Kyverno. هذا الشرط لا يثبت حدوث اختراق، كما أن المواد الرسمية التي جرى التحقق منها في 6 نوفمبر 2026 لا تثبت استغلالًا نشطًا في بيئات العملاء. توثق نشرتان نجاح إعادة الإنتاج في عناقيد اختبار حية؛ وهذا يثبت قابلية الوصول إلى المسارين، لا اختراق عنقودك.

الحقائق الخاصة بالإصدار أدناه مأخوذة من نشرات Kyverno الرسمية. أما خطة الحصر والاحتواء والتحديث وجمع الأدلة فهي تحليل هندسي.

الإجابة أولًا

استخدم جدول القرار قبل تغيير الإنتاج:

صدر Kyverno v1.19.2 رسميًا في 20 أكتوبر 2026، ويوصي المشروع بالتحديث للحصول على الإصلاحات المذكورة. يقابله Helm chart 3.9.2. وتحذر وثائق التحديث الرسمية من اختزال العملية في تغيير Image tag، لأن الموارد المساندة وCRDs قد تتغير.

ماذا يصلح الإصدار الأمني؟

من الأفضل التعامل مع النشرات الأربع والعشرين كعائلات لحدود أمنية بدل قائمة مسطحة:

هذا التصنيف مهم. العنقود الذي لا يفوض إنشاء السياسات قد يملك مسار تعرض مختلفًا عن منصة متعددة المستأجرين، لكنه ما زال يحتاج الإصدار لأن مشكلات التحقق من الصور والتوليد والتوافر لها متطلبات أخرى.

مثالان حرجان لعبور Namespace

### يفحص apiCall مسارًا وينفذ مسارًا آخر

تؤثر النشرة GHSA-3xfv-vq8x-qhg4 في Kyverno حتى 1.19.1، وأُصلحت في 1.19.2. وتوضح أن مستخدمًا محدودًا بـNamespace ويستطيع إنشاء Policy محلية يمكنه إخفاء مقاطع traversal خلف فاصل fragment أو query. ينظف الفحص تمثيلًا للمسار، بينما ينفذ Kubernetes client التمثيل الخام بعد تجاهل fragment أو query.

يُنفذ الطلب بصلاحيات ServiceAccount الخاصة بـAdmission Controller. وتذكر النشرة أن الحساب يستطيع إنشاء إعدادات Admission وPolicyException على مستوى العنقود، ما ينتج مسارًا عمليًا إلى Cluster Admin. تحقق الباحثون من المشكلة على تثبيت Helm افتراضي لـKyverno 1.19.1 داخل kind.

توثق النشرة المرتبطة GHSA-39w8-hv5g-f73w صيغة تعتمد percent-escape غير صالح في 1.19.1. الدرس الهندسي أوسع من URL parsing: يجب أن يعمل الفحص الأمني والتنفيذ على التمثيل القانوني نفسه.

### تختار NamespacedMutatingPolicy هدفًا خارج نطاقها

تؤثر GHSA-jcw5-3wcg-fqx5 في الإصدارات بدءًا من 1.18.0، وأُصلحت في 1.19.2. تصف النشرة NamespacedMutatingPolicy مع تفعيل mutate-existing تستطيع تركيب Target عبر CEL expression. ومع غياب فحص لكل Target يثبت Namespace والنطاق، يستطيع Background Controller كتابة النتيجة بصلاحيات ServiceAccount المميزة.

الشرط المهم هو صلاحية إنشاء Resource الخاص بالسياسة المحلية. وقد يشمل الأثر الكتابة فوق Roles أو RoleBindings أو NetworkPolicies أو ConfigMaps خارج Namespace المهاجم، وفق الصلاحيات الفعلية للـController. اختبر الشرط باستخدام نموذج RBAC الحقيقي؛ لا تفترض أن «Namespace admin» تعني الشيء نفسه في كل منصة.

احصر الواقع قبل الاحتواء

أنشئ سجل أدلة لكل عنقود:

{
  "cluster": "prod-eu-1",
  "install_method": "helm",
  "chart": "kyverno-3.9.1",
  "app_version": "1.19.1",
  "controllers": ["admission", "background", "cleanup", "reports"],
  "policy_authors": ["platform-team", "tenant-admins"],
  "namespaced_policy_types": ["Policy", "NamespacedMutatingPolicy"],
  "image_verification": true,
  "artifact_digests": ["sha256:..."],
  "rollback_revision": "42"
}

هذا مخطط حصر داخلي، وليس ملف إعداد Kyverno.

اجمع الأدلة من العنقود الحي:

helm list -A | grep -i kyverno
kubectl api-resources | grep -i kyverno
kubectl -n kyverno get deploy,pod -o wide
kubectl -n kyverno get deploy -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{range .spec.template.spec.containers[*]}  {.name}{" "}{.image}{"\n"}{end}{end}'
kubectl get clusterrole,clusterrolebinding | grep -i kyverno

ثم اسأل Kubernetes authorization عن هويات ممثلة وباستخدام أسماء الموارد الدقيقة التي أعادها api-resources:

kubectl auth can-i create policies.kyverno.io --as=alice -n tenant-a
kubectl auth can-i create namespacedmutatingpolicies.policies.kyverno.io --as=alice -n tenant-a

احصر أيضًا GitOps manifests وHelm values وملكية CRDs وعناقيد التعافي من الكوارث وArtifacts الخاصة بالرجوع. وجود قيمة 1.19.2 في المستودع لا يثبت أن كل Controller حي يستخدمها.

احتواء لا يمحو الأدلة

إذا تعذر التحديث الفوري:

1. أزل أو قيّد بدقة صلاحيات create وupdate غير الموثوقة لأنواع سياسات Kyverno المحلية. استخدم موارد API المثبتة فعليًا.
2. جمّد تغييرات السياسات الجديدة وراجع التعديلات الأخيرة على Policy وNamespacedMutatingPolicy وCleanupPolicy وPolicyException وسياسات التحقق من الصور.
3. احفظ Kubernetes audit logs وسجلات Controllers وقرارات Admission وتاريخ GitOps وImage digests قبل تدوير Pods.
4. راجع طلبات API الصادرة عن ServiceAccounts الخاصة بـKyverno بحثًا عن كتابة غير متوقعة بين Namespaces أو على مستوى العنقود.
5. احمِ توافر Admission. لا تحذف Webhooks أو Controllers عشوائيًا؛ فقد تنشئ حالة fail-open أو fail-closed حادثًا ثانيًا.

هذه إجراءات لتقليل الخطر، وليست بديلًا عن 1.19.2. إذا وجدت نشاطًا مشبوهًا، اتبع خطة الاستجابة ودوّر Credentials المتأثرة بعد حفظ الأدلة اللازمة لتحديد النطاق.

حدّث Kyverno كنظام كامل

للتثبيت عبر Helm، ثبّت chart 3.9.2 أو إصدارًا مدعومًا أحدث يحمل Kyverno 1.19.2 أو أحدث. صدّر القيم الحالية واقرأ Release notes قبل التطبيق. يقدم Kyverno 1.19 اعتمادًا مستقلًا باسم kyverno-api لإدارة CRDs؛ لذلك يجب على الفرق التي تستخدم crds.install=false أو تدير CRDs منفصلة تحديث هذا المسار صراحة.

نفّذ التغيير أولًا في عنقود غير إنتاجي ممثل:

1. انسخ Helm values والسياسات وإعداد إدارة CRDs.
2. حدّث chart وCRDs بالطريقة الرسمية المدعومة.
3. انتظر اكتمال Rollout لكل Deployment وسجل Image digests الجديدة.
4. اختبر حالات قبول ورفض للتحقق والتحوير والتوليد والتحقق من الصور والاستثناءات والتنظيف بحسب الميزات المستخدمة.
5. اختبر هوية مستأجر يفترض السماح لها بإنشاء Policy محلية وأخرى يجب رفضها. أثبت أن Policy محلية لا تقرأ أو تحور Namespace أخرى.
6. رقِّ عبر مجموعات عنقود، وراقب Admission latency ونسبة الرفض وأخطاء Controllers وPolicy reports، وحدد نافذة قرار واضحة للرجوع.
7. لا ترجع إلى 1.19.1 أو Artifact أقدم متأثرة. إذا منع تراجع وظيفي الترقية، فقيّد إنشاء السياسات وصعّد للمورد مع الحفاظ على الحد الأمني المصحح.

عقد التحقق

لا تصف النشر بأنه مصحح إلا عند نجاح أربع طبقات:

• Artifact: كل صورة Controller تطابق Digest المعتمد، وHelm release أو manifest يطابق إعداد 1.19.2 المراجع.
• Runtime: لا Pod أو cache أو عنقود خامل أو Job أو Rollback revision يمكنه إعادة Controller متأثرة.
• السلوك: تبقى اختبارات السياسات المحلية محصورة؛ ويعمل التحقق من الصور والاستثناءات والتوليد والتنظيف كما قصدت.
• الأدلة: لا تظهر Audit وController logs طلبات مميزة غير مفسرة خلال نافذة المراجعة.

لا تشغل Proof of Concept عامًا على الإنتاج. أنشئ اختبارًا سلبيًا صغيرًا يثبت أن المستأجر لا يستهدف Namespace أخرى، ونفذه في عنقود معزول بـRBAC ممثل.

أفضل الممارسات والأنماط المضادة والحدود

أفضل الممارسات:

• اعتبر كتابة السياسات كودًا مميزًا يحتاج مراجعة حتى لو كانت Policy محلية.
• قلل صلاحيات كل Controller ServiceAccount وراقب تغييرات Roles المجمعة.
• ثبّت الصور بالـDigest وأدرج كل Controllers في مخزون البرمجيات.
• ضع اختبارات أمن Admission بجانب تغييرات policy-as-code.
• افصل نجاح التحديث عن اكتمال تقييم الاختراق.

تجنب هذه الأنماط:

• «لا نستخدم ClusterPolicy، إذن لا يؤثر مؤلف Policy محلية في العنقود».
• تحديث Admission Controller فقط مع بقاء Background أو Cleanup قديمًا.
• تغيير Image tag وحدها دون chart وCRDs والموارد المساندة.
• إعلان اختراق لمجرد وجود نسخة متأثرة، أو إعلان الأمان لأن التنبيه لم يظهر.
• تعطيل Kyverno عالميًا دون فهم Webhook failure policy واعتماديات Admission.

يعالج Kyverno 1.19.2 النشرات المدرجة في Release notes، لكنه ليس برهانًا عامًا على أمان كل Policy مخصصة أو RBAC binding أو Webhook خارجي. تظل الإصدارات المختلطة والصلاحيات الزائدة ومنطق السياسات غير المراجع مخاطر تشغيلية.

قائمة تنفيذية

• أكد وجود Kyverno وسجل نسخة وDigest كل Controller.
• حدد من يستطيع إنشاء أو تعديل موارد سياسات Kyverno المحلية.
• قيّد التأليف الخطر مع حفظ Audit وController evidence.
• حدّث التثبيت كاملًا إلى 1.19.2/chart 3.9.2 أو إصدار ثابت مدعوم أحدث.
• اختبر حصر Namespace وكل عائلة سياسات مستخدمة في Canary cluster.
• احذف Rollback artifacts المتأثرة وتحقق من كل Controller حي.
• حقق في الأدلة منفصلة عن حالة التحديث؛ لا تستنتج استغلالًا نشطًا.

لتحصين قريب، راجع دليل تدوير شهادات Kubernetes، وخطة تحديث Next.js 16.4.1، ودليل تحديث ClickHouse الحرج. تغطي خدمة هندسة السحابة والأداء تصميم Rollout والمراقبة في الإنتاج.

المراجع

• ملاحظات إصدار Kyverno v1.19.2
• نشرات Kyverno الأمنية
• GHSA-3xfv-vq8x-qhg4: تصعيد عبر Policy apiCall
• GHSA-39w8-hv5g-f73w: تجاوز malformed percent-escape
• GHSA-jcw5-3wcg-fqx5: mutate-existing عابر للـNamespace
• وثائق تحديث Kyverno
• صورة الغلاف وسجل الترخيص — Carl Lender، Wikimedia Commons.jpg)

إعداد: Noor Yasser

إعداد: Noor Yasser