أصبح نموذج الأمان القائم على المحيط التقليدي عفا عليه الزمن في بيئات الحوسبة السحابية الأصلية الحديثة. في عناقيد Kubernetes، تكون أحمال العمل مؤقتة وديناميكية وتتوسع باستمرار. الاعتماد فقط على الجدران النارية عند الحافة غير كافٍ عندما يخترق الجهات الخبيثة المحيط. هنا يصبح الوصول إلى الشبكة ذو الثقة الصفرية (ZTNA) حاسماً. وتحديداً، يتطلب تأمين حركة المرور من الشرق إلى الغرب - وهي الاتصالات بين الحاويات داخل العنقود - التحول من الثقة الضمنية إلى التحقق الصريح.
يستكشف هذا الدليل كيفية تطبيق مبادئ ZTNA في Kubernetes باستخدام سياسات الشبكة الأصلية والوكلاء الواعيين بالهوية (IAP). سننتقل beyond القواعد البسيطة للسماح بالكل إلى إنشاء نموذج يتم فيه مصادقة كل مكالمة خدمة وتفويضها، بغض النظر عن مصدرها.
تحدي حركة المرور من الشرق إلى الغرب
في البنية المعمارية الأحادية، غالباً ما يتم تجاهل حركة المرور من الشرق إلى الغرب لأن كل شيء يعيش على نفس الشبكة الموثوقة. ومع ذلك، في Kubernetes، يمكن أن يسمح اختراق حاوية واحدة للمهاجم بمسح العنقود والانتقال أفقياً إلى قواعد البيانات الحرجة أو واجهات الإدارة. بدون تقسيم صارم، يكون نطاق الانفجار الناتج عن الاختراق كبيراً. يعالج ZTNA هذا عن طريق ضمان عدم قدرة أي حاوية على التحدث مع حاوية أخرى إلا إذا تم السماح بذلك صراحةً بناءً على الهوية، وليس مجرد عنوان IP.
الطبقة 1: سياسات الشبكة الدقيقة
الطبقة الأولى من الدفاع هي سياسة شبكة Kubernetes. تسمح هذه الموارد الأصلية بتعريف قواعد للاحتمالات بين الحاويات. بينما لا تكون سياسات الشبكة القياسية واعية بالهوية بحد ذاتها (فهي تعتمد على تسميات الحاويات والأسماء النطاقية)، فإنها تشكل الهيكل العظمي لهندسة الثقة الصفرية الخاصة بنا. بشكل افتراضي، يجب فرض سياسة "حظر الكل" للدخول لكل اسم نطاق.
تخيل سيناريو حيث تحتاج تطبيق واجهة أمامية إلى التواصل مع واجهة برمجة تطبيقات خلفية، ولكن لا يجب لأي خدمة أخرى الوصول إلى الواجهة الخلفية. يمكنك تحقيق ذلك عن طريق تسمية الحاويات وتطبيق قاعدة دخول محددة.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: restrict-backend-access
namespace: production
spec:
podSelector:
matchLabels:
app: backend-api
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: frontend-app
ports:
- protocol: TCP
port: 8080في هذا المثال، يمكن فقط للحاويات التي تحمل التسمية `app: frontend-app` في نفس الاسم النطاقي الوصول إلى الواجهة الخلفية على المنفذ 8080. يتم إسقاط أي حركة مرور أخرى بواسطة مكون واجهة شبكة الحاويات (CNI)، مما يفرض تقسيماً صارماً.
الطبقة 2: الوكلاء الواعيون بالهوية
بينما تتحكم سياسات الشبكة في *أين* يمكن أن تذهب حركة المرور، يتطلب ZTNA التحكم في *من* يقوم بإرسال الطلب. هنا يأتي دور الوكيل الواعي بالهوية (IAP). يجلس الوكيل بين العملاء والخدمات، ويحقق من هوية المرسل قبل السماح بالاتصال. في سياق Kubernetes، يتضمن ذلك غالباً استخدام شبكة خدمة مثل Istio أو وكيل جانبي مخصص يتحقق من رموز JWT أو بيانات اعتماد OAuth2.
من خلال حقن وكيل جانبي في كل حاوية، يمكنك فرض أن تحمل الطلبات رموز مصادقة صالحة. إذا لم يحمل الطلب رمزاً صالحاً، يقوم الوكيل بإنهاء الاتصال فوراً، مما يمنع الحركة الأفقية حتى لو تجاوز المهاجم سياسة الشبكة (على سبيل المثال، من خلال الهروب من الحاوية).
تنفيذ الهوية عبر شبكة الخدمة
يستخدم شبكة الخدمة يسمح لك بنقل التحقق من الهوية من كود التطبيق الخاص بك. يمكنك تعريف سياسات التفويض التي تتحقق من موضوع الطلب الوارد مقابل قائمة بالهويات المسموح بها.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: require-oidc
namespace: production
spec:
selector:
matchLabels:
app: backend-api
action: ALLOW
rules:
- from:
- source:
principals: ["cluster.local/ns/production/sa/frontend-sa"]تضمن هذه السياسة أنه يُسمح فقط لحساب الخدمة `frontend-sa` في اسم النطاق الإنتاجي بالاتصال بالواجهة الخلفية. حتى إذا حاول عنوان IP خارجي انتحال حركة المرور، سيفشل التحقق من الهوية.
تجميع كل شيء معاً
لا يتعلق ZTNA الفعال في Kubernetes باختيار بين سياسات الشبكة والوكلاء الواعيين بالهوية؛ بل يتعلق بطبقتها. توفر سياسات الشبكة التقسيم الشبكي الضروري لتقليل سطح الهجوم، بينما يضمن الوكيل الواعي بالهوية أن حركة المرور التي تعبر تلك التقسيمات يتم مصادقتها وتفويضها.
عند تنفيذ ذلك، تذكر أن الأمان عملية تكرارية. ابدأ بتفعيل سياسة "حظر الكل" لفهم تدفقات حركة المرور الخاصة بك، ثم قدم تدريجياً قواعد السماح. في الوقت نفسه، انتقل إلى شبكة خدمة أو نمط الوكيل الجانبي لإدخال التحقق من الهوية. من خلال دمج هذه الاستراتيجيات، تنشئ بنية دفاعية قوية متعددة الطبقات تحمي خدماتك المصغرة ضد أكثر التهديدات تعقيداً.
يعتني اعتماد الثقة الصفرية رحلة، لكنه المسار الوحيد القابل للتطبيق لتأمين التطبيقات الحديثة والديناميكية في السحابة.