الخلاصة
- تربط
ValidatingAdmissionPolicyBindingالسياسة بنطاق محتمل وموارد معلمات اختيارية وأفعال معلنة؛ وليست سجلاً لنتيجة طلب API معين. - تفصل وثائق Kubernetes بين مطابقة الموارد، وحل المعلمات، وتقييم التعبير، ومعالجة الإخفاق، والفعل المختار، واستجابة الطلب.
- الدليل القابل للمراجعة يحتفظ ببيان الإعداد ونتيجة الطلب في سجلين مستقلين بدلاً من جعل أحدهما شاهداً على الآخر.
قد يبدو الربط دليلاً نهائياً عند قراءته من شاشة الإعداد. يوجد اسم سياسة، وحدود لنطاق الموارد، وأفعال تسمى Deny أو Warn أو Audit. ومن السهل أن تتحول هذه العناصر في التقرير إلى عبارة: «الضابط مفروض». لكن الربط يصف اتصالاً مقصوداً بين منطق سياسة ونطاق ومعلمات محتملة. لا يذكر هوية طالب، ولا وقت طلب، ولا كائناً محدداً، ولا يثبت أن خادم API أعاد رفضاً أو تحذيراً أو حفظ مورداً.
تضع واجهة Kubernetes حدّاً واضحاً عند المطابقة. فـ ValidatingAdmissionPolicyBinding تربط ValidatingAdmissionPolicy بموارد ذات معلمات، ويُقاطع matchResources في الربط مع matchConstraints في السياسة. لا يصل الطلب إلى اختيار الربط إلا بعد أن يطابق جانب السياسة أولاً. يشرح ذلك أي طلب قد يدخل مسار التقييم، ولا يثبت أن طلباً واقعياً دخل التقاطع. قد لا يصل طلب مناسب أصلاً؛ وقد يقع الطلب خارج المطابقة؛ وقد يتغير أو يُرفض لاحقاً في موضع آخر من مسار القبول.
وتؤكد المعلمات أن الإعداد ليس نتيجة. يستطيع الربط أن يشير إلى مورد يستخدم لضبط السياسة. تفرق الوثائق بين مرجع موجود ومرجع غير موجود؛ وقد يجعل غياب المرجع الربط غير مضبوط فتغدو سياسة الإخفاق ذات صلة. هذه حقائق منفصلة عن السياسة والربط ومورد المعلمة وحالة الإخفاق. حفظها مفيد لمعرفة ما كان معلناً، لكنه لا يثبت أن حمولة بعينها سُمح لها أو مُنعت، ولا أن هدفاً أمنياً تحقق.
كذلك لا ينبغي تحويل failurePolicy إلى اسم آخر لفشل التحقق العادي. توثق Kubernetes هذا الحقل لأخطاء التحليل وفحص الأنواع ووقت التشغيل والإعداد. أما عندما تقيّم عبارة التحقق إلى false، فإن validationActions في الربط هي التي تعلن طريقة المعالجة. يشير Deny إلى رفض الطلب عند فشل التحقق، وWarn إلى إرسال تحذير إلى العميل، وAudit إلى إدراج معلومات الفشل في حدث تدقيق الطلب. ليست هذه ثلاث صيغ لعبارة «محمي». إنها طبقات مختلفة: خطأ أو نتيجة تعبير أو فعل معلن أو أثر مرتبط بطلب.
وموضع القبول في دورة الطلب يحد ما يمكن نسبته إلى الربط. تشرح Kubernetes أن متحكمات القبول تعمل بعد المصادقة والتفويض وقبل الحفظ. وتنفصل مرحلتا التعديل والتحقق، ويرفض الطلب إذا رفضته أي منهما. الربط لا يخبرنا إن كان التفويض السابق قد سمح، أو إن كان التعديل قد غيّر الكائن، أو إن كان متحكم آخر قد رفض العملية، أو إن كان الكائن قد حُفظ في النهاية. كما أن عمليات القراءة لا تمر بطبقة القبول. لذلك لا تصلح قائمة الروابط كتاريخ لما قبله النظام أو حفظه.
هناك دليل أضيق وأقوى عندما يتعلق الأمر بطلب بعينه. توثق Kubernetes تعليق تدقيق لفشل التحقق يحدد السياسة والربط وفهرس التعبير والأفعال المرتبطة بطلب API. يمكن لهذا التعليق أن يسند وصفاً محدوداً لتلك الواقعة. لكنه لا يثبت مصير طلب آخر ولا كفاية الضابط لكل بيئة. قوته تأتي من إبقائه حدود الادعاء ظاهرة.
الطريقة العملية هي حفظ سجلين متجاورين. يسجل الأول هوية السياسة والربط والإصدارات المرصودة والنطاق ومرجع المعلمة وسياسة الإخفاق والأفعال ووقت الرصد. ويسجل الثاني هوية الطلب ووقته وشروط المطابقة أو الاستبعاد وحالة المعلمة ونتيجة التقييم والفعل والاستجابة ودليل الحفظ أو الرفض. لا تفرض Kubernetes دفتر السجلات هذا. لكنه يمنع إعلاناً واضحاً من أن يتحول إلى دليل على حدث لم يشهده.
المصادر
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات