مفاهيم الأمان للتطبيقات والكلاسترات في خدمة Azure Kubernetes ‏(AKS)

يحمي أمان الحاويات خط الأنابيب من البداية إلى النهاية بالكامل من البناء إلى أحمال العمل التطبيقية التي تعمل في خدمة Azure Kubernetes ‏(AKS).

تتضمن سلسلة التوريد الآمنة بيئة البنية والسجل.

يتضمن Kubernetes مكونات الأمان، مثل معايير أمان الجرابوالبيانات السرية. يتضمن Azure مكونات مثل Microsoft Entra ID، Microsoft Defender for Containers، نهج Azure، Azure Key Vault، مجموعات أمان الشبكات، وترقيات العناقيد المنسقة. تجمع AKS بين مكونات الأمان هذه من أجل:

• توفير قصة مصادقة وتخويل كاملة.
• تطبيق AKS المدمج نهج Azure لتأمين تطبيقاتك.
• رؤى شاملة من البناء عبر تطبيقك مع Microsoft Defender for Containers.
• احرص على أن ترقية نظام تشغيل نظام مجموعة AKS الخاص بك إلى آخر تحديثات أمان، وكذلك أحدث إصدارات Kubernetes.
• توفير حركة جراب آمنة جراب والوصول إلى بيانات الاعتماد الحساسة.

يدعم AKS وضعين للعناصر: AKS Automatic وAKS Standard. تنطبق مفاهيم الأمان في هذا المقال على كلا الوضعين ما لم يذكر خلاف ذلك. يتضمن AKS Automatic خط أساس أمني محصن مع عدة ضوابط معدة معدة مسبقا بشكل افتراضي، بينما يوفر AKS Standard مرونة أكبر في التكوين.

تقدم هذه المقالة المفاهيم الأساسية التي تؤمن تطبيقاتك في AKS.

هام

ابتداء من 30 نوفمبر 2025، لم يعد خدمة Azure Kubernetes ‏(AKS) يدعم أو يوفر تحديثات الأمان ل Azure Linux 2.0. صورة عقدة لينكس 2.0 Azure متجمدة عند إصدار 202512.06.0. ابتداء من 31 مارس 2026، سيتم إزالة صور العقد، ولن تتمكن من توسيع مجموعات العقد الخاصة بك. انتقل إلى نسخة مدعومة Azure لينكس عن طريق ترقية مجموعات العقد إلى نسخة Kubernetes مدعومة أو الانتقال إلى osSku AzureLinux3. لمزيد من المعلومات، راجع Retirement GitHub issue وتحديث Azure إعلان التقاعد. للبقاء على اطلاع بالإعلانات والتحديثات، تابع ملاحظات الإصدار AKS.

بناء الأمان

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

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

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

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

أمان السجل

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

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

أمان نظام المجموعة

في AKS، المكونات الأساسية ل Kubernetes هي جزء من الخدمة المدارة التي تقدمها Microsoft وتدار وتتم صيانتها. كل عنقود AKS لديه كوبيرنتيز أساسي خاص به بمستأجر واحد ومخصص لتوفير خادم واجهة برمجة التطبيقات (API) والجدولة وغيرها. لمزيد من المعلومات، راجع إدارة الثغرات الثانوية ل Azure Kubernetes Service.

بشكل افتراضي، يستخدم خادم API Kubernetes عنوان IP عام، واسم مجال مؤهل بالكامل. يمكنك تقييد الوصول إلى نقطة نهاية خادم API باستخدام نطاقات IP المعتمدة. يمكنك أيضًا إنشاء نظام مجموعة خاص بالكامل للحد من وصول خادم API إلى الشبكة الظاهرية.

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

يمكنك التحكم في الوصول إلى خادم واجهة برمجة التطبيقات باستخدام Kubernetes التحكم في الوصول القائم على الأدوار (Kubernetes RBAC) وAzure RBAC. في AKS Automatic، Azure RBAC for Kubernetes authorization مسبق التكوين المسبق. في AKS Standard، يمكنك اختيار وتكوين نموذج التفويض الذي يناسب بيئتك بشكل أفضل. لمزيد من المعلومات، راجع Microsoft Entra التكامل مع AKS.

