تتحول "الثقة الصفري" إلى لغة فارغة بسرعة إذا كانت تعني فقط "نحن نهتم بالأمان". داخل Kubernetes، النسخة العملية أبسط وأكثر صرامة: لا ينبغي أن تثق خدمة ما في خدمة أخرى لمجرد أنها على نفس شبكة التجمع.
هذا يقود إلى ثلاثة متطلبات ملموسة:
- هوية العمل
- حركة مرور خدمة مشفرة بين الخدمات
- سياسة تفويض واضحة
ما تبدو عليه الثقة الصفري في Kubernetes
في معظم تجمعات الإنتاج، نقطة البداية ليست نشر شبكة خدمات مثالية. إنها مجموعة أصغر من الضوابط القابلة للتنفيذ:
- هويات خدمات موثقة
- mTLS بين الخدمات الحساسة
- سياسة شبكة على مستوى مساحة الأسماء أو العمل
- تفويض على نمط قائمة السماح للواجهات البرمجية المهمة
مع Istio، يمكن أن تبدو سياسة التفويض هكذا:
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
name: payments-api
spec:
selector:
matchLabels:
app: payments-api
rules:
- from:
- source:
principals:
- cluster.local/ns/checkout/sa/checkout-service
هذا أقرب بكثير إلى الثقة الصفري من "الخدمات كلها خاصة".
لماذا تكافح الفرق مع ذلك
القيمة حقيقية، لكن الضريبة التشغيلية حقيقية أيضًا. بمجرد تقديم mTLS وطبقات السياسة، فإنك تقدم أيضًا أوضاع فشل جديدة:
- مشكلات دوران الشهادات
- صعوبة في تصحيح حركة المرور
- أخطاء في السياسة تبدو وكأنها انقطاعات
- زيادة في الكمون وتعقيد في التحكم
لهذا السبب تتبنى الفرق الناضجة ذلك بشكل تدريجي. يبدأون بالهوية على شريحة ضيقة، يضيفون السياسة حيث يكون نطاق الانفجار أعلى، ويستثمرون في الرؤية قبل محاولة تأمين كل شيء.
هدف أفضل، لغة أفضل
الهدف الصحيح ليس "تثبيت شبكة والتحول إلى الثقة الصفري". الهدف الصحيح هو استبدال الثقة الشبكية الضمنية بهوية وسياسة واضحة في الأجزاء الأكثر أهمية من المنصة.
هذه الإطار أكثر صدقًا، ويمكن قياسه بسهولة، وأسهل بكثير في التشغيل.
قراءة إضافية