حاويات سرية (معاينة) مع خدمة Azure Kubernetes (AKS)

توفر الحاويات السرية مجموعة من الميزات والقدرات لزيادة تأمين أحمال عمل الحاوية القياسية لتحقيق أمان أعلى للبيانات وخصوصية البيانات وأهداف تكامل التعليمات البرمجية لوقت التشغيل. تتضمن خدمة Azure Kubernetes (AKS) حاويات سرية (معاينة) على AKS.

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

جنبا إلى جنب مع Pod Sandboxing، يمكنك تشغيل أحمال العمل الحساسة المعزولة في Azure لحماية بياناتك وأحمال العمل. ما الذي يجعل الحاوية سرية:

• الشفافية: بيئة الحاوية السرية حيث تتم مشاركة تطبيقك الحساس، يمكنك رؤية ما إذا كان آمنا والتحقق منه. يجب مصدر مفتوح جميع مكونات قاعدة الحوسبة الموثوق بها (TCB).
• إمكانية التدقيق: لديك القدرة على التحقق ومعرفة إصدار حزمة بيئة CoCo بما في ذلك نظام التشغيل Linux Guest وجميع المكونات الحالية. تقوم Microsoft بتسجيل الدخول إلى نظام التشغيل الضيف وبيئة وقت تشغيل الحاوية للتحقق من خلال التصديق. كما أنه يطلق خوارزمية تجزئة آمنة (SHA) من بنيات نظام التشغيل الضيف لبناء سلسلة السمعة والتحكم في القصة.
• الإثبات الكامل: يجب قياس أي شيء يشكل جزءا من TEE بشكل كامل بواسطة وحدة المعالجة المركزية مع القدرة على التحقق عن بعد. يجب أن يعكس تقرير الأجهزة من معالج AMD SEV-SNP طبقات الحاوية وتجزئة تكوين وقت تشغيل الحاوية من خلال مطالبات التصديق. يمكن للتطبيق إحضار تقرير الأجهزة محليا بما في ذلك التقرير الذي يعكس صورة نظام التشغيل الضيف ووقت تشغيل الحاوية.
• تكامل التعليمات البرمجية: يتوفر فرض وقت التشغيل دائما من خلال النهج المعرفة من قبل العميل للحاويات وتكوين الحاوية، مثل النهج غير القابلة للتغيير وتوقيع الحاوية.
• العزلة عن المشغل: تصميمات الأمان التي تفترض أقل امتياز وأعلى عزلة محمية من جميع الأطراف غير الموثوق بها بما في ذلك مسؤولي العملاء/المستأجرين. وهو يتضمن تقوية وصول وحدة التحكم Kubernetes الحالية (kubelet) إلى القرون السرية.

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

تساعدك هذه المقالة على فهم ميزة الحاويات السرية وكيفية تنفيذ وتكوين ما يلي:

• نشر أو ترقية نظام مجموعة AKS باستخدام Azure CLI
• إضافة تعليق توضيحي إلى pod YAML لوضع علامة على الجراب على أنه قيد التشغيل كحاوية سرية
• إضافة نهج أمان إلى pod YAML
• تمكين فرض نهج الأمان
• نشر تطبيقك في الحوسبة السرية

السيناريوهات المدعومة

الحاويات السرية (معاينة) مناسبة لسيناريوهات التوزيع التي تتضمن بيانات حساسة. على سبيل المثال، معلومات التعريف الشخصية (PII) أو أي بيانات ذات أمان قوي مطلوب للامتثال التنظيمي. بعض السيناريوهات الشائعة مع الحاويات هي:

• تشغيل تحليلات البيانات الضخمة باستخدام Apache Spark للتعرف على نمط الاحتيال في القطاع المالي.
• تشغيل مشغلات GitHub المستضافة ذاتيا لتوقيع التعليمات البرمجية بأمان كجزء من ممارسات DevOps للتكامل المستمر والنشر المستمر (CI/CD).
• التعلم الآلي الاستدلال والتدريب على نماذج التعلم الآلي باستخدام مجموعة بيانات مشفرة من مصدر موثوق به. يتم فك تشفيرها داخل بيئة حاوية سرية فقط للحفاظ على الخصوصية.
• بناء غرف نظيفة للبيانات الضخمة لمطابقة المعرف كجزء من الحساب متعدد الأطراف في صناعات مثل البيع بالتجزئة مع الإعلانات الرقمية.
• بناء الحوسبة السرية ثقة معدومة المناطق المنتقل إليها لتلبية لوائح الخصوصية لترحيل التطبيقات إلى السحابة.

الاعتبارات