إعدادات الأمان التلقائية ل AKS

يتضمن AKS Automatic خط أساس محصن مع ضوابط أمنية معدة مسبقا بشكل افتراضي، بما في ذلك:

• Azure RBAC for Kubernetes authorization
• تكامل الشبكة الافتراضية لخوادم واجهة برمجة التطبيقات
• هوية عبء العمل ومصدر OIDC
• ضمانات النشر ومعايير أمان البودات الأساسية في وضع التنفيذ
• منظف الصور لإزالة الصور غير المستخدمة وضعيفة
• قيود أمان تجمع عقد النظام المدارة التي تحافظ على الحدود بين أحمال عمل العملاء والبنية التحتية المدارة بواسطة AKS

يدعم AKS Standard هذه القدرات بمرونة أكبر في التنفيذ، لكنها قد تتطلب تمكين صريحا وإدارة تشغيلية.

أمان العقدة

عقد AKS هي آلات افتراضية (VMs) تابعة ل Azure. في AKS Standard، تدير إعدادات تجمع العقد وخيارات دورة الحياة. في AKS Automatic، يدير AKS تجمعات عقد النظام ومكونات النظام الأساسية نيابة عنك، بما في ذلك التوسع والترقيات، مع قيود أمنية على البنية التحتية للنظام المدار.

تعمل عقد لينكس بنسخ محسنة من أوبونتو أو Azure Linux. تعمل Windows Server العقد بإصدار Windows Server محسن باستخدام وقت تشغيل الحاوية containerd.

عند إنشاء مجموعة AKS أو توسيع نطاقها، يتم نشر العقد تلقائياً مع أحدث تحديثات الأمان وتكوينات نظام التشغيل.

إشعار

مجموعات AKS قيد التشغيل:

• كوبيرنتيز الإصدار 1.19 وما بعد: تستخدم containerd مجموعات عقد لينكس وقت تشغيل الحاويات الخاصة بها. تستخدم مجموعات Windows Server 2019 و Windows Server 2022 العقد containerd كوقت تشغيل الحاويات. لمزيد من المعلومات، راجع إضافة مجموعة عقد Windows Server باستخدام containerd.
• كوبيرنتيز الإصدار 1.19 وما قبله: تستخدم مجموعات عقد لينكس دوكر كوقت تشغيل الحاويات الخاصة بها.

لمزيد من المعلومات حول عملية ترقية الأمان لعقد لينكس و Windows العاملين، راجع Security patching nodes.

تشمل عناقيد AKS التي تعمل Azure الجيل الثاني من الأجهزة الافتراضية دعم Trusted Launch. تحمي هذه الميزة من تقنيات الهجوم المتقدمة والمستمرة من خلال الجمع بين التقنيات التي يمكنك تمكينها بشكل مستقل، مثل التمهيد الآمن وإصدار افتراضي من الوحدة النمطية للنظام الأساسي الموثوق به (vTPM). يمكن للمسؤولين نشر عقد عامل AKS مع محملات تمهيد تم التحقق منها وموقعة، ونواة نظام التشغيل، وبرامج التشغيل لضمان تكامل سلسلة التمهيد بأكملها للجهاز الظاهري الأساسي.

خيارات نظام التشغيل المحسنة للحاوية والأمان

Azure Container Linux (ACL) هو نظام تشغيل غير قابل للتغيير ومحسن للحاويات لنظام AKS. ACL مشتق من مشروع Flatcar Container Linux، ويبني على التصميم الثابت المثبت الذي يعتمد على الحاوية أولا، مع دمج حزم Azure Linux والصيانة وتكامل المنصة. يتيح ذلك ل ACL البقاء متوافقة بشكل وثيق مع ابتكارات Flatcar المتقدمة مع تلبية متطلبات الإنتاج والأمن والامتثال ل Azure. لمعرفة المزيد حول Flatcar Container Linux ، راجع وثائق Flatcar.

