مشاركة عبر

نهج الأمان للحاويات السرية على خدمة Azure Kubernetes

  • مقالة

كما هو موضح من قبل اتحاد الحوسبة السرية (CCC)، "الحوسبة السرية هي حماية البيانات المستخدمة من خلال إجراء الحساب في بيئة التنفيذ الموثوق بها المستندة إلى الأجهزة والمصدق عليها (TEE)." تم تصميم حاويات AKS السرية لحماية بيانات حاويات Kubernetes المستخدمة من الوصول غير المصرح به من خارج هذه القرون. يتم تنفيذ كل جراب في جهاز ظاهري للأداة المساعدة (UVM) محمي بواسطة AMD SEV-SNP TEE عن طريق تشفير البيانات المستخدمة ومنع الوصول إلى البيانات بواسطة نظام التشغيل المضيف (OS). تعاون مهندسو Microsoft مع المجتمعات مفتوحة المصدر للحاويات السرية (CoCo) وKata Containers في تصميم وتنفيذ الحاويات السرية.

نظرة عامة على نهج الأمان

أحد المكونات الرئيسية لبنية نظام حاويات Kata هو عامل Kata. عند استخدام حاويات Kata لتنفيذ الحاويات السرية، يتم تنفيذ العامل داخل TEE المستندة إلى الأجهزة وبالتالي فهو جزء من قاعدة الحوسبة الموثوق بها (TCB) الخاصة بالجراب. كما هو موضح في الرسم التخطيطي التالي، يوفر عامل Kata مجموعة من واجهات برمجة التطبيقات ttrpc التي تسمح لمكونات النظام خارج TEE بإنشاء وإدارة جرابات Kubernetes المستندة إلى السرية. هذه المكونات الأخرى (على سبيل المثال، Kata Shim) ليست جزءا من TCB الخاص بالجراب. لذلك، يجب أن يحمي العامل نفسه من استدعاءات API التي يحتمل أن تكون خطأ أو ضارة.

رسم تخطيطي لنموذج نهج أمان حاويات AKS السرية.

في حاويات AKS السرية، يتم تنفيذ الحماية الذاتية لواجهة برمجة تطبيقات عامل Kata باستخدام نهج أمان (يعرف أيضا باسم نهج عامل Kata)، يحدده مالكو القرون السرية. يحتوي مستند النهج على قواعد وبيانات مطابقة لكل جراب، باستخدام لغة نهج Rego القياسية للصناعة. يتم تنفيذ تنفيذ النهج داخل الجهاز الظاهري للأداة المساعدة (UVM) باستخدام Open Policy Agent (OPA) - مشروع متدرج ل Cloud Native Computing Foundation (CNCF).

محتويات النهج

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

بيانات

بيانات النهج خاصة بكل جراب. يحتوي على، على سبيل المثال:

  • قائمة بالحاويات المتوقع إنشاؤها في الحاوية.
  • قائمة واجهات برمجة التطبيقات المحظورة بواسطة النهج بشكل افتراضي (لأسباب تتعلق بالسرية).

أمثلة على البيانات المضمنة في مستند النهج لكل من الحاويات في pod:

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

القواعد

يتم تنفيذ قواعد النهج، المحددة بتنسيق Rego، بواسطة OPA لكل استدعاء واجهة برمجة تطبيقات عامل Kata من خارج الجهاز الظاهري للأداة المساعدة (UVM). يوفر العامل جميع مدخلات واجهة برمجة التطبيقات إلى OPA، ويستخدم OPA القواعد للتحقق مما إذا كانت المدخلات متسقة مع بيانات النهج. إذا كانت قواعد النهج والبيانات لا تسمح بإدخالات واجهة برمجة التطبيقات، يرفض العامل استدعاء واجهة برمجة التطبيقات عن طريق إرجاع رسالة خطأ "محظورة بواسطة النهج". فيما يلي بعض أمثلة القواعد:

  • يتم عرض كل طبقة حاوية كجهاز كتلة virtio للقراءة فقط إلى الجهاز الظاهري للأداة المساعدة (UVM). تتم حماية تكامل أجهزة الكتلة هذه باستخدام تقنية dm-verity لنواة Linux. يتم تضمين القيمة الجذر المتوقعة لشجرة تجزئة dm-verity في بيانات النهج، ويتم التحقق منها في وقت التشغيل بواسطة قواعد النهج.
  • ترفض القواعد إنشاء الحاوية عند اكتشاف سطر أوامر غير متوقع أو تحميل تخزين أو سياق أمان تنفيذ أو متغير بيئة.

