مشاركة عبر

نظرة عامة على Azure Kubernetes Application Network Security (preview)

مهم

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

تؤمن شبكة تطبيقات Azure Kubernetes التواصل بين الخدمات في مجموعات Azure Kubernetes Service (AKS) المتصلة من خلال TLS المتبادل التلقائي (mTLS) والتفويض القائم على الهوية. يصدر هويات عبء العمل ويدير إصدار الشهادات، والدوران، والتحقق من صحتها لتمكين التواصل المشفر والمصادق والصريح بين الخدمات دون الحاجة إلى تكوين يدوي، مع تشفير متوافق مع FIPS أثناء النقل.

تقدم هذه المقالة نظرة عامة على ميزات الأمان في شبكة تطبيقات Azure Kubernetes، بما في ذلك mTLS، وهويات عبء العمل، وإدارة الشهادات، وسياسات التفويض. كما يوضح القيود والخطوات التالية لتنفيذ الاتصالات الآمن في بيئة شبكة تطبيقات Azure Kubernetes الخاصة بك.

القيود

  • تصدر الشهادات حاليا من قبل جهة شهادات تدار عبر شبكة تطبيقات Azure Kubernetes (CA) وليست مرتبطة بسلطة شهادات عامة.

mTLS

تستخدم شبكة التطبيقات mTLS لتوفير اتصال مشفرا قائم على الهوية بين أحمال العمل. كل خدمة في عنقود متصل بشبكة التطبيقات تتلقى تلقائيا شهادة تسمح لها بإثبات هويتها وإنشاء اتصالات مشفرة وموثوقة مع خدمات أخرى في نفس شبكة التطبيقات. يستخدم التشفير أثناء النقل التشفير المتوافق مع FIPS.

استراتيجية ترحيل mTLS

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

فوائد mTLS في شبكة تطبيقات Azure Kubernetes

mTLS في Azure Kubernetes Application Network يساعدك على:

  • حماية البيانات أثناء النقل: يمكن تشفير جميع حركة المرور بين الخدمة تلقائيا (متوافقة مع FIPS).
  • التحقق من هوية الخدمة: كل عبء عمل له جذر وشهادة وسيطة فريدة تدار بواسطة شبكة التطبيقات.
  • تبسيط العمليات: تتولى شبكة التطبيقات إصدار الشهادات، والدوران، والإلغاء للمستخدمين.

إدارة الشهادات

توفر شبكة تطبيقات Azure Kubernetes إدارة الشهادات مدعومة ب Azure Key Vault التي تصدر وتحافظ على الشهادات المستخدمة في mTLS. تضع هذه الخدمة حدود ثقة مشتركة عبر جميع عناقيد AKS المتصلة بنفس مورد شبكة التطبيقات.

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

يوضح الرسم البياني التالي تسلسل الشهادات في Application Network، موضحا كيف يتم هيكلة شهادات CA الجذرية، وشهادات CA الوسيطة، وشهادات عبء العمل لبناء الثقة عبر التجمعات المتصلة:

لقطة شاشة لمخطط يوضح تسلسل الشهادات في شبكة تطبيقات Azure Kubernetes، يوضح كيف يتم هيكلة شهادات CA الجذرية، وشهادات CA الوسيطة، وشهادات عبء العمل لبناء الثقة عبر المجموعات المتصلة.

تسلسل الشهادات ودورة الحياة

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

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

من أي مجموعة أعضاء، يمكنك الحصول على شهادة CA الجذرية من Config Map istio-root-cert تحت مساحة applink-systemالاسم.

أنواع الشهادات وفترات التدوير

نوع الشهادة النطاق فترة الصلاحية فترة التدوير الغرض
روت CA Azure Kubernetes Application Network 12 شهرا 6 أشهر يحدد حدود الثقة لجميع العناقيد المتصلة بشبكة تطبيقات Azure Kubernetes
CA المتوسطة Cluster 90 يومًا 45 يوما إصدار شهادات عبء العمل لأحمال العمل داخل ذلك العنقود
شهادة عبء العمل Workload 24 ساعة 12 ساعة يصادق على أعباء العمل ويؤمن التواصل بين الخدمة.

هوية عبء العمل والتفويض

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

داخل بيئة متصلة بشبكة التطبيقات، تتواصل الأحمال العملية بأمان داخل وعبر مساحات الأسماء. لضمان إمكانية الوثوق بكل خدمة والتحقق منها، تقوم شبكة التطبيقات بتعيين هوية قابلة للتحقق لكل عبء عمل تمثل مساحة الاسم وحساب الخدمة الخاص بها.

يحصل كل عبء عمل في شبكة التطبيقات تلقائيا على هوية فريدة بصيغة SPIFFE ، والتي تشمل مساحة الاسم وحساب الخدمة. يتم تنسيق الهوية كما يلي:

spiffe://cluster.local/ns/<namespace>/sa/<service-account>

يتم تضمين هذه الهوية في شهادة عبء العمل وتستخدم لإثبات هوية الخدمة عند التواصل مع أحمال العمل الأخرى. تستخدم شبكة تطبيقات Azure Kubernetes نموذج الهوية القائم على SPIFFE مع سياسات تفويض Istio حتى تتمكن من تحديد قواعد واضحة ومتسقة للخدمات التي يسمح لها بالتواصل.

تعريف سياسات الوصول

يمكنك استخدام Istio AuthorizationPolicies للتحكم في الأحمال التي يسمح لها بالتواصل داخل بيئتك. تتيح لك هذه السياسات تحديد الوصول بناء على هويات عبء العمل المثبتة بدلا من مواقع الشبكة أو عناوين IP. يساعدك هذا النهج على فرض ضوابط وصول متسقة حتى مع توسع الخدمات وتحركها عبر العقد. على سبيل المثال، قد تسمح فقط ببوابات أو أحمال عمل محددة من مساحات أسماء موثوقة باستدعاء خدمة من خلال الإشارة إلى هويات SPIFFE الخاصة بها في قائمة المبادئ الخاصة بالسياسة كما هو موضح في المثال التالي:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-gateway-to-app
  namespace: default
spec:
  selector:
    matchLabels:
      app: myApp
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/default/sa/myApp-gateway // see SPIFFE format above

إرشادات تصميم السياسات

عند تصميم سياسات التفويض، ضع في اعتبارك أفضل الممارسات التالية:

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

ملحوظة

يعتمد تفويض شبكة تطبيقات Azure Kubernetes على هوية عبء العمل الموثوق وليس عنوان IP. هذا يضمن تطبيقا متسقا حتى مع توسع أو تحرك أعباء العمل عبر العقد.

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

المحتوى ذو الصلة

لمعرفة المزيد عن شبكة تطبيقات Azure Kubernetes، راجع المقالات التالية:

  • Last updated on