تتوفر ACL بشكل عام (GA) كخيار نظام تشغيل على AKS بدءا من AKS v1.34. يمكنك نشر مجموعات عقد ACL في عنقود AKS جديد، وإضافة مجموعات عقد ACL إلى عناقيد الحالية، ونقل مجموعات عقد لينكس الحالية إلى ACL.

لمزيد من المعلومات حول ACL، راجع Azure لينكس الحاويات (ACL) لنظرة عامة على AKS.

تخويل عقدة

تخويل العقدة هو وضع تخويل خاص الغرض يخول على وجه التحديد طلبات واجهة برمجة تطبيقات kubelet للحماية من الهجمات بين الشرق والغرب. يتم تمكين تخويل العقدة بشكل افتراضي على AKS 1.24 + أنظمة المجموعات.

نشر العقدة

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

تخزين العقدة

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

أحمال العمل العدائية متعددة المستأجرين

حاليا، بيئات Kubernetes ليست آمنة للاستخدام العدائي متعدد المستأجرين. تعمل ميزات الأمان الإضافية، مثل نُهج أمان الجراب أو Kubernetes RBAC للعقد، على حظر عمليات الاستغلال بكفاءة. للأمان الحقيقي عند تشغيل أحمال عمل عدائية متعددة المستأجرين، لا تثق إلا في برنامج مراقبة الأجهزة الافتراضية. مجال الأمان لـ Kubernetes يصبح المجموعة بأكملها، وليس عقدة فردية.

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

حساب العزل

بسبب الامتثال أو المتطلبات التنظيمية، قد تتطلب أعباء عمل معينة درجة عالية من العزلة عن أعباء عمل العملاء الأخرى. بالنسبة لهذه الأحمال العملية، يوفر Azure ما يلي:

• حاويات Kernel المعزولة لاستخدامها كعقد عامل في نظام مجموعة AKS. هذه الحاويات معزولة تماما لنوع معين من الأجهزة ومعزولة عن نسيج Azure Host، ونظام التشغيل المضيف، والمعالج الافتراضي. إنهم مخصصون لعميل واحد. حدد أحد أحجام الأجهزة الظاهرية المعزولةكحجم العقدة عند إنشاء نظام مجموعة AKS أو إضافة تجمع عقدة.
• تقوم الحاويات السرية (المعاينة)، المستندة أيضا إلى حاويات Kata السرية، بتشفير ذاكرة الحاوية ومنع البيانات في الذاكرة أثناء الحساب من أن تكون في نص واضح وتنسيق قابل للقراءة والعبث. يساعد في عزل الحاويات الخاصة بك عن مجموعات/جرابات الحاويات الأخرى، ونواة نظام تشغيل عقدة الجهاز الظاهري. تستخدم الحاويات السرية (معاينة) تشفير الذاكرة المستندة إلى الأجهزة (SEV-SNP).
• توفر Pod Sandboxing (معاينة) حد عزل بين تطبيق الحاوية والنواة المشتركة وموارد الحوسبة (وحدة المعالجة المركزية والذاكرة والشبكة) لمضيف الحاوية.

أمن الشبكة

للاتصال والأمان مع الشبكات المحلية، يمكنك نشر عنقود AKS الخاص بك في شبكات Azure الافتراضية الحالية. تتصل هذه الشبكات الافتراضية بشبكتك المحلية عبر Azure Site-to-Site VPN أو Express Route. تعريف وحدات تحكم خروج Kubernetes مع عناوين IP الداخلية والخاصة للحد من وصول الخدمات إلى اتصال الشبكة الداخلية.

في AKS Automatic، يتم إعداد قدرات الشبكة الافتراضية المدارة وإعدادات الدخول والخروج الأساسية مسبقا لتوفير خط أساس آمن. في AKS Standard، نماذج الشبكات وضوابط الخروج/الدخول أكثر مرونة ويجب اختيارها بناء على بنية الأمان لديك.