بشكل افتراضي، تكون قواعد النهج شائعة لجميع القرون. تقوم أداة genpolicy بإنشاء بيانات النهج وهي خاصة بكل جراب.

القيم الافتراضية

عند تقييم قواعد Rego باستخدام بيانات النهج وإدخالات واجهة برمجة التطبيقات كمعلمات، يحاول OPA العثور على مجموعة واحدة على الأقل من القواعد التي ترجع true قيمة استنادا إلى بيانات الإدخال. إذا لم ترجع trueالقواعد ، فترجع OPA إلى العامل القيمة الافتراضية لواجهة برمجة التطبيقات هذه. أمثلة على القيم الافتراضية من النهج:

  • default CreateContainerRequest := false – يعني أن أي استدعاء CreateContainer API يتم رفضه ما لم تسمح مجموعة من قواعد النهج صراحة بهذا الاستدعاء.

  • default GuestDetailsRequest := true – يعني أن الاستدعاءات من خارج TEE إلى GuestDetails API مسموح بها دائما لأن البيانات التي يتم إرجاعها بواسطة واجهة برمجة التطبيقات هذه ليست حساسة لسرية أحمال عمل العملاء.

إرسال النهج إلى عامل Kata

تبدأ جميع أجهزة AKS Confidential Container Utility الظاهرية (UVM) باستخدام نهج افتراضي عام مضمن في نظام الملفات الجذر للجهاز الظاهري للأداة المساعدة (UVM). لذلك، يجب توفير نهج يطابق حمل العمل الفعلي للعميل إلى العامل في وقت التشغيل. يتم تضمين نص النهج في ملف بيان YAML كما هو موضح سابقا، ويتم توفير هذه الطريقة للعامل في وقت مبكر أثناء تهيئة الجهاز الظاهري للأداة المساعدة (UVM). ينتقل التعليق التوضيحي للنهج عبر مكونات kubelet والحاويات وKata shim لنظام حاويات AKS السرية. ثم يفرض العامل الذي يعمل مع OPA النهج لجميع الاستدعاءات إلى واجهات برمجة التطبيقات الخاصة به.

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

تأسيس الثقة في مستند النهج

قبل إنشاء الجهاز الظاهري للأداة المساعدة (UVM)، يحسب Kata shim تجزئة SHA256 لمستند النهج ويرفق قيمة التجزئة ب TEE. ينشئ هذا الإجراء ربطا قويا بين محتويات النهج وأداة المساعدة الظاهرية (UVM). لا يمكن تعديل حقل TEE هذا لاحقا إما بواسطة البرنامج المنفذ داخل الجهاز الظاهري للأداة المساعدة (UVM)، أو خارجه.

عند تلقي النهج، يتحقق العامل من تجزئة النهج التي تطابق حقل TEE غير القابل للتغيير. يرفض العامل النهج الوارد إذا اكتشف عدم تطابق التجزئة.

قبل معالجة المعلومات الحساسة، يجب أن تنفذ أحمال العمل الخاصة بك خطوات التصديق عن بعد لإثبات لأي جهة اعتماد أن حمل العمل يتم تنفيذه باستخدام الإصدارات المتوقعة من إصدارات TEE ونظام التشغيل والعامل و OPA ونظام الملفات الجذر. يتم تنفيذ التصديق في حاوية تعمل داخل الجهاز الظاهري للأداة المساعدة (UVM) الذي يحصل على دليل إثبات موقع من أجهزة AMD SEV-SNP. أحد الحقول من دليل التصديق هو حقل تجزئة السياسة TEE الموضح سابقا. لذلك، يمكن لخدمة Attestation التحقق من سلامة النهج، عن طريق مقارنة قيمة هذا الحقل بالتجزئة المتوقعة لنهج pod.

إنفاذ النُهج

وكيل Kata مسؤول عن فرض النهج. ساهمت Microsoft في مجتمع Kata وCoCo في تعليمة الوكيل البرمجية المسؤولة عن التحقق من النهج لكل استدعاء لواجهة برمجة تطبيقات ttrpc للعامل. قبل تنفيذ الإجراءات المقابلة لواجهة برمجة التطبيقات، يستخدم العامل واجهة برمجة تطبيقات REST OPA للتحقق مما إذا كانت قواعد النهج والبيانات تسمح بالمكالمة أو تحظرها.

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

نشر حاوية سرية على AKS