الحفاظ على سرية البيانات والرمز في صور الحاوية
على مدى السنوات القليلة الماضية ، شهدت الصناعة السحابية تحولًا كبيرًا من نشر التطبيقات المتجانسة على الأجهزة الافتراضية إلى تقسيم التطبيقات إلى مكونات أصغر (خدمات مصغرة) وتعبئتها في حاويات. إن شعبية النقل بالحاويات اليوم مدفوعة إلى حد كبير بأعمال Docker. Docker هي الشركة التي أصبحت القوة الدافعة الرئيسية وراء الحاويات: لقد وفرت أداة سهلة الاستخدام لبناء وتشغيل حاويات Docker وسجل حاويات Docker لتحدي التوزيع.
يعتمد نجاح تقنية النقل بالحاويات بشكل أساسي على أمان الحاويات في مراحل مختلفة من دورة حياتها. أحد المخاوف الأمنية هو وجود نقاط ضعف داخل الحاويات الفردية. للتعرف عليها ، يتم استكمال خطوط أنابيب DevOps المستخدمة لإنشاء الحاويات بأجهزة مسح ضوئي تبحث عن حزم بها نقاط ضعف محتملة في الحاويات وتنبيه أصحابها أو الفنيين إذا تم العثور عليهم. يعد مرشد الثغرات الأمنية على IBM Cloud مثالاً على هذه الأداة المساعدة.
جانب آخر من جوانب الأمان هو التأكد من أن الحاوية التي يتم تشغيلها هي التي تريدها وأنه لم يتم تعديلها. تتم معالجة هذه المشكلة باستخدام التوقيعات الرقمية المخزنة في كاتب العدل ، والتي ستحمي الحاويات من أي تعديلات.Docker Notary هو مثال على المستودع العام الذي يخزن توقيعات الصور. باستخدام كاتب العدل ، يمكن للعميل التحقق من توقيع صورة الحاوية للتأكد من أن صورة الحاوية لم يتم تغييرها منذ توقيعها مع المالك أو مفتاح فني الخدمة.
مشكلة أمنية محتملة أخرى هي عزل الحاوية. تساعد تقنيات أمان وقت تشغيل Linux مثل مساحات الأسماء ومجموعات cgroup وإمكانيات Linux وملفات تعريف SELinux و AppArmor و Seccomp في الحد من عمليات الحاوية وعزل الحاويات عن بعضها البعض في وقت التشغيل.
تتناول هذه المقالة مشكلة أمان المؤسسة التي لا تزال ساخنة فيما يتعلق بخصوصية البيانات والكود في صور الحاوية. الهدف الأمني الرئيسي عند العمل مع صور الحاوية هو السماح بإنشاء وتوزيع صور الحاوية المشفرة بحيث تكون متاحة فقط لمجموعة محددة من المستلمين. في هذه الحالة ، قد يتمكن الآخرون من الوصول إلى هذه الصور ، لكن لن يتمكنوا من تشغيلها أو رؤية البيانات الحساسة بداخلها. يعتمد تشفير الحاوية على التشفير الحالي مثل تقنيات تشفير Rivest-Shamir-Adleman (RSA) والمنحنى الإهليلجي ومعيار التشفير المتقدم (AES) ، والمعروف أيضًا باسم Rijndael ، وهو خوارزمية تشفير كتلة متماثلة.
استهلالي
لتحقيق أقصى استفادة من هذه المقالة ، يجب أن تكون على دراية بحاويات Linux وصور الحاويات ، وأن تكون على دراية بأساسيات الأمان.
العمل المتعلق بالتشفير والحاويات
بقدر ما نعلم ، لا يوجد عمل في مجال تشفير صور الحاوية. ومع ذلك ، هناك العديد من التطبيقات والمنتجات التي تدعم سرية البيانات وتشفير الحماية من السرقة من خلال نظام الملفات أو جهاز الحظر أو تشفير الأجهزة. يتم تنفيذ هذا الأخير باستخدام أقراص التشفير الذاتي. هناك أيضًا صور آلة افتراضية مشفرة.
توجد أنظمة الملفات المشفرة في العديد من أنظمة التشغيل في المؤسسات ويمكن أن تدعم تثبيت الأقسام والأدلة المشفرة. يمكن أن تدعم أنظمة الملفات المشفرة التمهيد من محرك تمهيد مشفر. يدعم Linux تشفير جهاز الحظر باستخدام برنامج تشغيل dm-encrypt ؛ يعد ecryptfs أحد الأمثلة على نظام الملفات المشفر. حلول تشفير الملفات الأخرى المتاحة لنظام التشغيل Linuxالمصدر المفتوح. في Windows ، يدعم نظام الملفات NTFS v3.0 التشفير. بالإضافة إلى ذلك ، يقوم العديد من الشركات المصنعة بإنشاء أقراص ذاتية التشفير. بالنسبة لصور الآلة الافتراضية ، يوجد حل مشابه للأقراص المشفرة. يدعم محاكي QEMU Machine (PC) مفتوح المصدر ومنتجات VMware الافتراضية صور الآلة الافتراضية المشفرة.
يهدف تشفير البيانات عادةً إلى الحماية من سرقة البيانات عندما يكون النظام غير متصل بالإنترنت. هناك تقنية ذات صلة هي توقيع صورة الحاوية بمفتاح يوفره العميل وخادم Docker Notary. يعمل خادم Docker Notary على مقربة من سجل صورة الحاوية. يتمتع مستخدمو أداة عميل Docker بخيار التوقيع على صورة الحاوية وتحميل التوقيع إلى حساباتهم عبر Docker Notary. أثناء هذه العملية ، يرتبط التوقيع بصورة الحاوية عبر اسم المسار للصورة وإصداراتها. يتم إنشاء التوقيع باستخدام دالة تجزئة يتم حسابها بناءً على وصف محتويات الصورة بالكامل. يسمى هذا الوصف بيان صورة الحاوية.تعمل تقنية توقيع صورة الحاوية على حل مشكلة حماية صور الحاوية من الوصول غير المصرح به وتساعد على تحديد أصل صورة الحاوية.
بناء
تطور نظام Docker البيئي لتوحيد تنسيقات صور الحاوية باستخدام مجموعة معايير Open Container Initiative (OCI) ، والتي تتحكم الآن في تنسيق وقت تشغيل الحاوية (مواصفات وقت التشغيل) وتنسيق صورة الحاوية (مواصفات الصورة). نظرًا لأن عمل الفريق يتطلب امتدادًا لتنسيق صورة الحاوية الحالي ، فقد حددنا امتدادًا للمعيار لدعم الصور المشفرة. تصف الأقسام التالية صورة الحاوية الحالية وتنسيق الامتداد.
في المستوى الأعلى ، يمكن أن تتكون الحاوية من مستند JavaScript Object Notation (JSON) ، وهو عبارة عن قائمة ببيانات الصور. على سبيل المثال ، يمكنك استخدام قائمة البيانات هذه عند استخدام بنيات أو أنظمة أساسية متعددة لصورة الحاوية. تحتوي قائمة البيان على روابط لبيانات الحاويات ، واحدة لكل مجموعة من الهندسة المعمارية ونظام التشغيل. على سبيل المثال ، تتضمن البنى المدعومة amd64 و arm و ppc64le ، وتشمل أنظمة التشغيل المدعومة Linux أو Windows. يظهر مثال لقائمة من البيانات في لقطة الشاشة أدناه:
يصف حقل نوع الوسائط التنسيق الدقيق للمستند المحدد. تسمح قائمة البيانات هذه بالتوسيع المستقبلي واختيار المحلل اللغوي المناسب للمستند المعني.
المستوى أسفل قائمة البيانات هو البيان. البيان هو أيضًا مستند JSON ويحتوي على قائمة مرتبة من المراجع لطبقات الصورة. تحتوي هذه الروابط على نوع الوسائط الذي يصف تنسيق الطبقة. يمكن أن يصف التنسيق ما إذا كانت الطبقة مضغوطة ، وإذا كان الأمر كذلك ، فكيف. على سبيل المثال ، يمكن حفظ كل مستوى كملف .tar يحتوي على الملفات التي تمت إضافتها في مرحلة معينة في البناء عند تشغيل بناء عامل الإرساء في Dockerfile. غالبًا ما يتم حزم الطبقات باستخدام ملفات .gzip مضغوطة لتحسين كفاءة التخزين. يظهر مثال على مستند البيان في لقطة الشاشة التالية:
كما هو موضح ، تتم الإشارة إلى البيانات والطبقات من خلال "ملخص" ، والذي يكون عادةً دالة تجزئة sha256 في مستندات JSON. عادةً ما يتم تخزين البيانات والطبقات كملفات على نظام الملفات. غالبًا ما تكون أسماء الملفات عبارة عن وظائف تجزئة فوق المحتوى ، مما يسهل العثور عليها وتحميلها. نتيجة طريقة التجزئة هذه هي أن تغييرًا بسيطًا في المستند المرجعي يتسبب في حدوث تغييرات في جميع المستندات التي تشير إليه ، وصولاً إلى قائمة البيانات.
كجزء من مشروع فريقنا ، أنشأنا تشفير الصور بناءً على مخطط تشفير مختلط باستخدام مفاتيح عامة ومتماثلة. تُستخدم المفاتيح المتماثلة للتشفير الجماعي للبيانات (تُستخدم للتشفير متعدد المستويات) ، وتُستخدم المفاتيح العامة لتعبئة المفاتيح المتماثلة. استخدمنا ثلاث تقنيات مختلفة لتشفير المفتاح العام: OpenPGP و JSON Web Encryption (JWE) و PKCS # 7.
OpenPGP
OpenPGP عبارة عن تقنية تشفير وتوقيع شائعة الاستخدام لتشفير رسائل البريد الإلكتروني وتوقيعها. غالبًا ما تستخدمه المجتمعات مفتوحة المصدر أيضًا لتوقيع التزامات (علامات) التعليمات البرمجية المصدر في مستودعات git. إنه معيار إنترنت تم تحديده بواسطة IETF في RFC480 ويمكن اعتباره إصدارًا مفتوحًا لتقنية PGP المسجلة الملكية السابقة.
OpenPGP له تنسيقه الخاص لمفاتيح RSA. عادةً ما يتم تخزين المفاتيح في ملف حلقة مفاتيح ويمكن استيرادها من ملفات مفاتيح OpenPGP العادية. الجانب الأكثر ملاءمة لسلسلة مفاتيح OpenPGP هو أنه يمكن ربط المفاتيح العامة بعناوين البريد الإلكتروني لأصحابها. يمكنك العمل مع مستلمين متعددين للرسالة عن طريق تحديد قائمة المستلمين من خلال عناوين بريدهم الإلكتروني ، والتي تظهر بعد ذلك في المفاتيح العامة لهؤلاء المستلمين. بالإضافة إلى ذلك ، تم بناء شبكة ثقة حول هذه التقنية: يمكنك العثور على المفاتيح العامة للعديد من المستخدمين ، مرتبة حسب عناوين بريدهم الإلكتروني. على سبيل المثال ، غالبًا ما تُستخدم هذه المفاتيح لتوقيع علامات git.
يمكنك استخدام تنسيق الرسائل المشفرة OpenPGP لتشفير رسالة مجمعة إلى عدة مستلمين. يحتوي عنوان رسالة OpenPGP على كتلة واحدة لكل مستلم. تحتوي كل كتلة على معرف مفتاح 64 بت يخبر خوارزمية فك التشفير بمكان محاولة فك تشفير المفتاح الخاص المقابل. بعد فك تشفير النقطة المشفرة داخل الكتلة ، تظهر المفتاح المتماثل الذي يمكن استخدامه لفك تشفير الرسالة المجمعة. يعرض كل كائن تخزين ثنائي كبير للمفتاح العام المشفر للمستلم نفس المفتاح المتماثل.
استخدمنا OpenPGP بطريقة مماثلة ، ولكن في هذه الحالة ، فإن الرسالة المشفرة التي يرسلها ليست طبقة. بدلاً من ذلك ، يحتوي على مستند JSON ، والذي يحتوي بدوره على مفتاح متماثل يستخدم لتشفير وفك تشفير كل من الطبقة ومتجه التهيئة. نسمي هذا المفتاح مفتاح تشفير الطبقة (LEK) وهو شكل من أشكال مفتاح تشفير البيانات. ميزة هذه الطريقة هي أننا نحتاج فقط LEK واحد. باستخدام LEK ، نقوم بتشفير الطبقة لمتلقي واحد أو أكثر. يمكن أن يكون لكل مستلم (صورة حاوية) نوع مفتاح مختلف ، ولا يلزم أن يكون مفتاح OpenPGP. على سبيل المثال ، يمكن أن يكون مفتاح RSA بسيطًا. طالما لدينا القدرة على استخدام مفتاح RSA هذا لتشفير LEK ، يمكننا العمل مع مستلمين متعددين بأنواع مفاتيح مختلفة.
تشفير الويب JSON (JWE)
تشفير الويب JSON ، المعروف أيضًا باسم JWE ، هو معيار IETF آخر للإنترنت ويتم تعريفه في RFC7516 . هذا هو معيار تشفير أحدث من OpenPGP ، وبالتالي يستخدم أحدث الأصفار منخفضة المستوى المصممة لتلبية متطلبات التشفير الأكثر صرامة.
على نطاق أوسع ، يعمل JWE بطريقة مشابهة لـ OpenPGP من حيث أنه يحتفظ أيضًا بقائمة المستلمين والبريد الجماعي لرسالة مشفرة بمفتاح متماثل يمكن لكل مستلم للرسالة الوصول إليه. يمكن أن يكون لدى مستلمي رسالة JWE أنواع مختلفة من المفاتيح ، مثل مفاتيح RSA وأنواع مفاتيح منحنى بيضاوي محدد للتشفير ومفاتيح متماثلة. نظرًا لأن هذا معيار جديد ، فلا يزال من الممكن توسيع JWE لدعم المفاتيح في الأجهزة مثل TPMs أو وحدات أمان الأجهزة (HSM) باستخدام واجهات PKCS # 11 أو Key Management and Interoperability Protocol (KMIP). يتم استخدام JWEs بطريقة مشابهة لـ OpenPGP إذا كان لدى المستلمين مفاتيح RSA أو منحنيات بيضاوية.في المستقبل ، قد نقوم بتوسيعه لدعم المفاتيح المتماثلة مثل KMIP داخل HSM.
PKCS # 7
يتم تعريف PKCS # 7 ، المعروف أيضًا باسم Cryptographic Message Syntax (CMS) ، في IEFT RFC5652 . وفقًا لـ Wikipedia حول CMS ، "يمكن استخدامه للتوقيع رقميًا أو هضم أو مصادقة أو تشفير أي شكل من أشكال البيانات الرقمية."
إنه مشابه للتقنيتين الموصوفتين سابقًا من حيث أنه يسمح بتعدد المستلمين وتشفير الرسائل المجمعة. لذلك ، استخدمناه تمامًا مثل التقنيات الأخرى ، ولكن فقط للمستلمين الذين يقدمون شهادات لمفاتيح التشفير.
لدعم تقنيات التشفير الموصوفة سابقًا ، قمنا بتوسيع مستند البيان ليشمل المعلومات التالية:
- يتم تخزين رسائل OpenPGP و JWE و PKCS # 7 في خريطة التعليقات التوضيحية ، والتي تعد جزءًا من البيان.
- تحتوي كل طبقة محددة على خريطة واحدة. خريطة التعليقات التوضيحية هي في الأساس قاموس يحتوي على سلاسل كمفاتيح وسلاسل كقيم (أزواج مفتاح - قيمة).
لدعم تشفير الصور ، قمنا بتعريف المفاتيح التالية:
- org.opencontainers.image.enc.keys.openpgp
- org.opencontainers.image.enc.keys.jwe
- org.opencontainers.image.enc.keys.pkcs7
تحتوي القيمة المشار إليها بواسطة كل مفتاح على واحدة أو أكثر من الرسائل المشفرة لتقنية التشفير المقابلة. نظرًا لأن هذه الرسائل يمكن أن تكون بتنسيق ثنائي ، فهي بترميز base64. يجب أن تحتوي الطبقة المشفرة على تعليق توضيحي واحد على الأقل ، ولكن يمكن أن تحتوي على جميع التعليقات ، إذا كان لدى المستلم عدد كافٍ من أنواع المفاتيح المختلفة.
لتحديد أن الطبقة تم تشفيرها بـ LEK ، قمنا بتوسيع أنواع الوسائط الحالية بالملحق "+ مشفر" ، كما هو موضح في الأمثلة التالية:
- التطبيق / vnd.docker.image.rootfs.diff.tar + مشفر
- التطبيق / vnd.docker.image.rootfs.diff.tar.gzip + مشفر
توضح هذه الأمثلة أن الطبقة مضغوطة في ملف .tar ومشفرة - أو كلاهما مضغوط في ملف .tar وضغطهما في ملف .gzip وتشفيرهما. تُظهر لقطة الشاشة التالية مثالاً لبيان يرتبط بالطبقات المشفرة. كما تعرض أيضًا خريطة تعليق تحتوي على رسالة JWE المشفرة.
تشفير متعدد الطبقات باستخدام مفاتيح متماثلة
بالنسبة للتشفير المتماثل مع LEK ، اختار فريقنا تشفيرًا يدعم التشفير المصدق ويعتمد على معيار التشفير AES بمفاتيح 128 و 256 بت.
مثال على التنفيذ: containerd
قمنا بتنفيذ تبايننا في مشروع وقت تشغيل حاوية جديد يسمى containerd . يمكن الاطلاع على شفرة المصدر الخاصة به على golang باتباع الرابط . يستخدم Docker daemon containerd لتشغيل بعض خدماته ، ويحتوي Kubernetes على مكون إضافي لاستخدام containerd مباشرة. لذلك ، نأمل أن تكون امتداداتنا لدعم صور الحاوية المشفرة مفيدة لكليهما.
تنفيذ التشفير متعدد المستويات باستخدام LEK هو في أدنى مستوى معماري من الامتدادات. كان أحد متطلبات التنفيذ هو استيعاب طبقات حجمية من عدة غيغابايت مع الحفاظ على حجم الذاكرة المشغولة بالعملية التي تؤدي عملية التشفير على الطبقة بحجم بضعة ميغا بايت فقط.
يأخذ دعم خوارزميات التشفير المصادق عليها في Golang مصفوفة بايت كمدخلات وتؤدي كامل مرحلة التشفير (الختم) أو فك التشفير (الفتح) ، مما يمنع نقل المصفوفات الإضافية وإضافتها إلى التدفق. نظرًا لأن واجهة برمجة تطبيقات التشفير هذه تتطلب تحميل الطبقة بأكملها في الذاكرة أو اختراع مخطط ما لتغيير متجه التهيئة (IV) لكل كتلة ، فقد قررنا عدم استخدام تشفير golang المصدق مع دعم البيانات المرتبطة (AEAD). بدلاً من ذلك ، استخدمنا مكتبة تشفير golang الخاطئة التي تدعم AEAD في التدفقات(كتل) وتنفذ مخططها الخاص لتغيير IV في كل كتلة. في تطبيقنا ، قمنا بتقسيم الطبقة إلى كتل بحجم 1 ميغابايت ، والتي ننقلها واحدة تلو الأخرى للتشفير. يقلل هذا الأسلوب من حجم الذاكرة عند استخدام تشفير مصدق. من ناحية فك التشفير ، نقوم بالعكس وننتبه للأخطاء التي ترجعها الدالة Open () لضمان عدم العبث بكتل التشفير.
فوق التشفير المتماثل ، تقوم مخططات التشفير غير المتماثلة بتشفير LEK وناقل التهيئة (IV). لإضافة مخططات تشفير أو إزالتها ، نقوم بتسجيل كل تطبيق تشفير غير متماثل. عندما يتم استدعاء واجهة برمجة تطبيقات التشفير غير المتماثل لتشفير الطبقة ، فإننا ندعو معالجات التشفير المسجلة واحدة تلو الأخرى ، لتمرير المفاتيح العامة للمستلمين. بعد استخدام جميع مفاتيح المستلمين للتشفير ، نعود إلى خريطة التعليقات التوضيحية مع معرفات خوارزمية التشفير غير المتماثلة كمفاتيح تعيين ومع القيم التي تحتوي على الرسائل المشفرة في OpenPGP و JWE و PKCS # 7. تحتوي كل رسالة على حزمة LEK و IV. يتم تخزين خرائط التعليقات التوضيحية في مستند البيان كما هو موضح في لقطة الشاشة السابقة.
يمكننا أيضًا إضافة مستلمين إلى صورة مشفرة بالفعل. يضيف مؤلفو الصور مستلمين إذا كانوا في القائمة. يتم استخدام المفتاح الخاص لقائمة المستلمين ، وهو مطلوب لفك ضغط مستويات LEK و IV. ثم نلف LEK و IV في رسالة جديدة باستخدام مفتاح المستلم الجديد ونضيف هذه الرسالة إلى خريطة التعليق التوضيحي.
لقد استخدمنا ثلاثة أنواع من أنظمة التشفير غير المتماثل لأنواع مختلفة من المفاتيح. نستخدم مفاتيح OpenPGP لتشفير رسائل OpenPGP. يتطلب PKCS # 7 الذي نستخدمه شهادات x.509 لمفاتيح التشفير. يتعامل JWE مع جميع أنواع المفاتيح الأخرى مثل مفاتيح RSA البسيطة والمنحنيات الإهليلجية والمفاتيح المتماثلة. لقد وضعنا نموذجًا أوليًا لملحق JWE يسمح بعمليات التشفير باستخدام المفاتيح التي يديرها خادم KMIP.
يتضمن وقت تشغيل الحاوية أداة العميل ctr للتفاعل معها. لقد قمنا بتوسيع ctr لتمكين اختبار تغييراتنا وتوفير الوصول لمستخدمي الحاويات. يقوم ctr بالفعل بتنفيذ أمر فرعي يدعم عمليات الصور ، مثل التفاعل مع تسجيل الصور عن طريق جلب الصور وإرسالها.
لقد قمنا بتوسيع هذا الأمر الفرعي عن طريق إضافة وظائف لتشفير الصور وتمكين تشفير طبقات معينة من بنى محددة باستخدام مجموعة محددة من المفاتيح. يسمح هذا الأسلوب للمستخدمين بتشفير الطبقات التي تحتوي على بيانات حساسة فقط وترك الطبقات الأخرى غير مشفرة. يمكن إلغاء تكرار الأخير ، لكن هذا نادر الحدوث بالنسبة للطبقات المشفرة.
وبالمثل ، يمكننا فك رموز الطبقات الفردية للبنى الفردية. لقد أضفنا أمرًا فرعيًا layerinfo يُظهر حالة التشفير لكل طبقة ويعرض تقنيات التشفير المستخدمة لها. بالنسبة إلى OpenPGP ، يمكننا أيضًا عرض معرّفات المفاتيح اللازمة لفك التشفير ، أو تحويلها إلى عناوين البريد الإلكتروني للمستلمين باستخدام حلقة مفاتيح.
بالإضافة إلى ذلك ، يمكنك تصدير واستيراد صور الحاويات. لقد قمنا بتنفيذ دعم لتشفير الطبقة عند التصدير وفك التشفير عند الاستيراد. على الرغم من أننا نفك تشفير الطبقات لإنشاء نظام ملفات rootfs للحاوية ، يتم الاحتفاظ بالطبقات المشفرة وملفات البيانات الأولية الأصلية مثل بياناتها. يتيح لك هذا الأسلوب تصدير صورة مشفرة وإجراء فحوصات التفويض عندما يريد المستخدمون بدء حاوية بصورة مشفرة.
عندما يتم استرداد صورة عادية (غير مشفرة) من السجل ، يتم فك ضغطها وفك ضغطها تلقائيًا بحيث يمكن إنشاء الحاويات منها على الفور. لتسهيل الأمر على الصور المشفرة ، نقترح عليك تمرير المفتاح الخاص إلى فريق التفريغ حتى يتمكنوا من فك تشفير الطبقات قبل تفريغ العبوة. إذا تم تشفير الصورة بمفاتيح متعددة ، فيمكن تمرير مفاتيح متعددة لأمر السحب. هذا النقل مدعوم أيضًا. بعد الاستخراج الناجح للصورة المشفرة من السجل ، يمكن لأي شخص لديه حق الوصول إلى containerd إنشاء حاوية من الصورة. للتأكد من أن المستخدم لديه الحق في استخدام صورة الحاوية ، نقترح عليه تقديم المفاتيح الخاصة المستخدمة لفك تشفير الحاوية.نستخدم المفاتيح للتحقق من ترخيص المستخدم ، وما إذا كان يمكن استخدامها لفك تشفير LEK لكل مستوى مشفر ، وإذا تم تأكيد ذلك ، فإننا نسمح للحاوية بالبدء.
دليل خطوة بخطوة للتشفير باستخدام الحاوية د
في هذا القسم ، سوف نوضح خطوات التشفير التي يتم تطبيقها مع contairdd باستخدام ctr في سطر الأوامر. سنوضح لك كيفية تشفير وفك تشفير صورة حاوية.
بادئ ذي بدء ، تحتاج إلى استنساخ مستودع git containerd / imgcrypt ، وهو مشروع فرعي ويمكنه تشفير / فك تشفير صورة الحاوية. ثم تحتاج إلى بناء الحاوية وتشغيلها. لإكمال هذه الخطوات ، تحتاج إلى معرفة كيفية إعداد بيئة تطوير
golang : يتطلب imgcrypt إصدار الحاوية 1.3 أو إصدار أعلى.
بناء وتثبيت imgcrypt:
# make
# sudo make installقم بتشغيل containerd مع ملف التكوين الموضح في المثال أدناه. لتجنب التعارض في containerd ، استخدم الدليل / tmp للأدلة. أنشئ أيضًا الإصدار 1.3 من الحاوية من المصدر ، لكن لا تقم بتثبيته.
# cat config.toml
disable_plugins = ["cri"]
root = "/tmp/var/lib/containerd"
state = "/tmp/run/containerd"
[grpc]
address = "/tmp/run/containerd/containerd.sock"
uid = 0
gid = 0
[stream_processors]
[stream_processors."io.containerd.ocicrypt.decoder.v1.tar.gzip"]
accepts = ["application/vnd.oci.image.layer.v1.tar+gzip+encrypted"]
returns = "application/vnd.oci.image.layer.v1.tar+gzip"
path = "/usr/local/bin/ctd-decoder"
[stream_processors."io.containerd.ocicrypt.decoder.v1.tar"]
accepts = ["application/vnd.oci.image.layer.v1.tar+encrypted"]
returns = "application/vnd.oci.image.layer.v1.tar"
path = "/usr/local/bin/ctd-decoder"
# sudo ~/src/github.com/containerd/containerd/bin/containerd -c config.tomlأنشئ زوج مفاتيح RSA باستخدام أداة سطر أوامر openssl وقم بتشفير الصورة:
# openssl genrsa --out mykey.pem
Generating RSA private key, 2048 bit long modulus (2 primes)
...............................................+++++
............................+++++
e is 65537 (0x010001)
# openssl rsa -in mykey.pem -pubout -out mypubkey.pem
writing RSA key
# sudo chmod 0666 /tmp/run/containerd/containerd.sock
# CTR="/usr/local/bin/ctr-enc -a /tmp/run/containerd/containerd.sock"
# $CTR images pull --all-platforms docker.io/library/bash:latest
[...]
# $CTR images layerinfo --platform linux/amd64 docker.io/library/bash:latest
# DIGEST PLATFORM SIZE ENCRYPTION RECIPIENTS
0 sha256:9d48c3bd43c520dc2784e868a780e976b207cbf493eaff8c6596eb871cbd9609 linux/amd64 2789669
1 sha256:7dd01fd971d4ec7058c5636a505327b24e5fc8bd7f62816a9d518472bd9b15c0 linux/amd64 3174665
2 sha256:691cfbca522787898c8b37f063dd20e5524e7d103e1a3b298bd2e2b8da54faf5 linux/amd64 340
# $CTR images encrypt --recipient jwe:mypubkey.pem --platform linux/amd64 docker.io/library/bash:latest bash.enc:latest
Encrypting docker.io/library/bash:latest to bash.enc:latest
$ $CTR images layerinfo --platform linux/amd64 bash.enc:latest
# DIGEST PLATFORM SIZE ENCRYPTION RECIPIENTS
0 sha256:360be141b01f69b25427a9085b36ba8ad7d7a335449013fa6b32c1ecb894ab5b linux/amd64 2789669 jwe [jwe]
1 sha256:ac601e66cdd275ee0e10afead03a2722e153a60982122d2d369880ea54fe82f8 linux/amd64 3174665 jwe [jwe]
2 sha256:41e47064fd00424e328915ad2f7f716bd86ea2d0d8315edaf33ecaa6a2464530 linux/amd64 340 jwe [jwe]ابدأ تسجيل الصور المحلي الخاص بك حتى تتمكن من تحميل الصورة المشفرة إليه. لتلقي صور حاوية مشفرة ، تحتاج إلى أحدث إصدارات التسجيل.
# docker pull registry:latest
# docker run -d -p 5000:5000 --restart=always --name registry registryقم بتحميل الصورة المشفرة إلى السجل المحلي الخاص بك ، واستخرجها باستخدام ctr-enc ، ثم قم بتشغيل الصورة:
# $CTR images tag bash.enc:latest localhost:5000/bash.enc:latest
# $CTR images push localhost:5000/bash.enc:latest
# $CTR images rm localhost:5000/bash.enc:latest bash.enc:latest
# $CTR images pull localhost:5000/bash.enc:latest
# sudo $CTR run --rm localhost:5000/bash.enc:latest test echo 'Hello World!'
ctr: you are not authorized to use this image: missing private key needed for decryption
# sudo $CTR run --rm --key mykey.pem localhost:5000/bash.enc:latest test echo 'Hello World!'
Hello World!خاتمة
يعد تشفير صور الحاويات إضافة جيدة لأمنها ، فهو يضمن سرية البيانات وسلامة صور الحاويات في موقع التخزين. تعتمد التقنية المقترحة على تقنيات التشفير RSA والمنحنى البيضاوي و AES المتاحة للجمهور. يطبق مفاتيح لأنظمة التشفير ذات المستوى الأعلى مثل OpenPGP و JWE و PKCS # 7. إذا كنت تعرف كيفية العمل مع OpenPGP ، فيمكنك تشفير صور الحاوية لمستلمي OpenPGP باستخدام عناوين بريدهم الإلكتروني ، بينما تُستخدم مفاتيح RSA البسيطة والمنحنيات البيضاوية للتشفير مثل JWE.