يرى Koray Oksay، سفير CNCF، أن المؤسسات تضع Kyverno غالباً تحت مسؤولية فرق الأمن، فتستخدمه للتحقق من إعدادات Kubernetes وحظر الحاويات التي تعمل بصلاحيات الجذر أو تفرض معايير أمان الحاويات، ثم تترك جانباً كبيراً من إمكاناته. ووفقاً لطرح Oksay، فإن هذا التصنيف الذهني يحصر Kyverno في دور «بوابة» تمنع الإعدادات السيئة، بينما يمكن استخدامه كلبنة أساسية تبني عليها فرق المنصات خدماتها وقواعدها التشغيلية.
يستند هذا الرأي إلى تجربة الكاتب التي بدأت بعرض في مؤتمر KCD Munich عام 2023 حمل عنوان «تأمين أحمال Kubernetes باستخدام Kyverno». وبعد ثلاث سنوات من العمل في بيئات إنتاجية، يقول إن اهتمامه انتقل إلى الحوكمة وCEL والخدمة الذاتية للمنصات، وإن وصف Kyverno بأنه «محرك سياسات» لم يعد كافياً لتغطية نطاقه.
لماذا لا يكفي التصنيف الأمني؟
لا ينفي Oksay الوظائف الأمنية لـ Kyverno. فالمنصة تستطيع حظر الإعدادات غير الآمنة، وفرض Pod Security Standards، والتحقق من توقيعات صور الحاويات. لكن ربطها بالأمن وحده يرسخ نموذجاً يرى السياسة بوصفها حاجزاً هدفه الأساسي الرفض، بحيث يقاس النجاح بعدد عمليات النشر التي جرى منعها.
في المقابل، يحدد الكاتب أربع وظائف رئيسية لـ Kyverno: التحقق، والتعديل، والتوليد، والتحقق من الصور. تنتمي وظيفة التحقق مباشرة إلى نموذج الحاجز، أما التعديل فيغيّر الموارد قبل إدخالها إلى العنقود، والتوليد ينشئ موارد جديدة استجابة لأحداث معينة، بينما يركز التحقق من الصور على بناء الثقة بها، لا على حظر التهديدات فقط. لذلك يرى أن ثلاثاً من الوظائف الأربع ذات طبيعة بنّاءة، لكن كثيراً من المؤسسات لا تستخدم سوى سياسات التحقق.
ما المقصود بمكوّن أساسي للمنصة؟
يستخدم Oksay تعبير «مكوّن أساسي» بالمعنى القريب من استخدامه في لغات البرمجة: لبنة صغيرة ومفهومة يمكن تركيبها لبناء أنظمة أكبر. ولكي تؤدي هذه اللبنة دوراً فعلياً في المنصة، ينبغي أن تخفي التعقيد عن المطورين، وتقدم ضمانات تلقائية، وتتكامل مع لبنات أخرى، وتكون متاحة بالخدمة الذاتية بدلاً من الاعتماد على طلبات يدوية أو طوابير دعم.
وبهذا المعنى، تشبه سياسات Kyverno مكونات مثل Pods وServices وConfigMaps وتركيبات Crossplane. فهي تحول القواعد التي تتبناها المؤسسة إلى سلوك تلقائي داخل المنصة.
كيف تستخدمه فرق المنصات؟
- تجهيز مساحات الأسماء: عند إنشاء مساحة أسماء، يستطيع Kyverno توليد NetworkPolicy وResourceQuota وLimitRange وRoleBindings الافتراضية، بحيث تظهر المساحة مجهزة من دون مطالبة المطور بتذكر قائمة من الخطوات اليدوية.
- حقن الحاويات الجانبية: يمكن إضافة وكلاء المراقبة أو وكلاء الشبكات أو حاويات مزامنة الأسرار إلى مواصفات Pod أثناء مرحلة القبول، مع إبقاء ملف Deployment بسيطاً.
- إعادة كتابة مراجع الصور: يمكن تحويل مرجع مثل nginx:1.25 إلى mirror.internal/nginx:1.25 كي تمر عمليات السحب عبر مرآة داخلية، بدلاً من مطالبة كل مطور بإضافة البادئة يدوياً.
- إضافة طلبات الموارد الافتراضية: بدلاً من حظر Pods التي لا تحدد طلبات CPU والذاكرة، يمكن حقن قيم مناسبة ثم تعديلها عند الحاجة.
- تعيين وسوم الملكية: يمكن إضافة وسوم الفريق ومركز التكلفة والبيئة عندما تكون القيم واضحة، أو فرضها عندما يكون الغموض مؤثراً.
ما الذي يتغير عملياً؟
تجمع هذه الاستخدامات فكرة واحدة: تحويل قناعة تنظيمية إلى ضمان آلي غير مرئي. فقد تكون القاعدة أمنية، مثل منع الحاويات ذات الصلاحيات العالية، أو تشغيلية، مثل فرض حدود الموارد، أو مالية، مثل ربط كل مورد بوسم مركز تكلفة. بدلاً من بقاء هذه القواعد في الويكي أو قوائم المراجعة أو معرفة مهندس واحد، تصبح سياسة مكتوبة ككود، محفوظة في Git، ومطبقة عبر أدوات GitOps وKyverno.
يقترح هذا المنظور التعامل مع السياسة باعتبارها واجهة المنصة للتعبير عن نية المؤسسة. وعند تطبيقه، تتحول وظائف Kyverno إلى مستويات مختلفة: التحقق يوفر حواجز حماية، والتعديل يرسم «طرقاً ممهدة» للمطورين، والتوليد يقدم قوالب أو تجهيزات أولية، والتحقق من الصور يبني الثقة.
كما ستتعامل الفرق مع السياسات بوصفها منتجات لها إصدارات ومستخدمون ودورات إيقاف واستثناءات قابلة للتتبع. ويمكن أن يبدأ نشر السياسة بالتدقيق، ثم التحذير، ثم الفرض التدريجي. ويشير الكاتب أيضاً إلى تحديات تنسيق محتملة عندما تعدّل سياسة مورداً تعتبره Argo CD أو Flux مملوكاً لها، بما قد يؤدي إلى حلقات مزامنة.
الخلاصة التي يقدمها Oksay هي أن قراءة Kyverno كدليل أمني فقط تحجب جزءاً كبيراً من واجهته وإمكاناته. فهو، في رأيه، ليس حارساً يقف عند مدخل العنقود، بل طبقة تربط آراء فريق المنصة بالسلوك الفعلي للموارد والتطبيقات.