مجموعات أمان شبكة Azure

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

إذا قمت بتوفير شبكة فرعية خاصة بك لمجموعة AKS الخاصة بك (سواء باستخدام Azure CNI أو Kubenet)، فإن لا تعدل مجموعة أمان الشبكة على مستوى شبكة الشبكة التي تديرها AKS. بدلًا من ذلك، أنشئ مجموعات أمان شبكة الاتصال على مستوى الشبكة الفرعية لتعديل تدفق حركة المرور. تأكد من أنها لا تتداخل مع حركة المرور الضرورية التي تدير المجموعة، مثل الوصول إلى موازن التحميل، أو الاتصال بلوحة التحكم، أو الخروج.

نُهج شبكة Kubernetes

للحد من حركة مرور الشبكة بين وحدات الجراب في نظام المجموعة، تقدم AKS الدعم لـنُهج شبكة Kubernetes. باستخدام نهج الشبكة، يمكنك السماح أو رفض مسارات شبكة محددة داخل نظام المجموعة استنادًا إلى مساحات الأسماء ومحددات التسميات.

أمان التطبيقات

لحماية الكبسولات التي تعمل على AKS، فكر في Microsoft Defender للحاويات لاكتشاف وتقييد الهجمات السيبرانية ضد تطبيقاتك التي تعمل داخل الكبساط. قم بتشغيل الفحص المستمر لكشف الانحراف في حالة الثغرة الأمنية لتطبيقك وتنفيذ عملية "الأزرق/الأخضر/الكناري" لتصحيح الصور العرضة للتهديدات واستبدالها.

في AKS Automatic، يتم إعداد هوية عبء العمل ومصدري OIDC مسبقا لتبسيط الوصول الآمن إلى عبء العمل إلى خدمات Azure. في AKS Standard، تتوفر هذه القدرات ويمكن تفعيلها كجزء من وضعك الأمني الأساسي.

تأمين وصول الحاوية إلى الموارد

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

أسرار Kubernetes

باستخدام بياناتKubernetesالسرية، يمكنك حقن البيانات الحساسة في وحدات الجراب، مثل بيانات اعتماد الوصول أو المفاتيح.

1. قم بإنشاء بيانات سرية باستخدام Kubernetes API.
2. حدد وحدات الجراب الخاصة بك أو النشر واطلب بيانات سرية محددة.
   • يتم توفير البيانات السرية فقط للعقد ذات الجراب المجدول الذي يحتاجها.
   • يتم تخزين البيانات السرية في tmpfs ، ولا يتم كتابتها على القرص.
3. عند حذف آخر جراب على عقدة تتطلب بيانات سرية، يتم حذف Secret من tmpfs للعقدة.
   • يتم تخزين الأسرار داخل مساحة اسم معينة ولا يمكن الوصول إليها إلا من pods داخل نفس مساحة الاسم.

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

إشعار

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

يتم تخزين أسرار Kubernetes في etcd، مخزن قيم المفاتيح الموزعة. يسمح AKS بالتشفير في بقية البيانات السرية في etcd باستخدام مفاتيح يديرها العميل.

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

للبدء في تأمين نظم مجموعة AKS الخاصة بك، راجع ترقية نظام مجموعة AKS.

إذا كنت تقيم الافتراضيات الخاصة بالنمط والمسؤوليات التشغيلية، راجع ما هو خدمة Azure Kubernetes ‏(AKS) التلقائي؟

للاطلاع على أفضل الممارسات ذات الصلة، راجع أفضل ممارسات أمان وترقيات نظام المجموعة في AKS وأفضل ممارسات أمان الجراب في AKS.

لمزيد من المعلومات حول مفاهيم Kubernetes وAKS الأساسية، راجع المقالات التالية:

• مجموعات Kubernetes / AKS وأعباء العمل
• هوية Kubernetes / AKS
• شبكات Kubernetes / AKS الظاهرية
• التخزين في Kubernetes / AKS
• تغيير السعة في Kubernetes / AKS