فيما يلي اعتبارات مع هذه المعاينة للحاويات السرية:

• زيادة في وقت بدء تشغيل pod مقارنة بوحدات الجراب المشغلة والقرون المعزولة عن النواة.
• صور حاوية الإصدار 1 غير مدعومة.
• لا تنعكس تحديثات الأسرار وConfigMaps في الضيف.
• تتطلب الحاويات سريعة الزوال وأساليب استكشاف الأخطاء وإصلاحها الأخرى مثل exec في حاوية، ومخرجات السجل من الحاويات، و stdio (ReadStreamRequest و WriteStreamRequest) تعديلا للنهج وإعادة توزيعه.
• لا تدعم أداة منشئ النهج أنواع توزيع cronjob.
• نظرا إلى تشفير قياسات طبقة صورة الحاوية في نهج الأمان، لا نوصي باستخدام العلامة latest عند تحديد الحاويات.
• تدعم الخدمات وموازنات التحميل وEndpointSlices بروتوكول TCP فقط.
• يجب تكوين جميع الحاويات في جميع الحاويات على المجموعات إلى imagePullPolicy: Always.
• يدعم منشئ النهج فقط الحجيرات التي تستخدم عناوين IPv4.
• لا يمكن تغيير قيم ConfigMaps والأسرار إذا كان الإعداد باستخدام أسلوب متغير البيئة بعد نشر الجراب. يمنعه نهج الأمان.
• سجلات إنهاء الجراب غير مدعومة. بينما تكتب الحجيرات سجلات الإنهاء إلى /dev/termination-log أو إلى موقع مخصص إذا تم تحديدها في بيان الجراب، لا يمكن للمضيف/kubelet قراءة تلك السجلات. لا تنعكس التغييرات من الضيف إلى هذا الملف على المضيف.

نظرة عامة على تخصيص الموارد

من المهم فهم سلوك تخصيص موارد الذاكرة والمعالج في هذا الإصدار.

• وحدة المعالجة المركزية: يقوم shim بتعيين وحدة معالجة مركزية ظاهرية واحدة إلى نظام التشغيل الأساسي داخل الجراب. إذا لم يتم تحديد أي مورد limits ، فلن يكون لأحمال العمل مشاركات وحدة المعالجة المركزية منفصلة معينة، ثم تتم مشاركة وحدة المعالجة المركزية الظاهرية مع حمل العمل هذا. إذا تم تحديد حدود وحدة المعالجة المركزية، يتم تخصيص مشاركات وحدة المعالجة المركزية بشكل صريح لأحمال العمل.
• الذاكرة: يستخدم معالج Kata-CC ذاكرة 2 غيغابايت لنظام التشغيل UVM وذاكرة X ميغابايت إضافية حيث X هو المورد limits إذا تم تحديده في بيان YAML (مما يؤدي إلى جهاز ظاهري بسعة 2 غيغابايت عند عدم تحديد حد، بدون ذاكرة ضمنية للحاويات). يستخدم معالج Kata ذاكرة أساسية 256 ميغابايت لنظام التشغيل UVM وذاكرة X MB الإضافية عند تحديد المورد limits في بيان YAML. إذا كانت الحدود غير محددة، تتم إضافة حد ضمني يبلغ 1792 ميغابايت مما يؤدي إلى جهاز ظاهري بسعة 2 غيغابايت وذاكرة ضمنية 1792 ميغابايت للحاويات.

في هذا الإصدار، لا يتم دعم تحديد طلبات الموارد في بيانات pod. تتجاهل حاوية Kata طلبات الموارد من بيان pod YAML، ونتيجة لذلك، لا تمرر الحاوية الطلبات إلى shim. استخدم المورد limit بدلا من المورد requests لتخصيص الذاكرة أو موارد وحدة المعالجة المركزية لأحمال العمل أو الحاويات.

مع نظام ملفات الحاوية المحلي المدعوم بذاكرة الجهاز الظاهري، يمكن أن تملأ الكتابة إلى نظام ملفات الحاوية (بما في ذلك التسجيل) الذاكرة المتوفرة المقدمة إلى الحاوية. يمكن أن يؤدي هذا الشرط إلى تعطل الجراب المحتمل.

الخطوات التالية

• راجع نظرة عامة على نهج أمان الحاويات السرية للتعرف على كيفية حماية أحمال العمل وبياناتها في pod.
• نشر حاويات سرية على AKS باستخدام نهج أمان افتراضي.
• تعرف على المزيد حول مضيفي Azure Dedicated للعقد مع نظام مجموعة AKS لاستخدام عزل الأجهزة والتحكم في أحداث صيانة النظام الأساسي ل Azure.