كيف تحافظ على الأسرار؟ في مستودع ، في نظام النشر أو في نظام إدارة التكوين؟ على جهاز كمبيوتر شخصي ، على خوادم ، أو ربما في صندوق تحت السرير؟ وكيف تدير الأسرار لمنع التسريبات؟
يعرف سيرغي نوسكوف ( Albibek ) - رئيس مجموعة أمن المعلومات في المنصة من Avito ، الإجابة على هذه الأسئلة وسوف
يشاركنا . في Avito ، يستخدم HashiCorp Vault بنشاط HashiCorp Vault لمدة عامين ، وخلال هذه الفترة حصلوا على المطبات وضخ الخبرة إلى مستوى "Master".
في هذا المقال ، سنتحدث بشكل شامل عن Vault: ما هو وأين وكيف يتم استخدامه في الشركة ، وكيف تدير Avito الأسرار باستخدام HashiCorp Vault ، وكيفية استخدام Puppet و Kubernetes ، واستخدام الحالات مع Puppet و SCM الأخرى ، ما هي المشاكل التي تنشأ ، وما الذي يضر بالأمان والمطورين ، وبطبيعة الحال ، تبادل الأفكار حول كيفية إصلاحه.
ما هو السر؟
أي معلومات سرية:
- تسجيل الدخول وكلمة المرور ، على سبيل المثال ، إلى قاعدة البيانات ؛
- مفاتيح API
- مفتاح شهادة الخادم (* .google.com)
- مفتاح شهادة العميل (الشركاء ، أموال ياندكس ، QIWI) ؛
- مفتاح لتوقيع تطبيقات الهاتف المحمول.
جميع المعلومات التي نريد أن نبقيها سرية ، نسميها سرية. هذا يخلق مشكلة تخزين: التخزين في المستودع سيء ، في شكل مشفر - تحتاج إلى الاحتفاظ بمفاتيح التشفير في مكان ما.
يعد HashiCorp Vault أحد الحلول الجيدة للمشكلة.
- بأمان مخازن وإدارة المفاتيح.
- شحذ على عالم الخدمات المصغرة ، منذ الخدمة الصغيرة نفسها.
- قامت HashiCorp Vault بالكثير من أجل المصادقة على الوصول إلى الأسرار والتصريح بها ، مثل قوائم ACL ومبدأ الحد الأدنى من الامتيازات.
- واجهة الراحة مع JSON.
- الأمن ليس مثاليًا ، ولكن على مستوى مرتفع إلى حد ما.
في رأيي ، هذه أداة مريحة إلى حد ما.
ما الجديد في HashiCorp Vault
يتم تطوير الأداة وفي السنوات الأخيرة ظهرت العديد من الميزات المثيرة للاهتمام: رؤوس CORS لـ GUI بدون وسطاء. المدمج في واجهة المستخدم الرسومية. الاندماج الأصلي مع Kubernetes ؛ الإضافات للخلفية المنطقية والمصادقة والإطار.
معظم التغييرات التي أعجبتني شخصيًا هي
القدرة على عدم كتابة إضافات وإضافات ستقف خارج الأداة.
على سبيل المثال ، هناك Vault ، وتريد توسيعه - كتابة منطق إضافي أو واجهة المستخدم الخاصة بك للتشغيل الآلي ، والتي ستعمل على أتمتة شيء ما. قبل التغييرات ، اضطررت إلى رفع خدمة إضافية يواجهها Vault ، وتعيين جميع الطلبات: أولاً تذهب الطلبات إلى الخدمة ، ثم إلى Vault. هذا أمر سيء لأنه في الخدمة الوسيطة قد يكون هناك مستوى أمان منخفض ، وكل الأسرار تمر به.
المخاطر الأمنية أعلى بكثير عندما يمر السر عبر عدة نقاط في وقت واحد!مشكلة الدجاج والبيض
عندما تثير مشكلة تخزين المعلومات السرية وتقرر تشفيرها ، بمجرد تشفير شيء ما ، ينتقل سريتك من مكان التشفير إلى مكان تخزين المفتاح. يحدث هذا طوال الوقت: بمجرد قيامك بحفظ أحد الأسرار في مكان ما أو تغيير أحدها الحالي ، يكون لديك واحدًا آخر وتبدأ دائرة مسحورة -
حيث يمكنك الاحتفاظ بسرية الوصول إلى السر .
سر الوصول إلى السر هو ذلك الجزء من الأمان الذي يسمى
المصادقة . الأمن لديه جزء آخر -
إذن. في عملية التفويض ، يتم التحقق مما إذا كان يمكن للمستخدم الوصول إلى المكان الذي يطلبه بالضبط. في حالة Vault ، يوجد طرف ثالث موثوق به يقرر ما إذا كان سيتم التخلي عن السر أم لا. إذن فقط يحل المشكلة جزئيا.
HashiCorp قبو في Avito
في Avito ، يتم تثبيت HashiCorp في التثبيت الكبير الوحيد على الشبكة بالكامل. HashiCorp Vault له العديد من الجوانب المختلفة. نحن نستخدم الخلفية القائمة على
القنصل أيضًا من HashiCorp ، لأن Vault لا يمكنها إلا أن تدعم تسامحها مع الأعطال من خلال القنصل.
Unseal هي طريقة لعدم الاحتفاظ بالمفتاح الرئيسي في مكان واحد. عند بدء تشغيل Vault ، يقوم بتشفير كل شيء على مفتاح ، ومرة أخرى تظهر مشكلة الدجاج والبيض: حيث يتم الاحتفاظ بسرية ، والتي سوف تشفر جميع الأسرار الأخرى. لتجنب هذه المشكلة ، يوفر Vault مفتاحًا مركبًا ، والذي يتطلب عدة أجزاء من المفتاح ، والتي نوزعها على العديد من الموظفين. في Avito ، قمنا بتهيئة Unseal في الخيارات لثلاثة أشخاص من أصل 7. إذا بدأنا Vault ، فيجب أن يأتي 3 أشخاص على الأقل ويدخلون جزءهم من المفتاح حتى يبدأ العمل. ينقسم المفتاح إلى 7 أجزاء ويمكنك إحضار أي منها.
لقد قمنا بتجميع اختبار Vault صغير ، وهو صندوق رمل للمطورين حيث يمكنهم اللعب. إنه على شكل حاوية Docker ويخلق أسرار بسيطة حتى يتمكن الناس من لمس الأداة بأيديهم ، والراحة. لا يوجد قنصل ومجموعات في صندوق الحماية ، إنه مجرد نظام ملفات يحمل Vault أسرارًا مشفرة ونصًا صغيرًا لبدء التهيئة.
إليك ما نقوم بتخزينه الآن في Vault:
- جميع أسرار Krosnetes microservices تقريبًا: كلمات مرور قاعدة البيانات ، مفاتيح API ، كل ما سبق.
- أسرار لوضع على خوادم "الحديد" و LXC.
- نضع أيضًا أسرار لتصميم CI / CD في TeamCity في Vault. التغطية ليست 100 ٪ ، ولكنها مقبولة تماما.
- مفاتيح جميع الشهادات: PKI الداخلية ، والمراجع المصدقة الخارجية ، على سبيل المثال ، GeoTrust وما شابه.
- أسرار مشتركة للفرق.
في الداخل ، يقوم Vault بتخزين كل شيء فقط في JSON ، وهو ليس مناسبًا دائمًا ويتطلب إجراءات إضافية من المطور ، لذلك ننشر الأسرار بشكل أساسي في شكل ملف.
نحاول تسليم الأسرار في شكل ملفات.
نحن لا نقول للمطور: "اذهب إلى Vault ، خذ سراً!" ، لكن ضع الملف على القرص ونقول: "Developer ، سيظهر ملف على قرصك ، يأخذ السر منه ، وسنكتشف بالفعل كيفية الحصول عليه من Vault وإحضاره. لك ".
لقد اعتمدنا اتفاقية بسيطة لحقول JSON ، والتي نشير فيها إلى أي حقوق تحميل الملف. هذا هو بيانات التعريف لنظام الملفات ، وحقل البيانات هو سلسلة مشفرة مع السر نفسه ، والتي سوف تصبح محتويات الملف.
دمية + هييرا + قبو
تستخدم جميع البنية التحتية لشركة Avito تقريباً Puppet ، وهي تعمل على نشر جميع الخوادم.
لدى Puppet أداة ملائمة لتنظيم التسلسلات الهرمية -
Hiera . يتكامل Vault بشكل جيد مع Hiera من خلال وحدة إضافية ، لأنه يتم إرسال طلب قيمة المفتاح إلى هذه المكتبة ، و Vault نفسها هي قاعدة بيانات ذات قيمة مفتاح ، ولكن مع جميع ميزات الأمان - مع تشفير شفاف وإمكانية اختيار الوصول إلى المفاتيح.
لذلك ، أول ما قمنا بتطبيقه هو Vault in Puppet ، ولكن مع إضافة واحدة - لدينا طبقة متوسطة تسمى
Router backend . الخلفية التوجيه - وحدة نمطية منفصلة Hiera ، فقط الملفات على القرص الذي يقول حيث يجب أن تذهب Hiera للمفتاح - في Vault أو في مكان آخر.
هناك حاجة إليه حتى لا تذهب Hiera إلى Vault باستمرار ، لأنها دائمًا ما تذهب عبر التسلسل الهرمي. هذه ليست مشكلة Vault أو تحميل عليها ، ولكن ميزة Hiera نفسها. لذلك ، إذا تركت الوحدة النمطية لـ Vault فقط دون الواجهة الخلفية لجهاز التوجيه ، فسوف يستغرق برنامج Puppet الرئيسي وقتًا طويلاً للغاية لجمع التكوين الخاص بعامل Puppet ، حيث سيتحقق من كل مفتاح في Vault.
بالنسبة إلى Puppet ، يتم حل مشكلة الدجاج والبيض نظرًا لحقيقة أن الطرف المخوّل هو المعلم الرئيسي. هو الذي يعطي السر للوصول إلى السر. يستطيع برنامج Puppet الرئيسي الوصول إلى جميع الأسرار في وقت واحد ، لكن يُسمح لكل مضيف باستلام السمة المخصصة لها فقط. تمت المصادقة بالفعل على المضيف على برنامج Puppet الرئيسي بشهادته ، والتي يتم إنشاؤها محليًا ولا تترك حدود المضيف. من حيث المبدأ ، يبقى سر الوصول إلى السر ، لكن هذا ليس بالغ الأهمية.
تتكون عملية الكشف عن سر جديد في Puppet من الخطوات التالية.
- نأخذ سراً في مكان ما - شخص ما يقدمه لنا أو يخرجه.
- وضع سر في Vault ، مع تسلسل هرمي كما في Hiera: /puppet/role/www/site.ssl.key .
- نقوم بتسجيل بادئة في بيان Puppet ، مع الإشارة إلى أن الملف موجود في Vault وأين يمكن الحصول عليه.
- نكتب المسار في Vault في YAML لجهاز التوجيه Hiera والخلفية حتى يتمكن Hiera من العثور عليه.
- سحب الطلب عبر GIT إلى مستودع البيان.
- قم بتشغيل أو انتظر تشغيل عميل Puppet.
يهرب عملاء الدمى معنا كل 30 دقيقة ، لذلك عليك الانتظار قليلاً حتى ينفد السر. هذا لا يسبب مشاكل -
نحن لا نشارك الأسرار كل يوم . طالما لم تشارك Kubernetes في العمل ، فلا يوجد الكثير من النفقات العامة ونحن على استعداد لوضع أسرار في Vault بأيدينا مع الحد الأدنى من الأتمتة.
إضافةً إضافية نحصل على "الرقاقة" Hiera -
يمكن وضع السر على الفور لمجموعة من المضيفين أو اعتمادًا على دور المضيف ، الذي وضعناه في الدور المتغير.
الخطر الوحيد: إذا كان لديك Puppet وكنت تستخدم Hiera ، فلا تحل محل أي شيء في الطريق لقوالب متغير ، لأنه يتم جمع العديد من الحقائق والمتغيرات من جانب العميل. إذا استبدل المهاجم حقيقة على العميل ، فإن سيد العرائس سوف يمنحه أسرار الآخرين.
تأكد من التحقق من المتغيرات : استخدم فقط تلك التي لا يسمح برنامج Puppet-master بتحديدها من جانب العميل.
ماذا تفعل مع SCM دون معالج؟
إذا لم يكن لديك دمية فجأة ، فمن الأرجح أنسيبل. بالنسبة إلى Chef وغيرها من SCMs المركزية ، فإن حلولهم هي مكون إضافي يمكنه الوصول إلى Vault. أقدم العديد من الخيارات التي يمكن تنفيذها مع Ansible.
وكيل محلي
محليًا للخادم ، قم بإنشاء رمز مميز ، وهو في الواقع كلمة المرور للوصول إلى Vault. الرمز المميز صالح طوال الوقت. يمكنك تحديثه أو أتمتة. باستخدام هذا الرمز المميز ، تذهب إلى Vault وتسلب أسرارك.
الفكرة هي أنه على الخادم الخاص بك حيث تحتاج إلى تسليم الأسرار ، فإن العامل الذي يأتي إلى Vault يدور ، وينظر في جميع الأسرار ويضعها في شكل ملفات. نحن نستخدم الوكيل على عدة خوادم منفصلة حيث لا يوجد دمية.
سلبيات:- يسهل إدخال الرمز المميز في شريحة صغيرة ، ولكن إذا كان لديك عدة خوادم موصولة يوميًا ، فسيتعين عليك إنشاء رمز مميز لكل خادم ويصف السياسة. هذا غير مريح.
- يحتاج الرمز إلى تحديث.
- من الصعب تجميع الخوادم حسب الدور أو الغرض أو الحقائق ، ويجب مزامنتها مع Vault.
تشفير العبور
يحتوي Vault على وظيفة تشفير عبور ، وجوهرها هو أن Vault يعمل كخادم
تشفير . عليك فقط إحضاره نصًا غير مرئي ، وعلى مفتاحه الخاص ، الذي لديه فقط ، يشفر ويصدر النص المغلق. ثم اختر من يمكنه فك تشفير هذا النص المغلق.
Ansible لديه كيان ، وتسمى أيضا Vault. هذه ليست HashiCorp Vault ، ولكن
Ansible Vault . ليست هناك حاجة للتشويش ، ويمكن تخزين الأسرار في الأول والثاني. يحتوي Ansible على مكون إضافي جاهز لتقديم الأسرار من Hashicorp Vault. إذا منحت حق الوصول الشخصي إلى Vault ، فيمكنك فك تشفير الأسرار. عندما تقوم بتدوير Ansible ، فإنه ينتقل إلى Vault نيابة عنك ، ويقوم بفك تشفير الأسرار المشفرة في المستودع ، ويقوم بتحويله إلى مرحلة الإنتاج.
يوجد أيضًا عيب -
كل مسؤول يمكنه الوصول إلى الأسرار . ولكن هناك مراجعة: يعرف Vault كيفية الاحتفاظ بسجل نشاط حول المستخدم الذي جاء ، والسرية التي يقرؤها ، والتي تمكن الشخص من الوصول إليها. أنت تعرف دائما من ومتى وماذا فعلت بسر. هذا الخيار يبدو جيدا بالنسبة لي.
عيب كبير # 1
أكبر عيب يسبب أكبر ألم لنا هو أنه في Vault لا يمكنك تفويض التحكم الكامل في أي
جزء من البيانات إلى أي شخص. في Vault ، يتم الوصول إلى السر بطرق مشابهة لتلك الموجودة في UNIX - عادة ما تكون الأسماء مفصولة بشرطة مائلة ، والنتيجة هي "دليل". عندما يكون لديك مثل هذا المسار ، فأنت تريد أحيانًا المشاركة في المسار ومنحه لشخص آخر للتحكم فيه.
على سبيل المثال ، حصلت على شهادات ، تسمى
/ certs ، وتريد منحها إلى ضباط الأمن الأفراد الذين يتعاملون مع PKI. المدفن لا يمكن القيام بذلك. لا يمكنك منح الحق في إصدار حقوق داخل هذه البادئة - حتى يتمكن حراس الأمن أنفسهم من توزيع الحقوق على الشهادات لشخص آخر.
لا يتمتع Vault بالقدرة على منح حقوق منح الحقوق بشكل انتقائي . بمجرد منحك الحق في منح الحقوق ، أعطيت أيضًا الفرصة للوصول الكامل إلى جميع الأسرار. بمعنى آخر ، لا يمكنك منح حق الوصول إلى جزء Vault.
هذه هي واحدة من أكبر المشاكل. لدي فكرة عن كيفية حلها ، سأخبرك عنها لاحقًا.
Kubernetes
في RIT ++ ،
تحدثت عن نظام منفصل قمنا بتطبيقه على
Kubernetes : إنه يعمل كطرف ثالث ، ويذهب إلى API ،
ويفحص الوصول ، ثم يطلب سرًا في Vault.
الآن فقد نظامنا أهميته ، لأنه في Vault 0.9 ، ظهر دعم محلي لـ Kubernetes. الآن يعرف Vault بنفسه كيفية الانتقال إلى Kubernetes والتأكد من السماح بالوصول إلى السر. يفعل هذا مع
رمز حساب الخدمة . على سبيل المثال ، عندما يكون لديك ملف مطوي ، هناك
JWT خاص وموقع ومصرح به ، مصمم لطلبات واجهة برمجة تطبيقات Kubernetes. باستخدام رمز مميز ، يمكنك أيضًا تسجيل الدخول إلى Vault والحصول على أسرار خاصة بمساحة الاسم الخاصة بك.
كل شيء يتم على مستوى Vault نفسه. صحيح ، سيكون من الضروري بدء دور لكل مساحة اسم ، أي ، أخبر Vault أن هناك مساحة اسم ، سيكون هناك إذن بذلك ، والتسجيل إلى أين تذهب إلى Kubernetes. يتم ذلك مرة واحدة ، ثم ينتقل Vault إلى واجهة برمجة التطبيقات (API) نفسها ، ويؤكد صحة JWT ويصدر رمز الوصول الخاص به.
قواعد Kubernetes
من حيث اسم الخدمة والبيانات الوصفية الإضافية ، نحن نثق بالمطورين. هناك فرصة صغيرة أن يحصل المطورون بطريق الخطأ أو عن قصد على أسرار الخدمات الأخرى التي تدور في مساحة اسم واحدة ، لذلك قدمنا قاعدة:
خدمة واحدة -
مساحة اسم واحدة.خدمات microservice جديدة؟ الحصول على مساحة اسم جديدة مع أسرارك. لا يمكنك عبور الحدود إلى الحدود المجاورة - هناك رمز حساب الخدمة الخاص بك.
الحدود الأمنية في Kubernetes في الوقت الحالي هي مساحة الاسم. إذا كنت تحتاج إلى اثنين من مساحة الاسم ، فقم بنسخه.
Kubernetes لديه
أسرار kubernetes . يتم تخزينها في غيرها في Kubernetes في شكل غير مشفرة ويمكن أن "تضيء" في لوحة القيادة أو عندما تبدأ kubectl القرون. إذا تم تعطيل المصادقة في etcd في نظامك ، أو إذا منحت شخصًا حق الوصول الكامل للقراءة فقط ، تكون كل الأسرار مرئية له. هذا هو السبب في أننا قدمنا قاعدتين:
يحظر استخدام أسرار kubernetes ويحظر تحديد أسرار في متغيرات البيئة في البيانات . إذا كتبت سرًا في البيئة أثناء النشر. yaml ، فهذا أمر سيء ، لأنه يمكن مشاهدة البيان نفسه من قبل أي شخص ليس كسولًا.
تسليم Kubernetes
كما قلت ، يجب أن نضع الملف بطريقة ما في Kubernetes. لدينا نوع من السر: الجوهر ، كلمة المرور ، المكتوبة بلغة JSON في Vault. كيف يمكن تحويله إلى ملف داخل الحاوية في Kubernetes الآن؟
خيار التسليم الأول.
- نبدأ حاوية الحرف الأول الخاصة.
- يبدأ من صورتنا.
- تحتوي الصورة على أداة مساعدة صغيرة تذهب إلى Vault مع رمز حساب الخدمة ، وتضع السر وتضعه في وحدة التخزين المشتركة.
- بالنسبة للأداة المساعدة ، يتم تثبيت وحدة تخزين مشتركة خاصة فقط في ذاكرة TMPFS بحيث لا تمر الأسرار عبر القرص.
- ينتقل حاوية التهيئة إلى Vault ، وتضع في هذا المجلد في شكل ملفات جميع الأسرار التي يعثر عليها في المسار المحدد.
- بعد ذلك ، يتم تثبيت وحدة التخزين المشتركة في الحاوية الرئيسية المطلوبة.
- عندما يتم تشغيل الحاوية الرئيسية ، تحصل فورًا على ما يحتاجه المطور - أسرار في شكل ملف على القرص.
يحتاج المطور فقط إلى تذكر المسار الذي يكمن فيه سره.
نستخدم شيئًا مثل هذه البادئة:
/k8s/<cluster>/<namespace>/<service>/some_secret
يحتوي اسم البادئة على اسم الكتلة ومساحة الاسم واسم الخدمة. كل خدمة لها سرها الخاص ، ولكل مساحة اسمها سرها الخاص.
الخيار الثاني هو نقطة الدخول
الخاصة بك. ننتقل الآن إلى ذلك في Avito ، لأن المطورين يواجهون مشكلات في init-container. في الرسم التخطيطي ، يكون هذا الخيار على اليمين.
لا يمكن للجميع تحمل نقطة الدخول الخاصة بهم. يمكننا ، لذلك في كل حاوية نفرض نقطة الدخول الخاصة بنا.
تعمل نقطة الدخول الخاصة بنا على نفس حاوية init: إنها تنتقل إلى Vault مع رمز حساب الخدمة ، وتأخذ الأسرار وتضعها في الحسبان. بالإضافة إلى الملفات ، يعيدها إلى البيئة. تتاح لك الفرصة لتشغيل التطبيق على النحو الموصى به في مفهوم
تطبيق Twelve-Factor : يأخذ التطبيق جميع الإعدادات ، بما في ذلك الأسرار ، من متغيرات البيئة.
متغيرات البيئة غير مرئية في البيان ولوحة القيادة ، حيث يتم تعيينها بواسطة PID 1 (عملية الحاوية الرئيسية) عند بدء التشغيل. هذه ليست متغيرات البيئة من Publishing.yaml ، ولكن متغيرات البيئة التي تم تعيينها بواسطة نقطة الدخول في العملية. لا تكون مرئية في لوحة المعلومات ، فهي غير مرئية ، حتى إذا قمت بإجراء kubectl exec في حاوية ، لأنه في هذه الحالة يتم إطلاق عملية أخرى ، بالتوازي مع PID1.
سير العمل
من وجهة نظر تنظيمية ، تكون العملية كما يلي. يتعلم المطور من بطل الأمان أو من الوثائق أنه لا ينبغي أن يحتفظ بالأسرار في المستودع ، ولكن في Vault فقط. ثم يأتي إلينا ويسأل عن مكان وضع الأسرار - يقدم طلبًا للأمان لإنشاء بادئة. في المستقبل ، يمكنك إنشاء بادئة بدون طلب ، فور إنشاء خدمة.
المطور ينتظر ، وهذا أمر سيء ، لأن الشيء الرئيسي بالنسبة له هو الوقت المناسب للسوق. ثم يقرأ التعليمات ويتعامل مع الملفات الطويلة - "أدخل هذا السطر هناك ، أدخل هذا السطر هنا". لم يشرع أحد المطورين أبدًا في تشغيل حاوية أولية من قبل ، لكنه اضطر إلى اكتشافها وتسجيلها في publish.yaml (مخطط الدفة).
Commit -> deploy -> feel pain -> fix -> repeatإنه يلتزم ، وينتظر بدء TeamCity ، ورؤية الأخطاء في TeamCity ، ويبدأ في الشعور بالألم ، ويحاول إصلاح شيء ما ، ويعاني الألم مرة أخرى. بالإضافة إلى ذلك ، يتم فرض أن كل نسخة في TeamCity لا تزال قائمة الانتظار. في بعض الأحيان ، لا يستطيع أي مطور اكتشاف ذلك بنفسه ، ويأتي إلينا ، ونقوم بتسويتها معًا.
في الأساس ، يعاني المطور بسبب أخطائه:
حاوية init المحددة بشكل غير صحيح أو لم يقرأ الوثائق .
الأمن لديه أيضا مشاكل. يتلقى حارس الأمن تطبيقًا لا يتوفر فيه سوى القليل من المعلومات ، وما زلنا نكتشف الأسئلة المفقودة: تعرف على أسماء المجموعات ، ومساحة الاسم للخدمة ، نظرًا لأن المطور لا يشير إليها في التطبيق ولا يعرف دائمًا ما هو عليه. عندما نكتشف كل شيء ، وننشئ سياسات وأدوار في Vault ، ونصف السياسات للمجموعات ، ومع المطور ، نبدأ في معرفة أين ولماذا ارتكب خطأ ، وسنقوم معًا بقراءة السجلات.
تساعد وحدة "الهندسة المعمارية" في حل المشكلة عن طريق الاختباء من مطور النشر. إنهم يقومون بتطوير قطعة تنشئ كل شيء للمطور ، بما في ذلك نقطة الدخول. نظرًا لحقيقة أننا نستبدل نقطة الدخول الخاصة بنا ، يمكننا استخدامها ليس فقط لتقديم الأسرار ، ولكن أيضًا للأشياء الأخرى التي قد تحتاج إلى القيام بها عند بدء التشغيل.
مشاكل واضحة مع أسرار Kubernetes.
- سير عمل معقد للغاية لكل من المطور وحارس الأمن.
- لا يمكنك تفويض أي شيء لأي شخص. يتمتع حارس الأمن بالوصول الكامل إلى Vault ، ولا يمكن الوصول الجزئي (انظر Big Flaw # 1).
- تنشأ الصعوبات عند نقل المطورين من مجموعة إلى أخرى ، من مساحة الاسم إلى مساحة الاسم ، عندما تكون هناك حاجة إلى أسرار مشتركة ، لأنه من المفترض في البداية أن الأسرار المختلفة مختلفة في مجموعات مختلفة.
نقول: "لماذا تحتاج أسرار الإنتاج في مجموعة ديف؟ الحصول على سر الاختبار ، وتذهب معها! " نتيجة لذلك ، هناك
الألغام والأسرار التي يصعب إدارتها. إذا تغير السر ، يجب ألا تنسى ذلك ، اذهب وتغيره في كل مكان ، وبينما لا توجد طريقة لتحديد أنه هو نفس السر ، باستثناء باسم الخدمة.
الفكرة: Kubernetes KMS
في الإصدارات الجديدة من Kubernetes ، يعتبر نظام KMS الفرعي ، Key Management Service ، ميزة تشفير سرية جديدة لـ Kubernetes. في الإصدار 1.11 كان في حالة ألفا ، في الإصدار 1.11 تم نقله إلى إصدار تجريبي.
الصورة مأخوذة من موقع مشروع موفر KMS لـ Vault ، وهناك خطأ في ذلك. إذا وجدت - اكتب في التعليقات.معنى KMS هو التخلص من عيب واحد - تخزين البيانات غير المشفرة في etcd.
يمكن لـ KMS ، مثل Ansible ، القيام بذلك.
- اذهب إلى مكان ما ، وقم بتشفير سر Kubernetes الأصلي ووضعه في صورة مشفرة.
- إذا لزم الأمر ، تسليم إلى جراب ، فك تشفير ووضعها في شكل فك تشفير.
قام المطورون بكتابة خدمة خاصة تقوم بذلك باستخدام تشفير العبور. يبدو أن الفكرة تعمل ، لكن من المهم أن تتذكر أن الأسرار تتوقف عن أن تكون تحت سيطرة Vault وتذهب إلى مكان آخر ، في نطاق مسؤولية مسؤولي Kubernetes.
سلبيات KMS.
- التخزين اللامركزي - الاستيلاء من Vault إلى Kubernetes (etcd) . لا يمكن التحكم في الأسرار بواسطة Vault ، وهو جيد كمستودع مركزي للأسرار. اتضح أن نصف الأسرار في Vault ، ونصفها في مكان آخر.
- حل Kubernetes فقط . إذا كان لديك بنية تحتية خاصة بـ Kubernetes فقط ، فستلتقط Vault ، ولا تفكر تقريبًا في ما يتم تخزينه هناك أنه يحتوي فقط على مفاتيح التشفير التي تديرها بشكل صحيح - تدويرها بانتظام ، وما إلى ذلك ... الأسرار نفسها موجودة في Kubernetes ، وهذا مناسب.
- من الصعب مشاركة الأسرار بين المجموعات . لكل مجموعة جديدة ، تحتاج إلى البدء من جديد ، قد لا يعمل نسخ الأسرار كما في حالة Vault واحد.
إيجابيات KMS.
- الدعم الأصلي في Kubernetes ، بما في ذلك الاختباء عند إظهار البيئة.
- إذن في مجال مسؤولية Kubernetes .
- لا يلزم دعم Vault تقريبًا .
- دوران المفتاح من خارج منطقة الجزاء .
CI / CD: TeamCity
كل شيء بسيط في TeamCity ، لأن JetBrains كتب مكونًا إضافيًا يمكنه أن يصف الأسرار للوصول إلى السر ، ويشفرها مع TeamCity ، ثم يستبدلها في المئة في القالب في مكان ما في القالب. في هذه اللحظة ، ينتقل عميل TeamCity نفسه إلى Vault ، ويأخذ السر ويجلبه إلى البنية كمعلمة.
هناك حاجة إلى بعض الأسرار أثناء النشر ، على سبيل المثال ، ترحيل قاعدة البيانات أو التنبيهات في سلاك. يتم تشغيل AppRole لكل مشروع - تحتوي الإعدادات أيضًا على سر (بيانات AppRole) ، ولكن يتم إدخاله في وضع الكتابة فقط - لا يسمح TeamCity بقراءته لاحقًا.
يعتني TeamCity نفسه بأنه عندما يدخل السر سجلات البناء ، فإنه يخفي نفسه تلقائيًا. كنتيجة لذلك ، السر لا "يمر" عبر القرص على الإطلاق ، أو يتم مسحه من القرص باستخدام أدوات TeamCity. كنتيجة لذلك ، يتم ضمان أمان النظام بالكامل من خلال TeamCity نفسه والمكوّن الإضافي ، كما أن الرقصات الإضافية مع الدف ليست مطلوبة
CI / CD ليس TeamCity؟
هذه هي المشكلات الرئيسية التي يجب مراعاتها إذا كنت تستخدم نظامًا مختلفًا (وليس TeamCity) مثل CI.
- العزلة: قصر نطاق السر على المشروع أو الفريق أو ما إلى ذلك.
- الذي يجيز الوصول إلى السر.
- استبعد القدرة على عرض سر الطرف المفوض.
- هناك مرحلة منفصلة من الإنشاء وهي استيراد السر إلى الملفات.
- تنظيف بعد نفسك.
نتيجةً لذلك ، على الأرجح سوف تكتب شيئًا مشابهًا جدًا للبرنامج المساعد TeamCity لجهاز CI / CD. من المرجح أن يكون الطرف المرخص له هنا هو CI / CD ، وسيكون هو الذي سيقرر ما إذا كان هذا البناء يمكنه الوصول إلى هذا السر ، وما إذا كان سيعطي السر نفسه بناءً على النتائج أم لا.
من المهم ألا تنسى
تنظيف نتائج البنية في نهاية التجميع ، إذا كانت قد وضعت على قرص ، أو للتأكد من أنها في الذاكرة فقط.
الشهادات
لا يوجد شيء خاص بالشهادات - نستخدم Vault بشكل أساسي لتخزينها.
يحتوي Vault على خلفية PKI خاصة لإصدار الشهادات ، حيث يمكنك إنشاء مرجع مصدق وتوقيع شهادات جديدة. لدينا PKI داخلي واحد ... يوجد المرجع المصدق الجذر و المرجع المصدق من المستوى الثاني بشكل منفصل ، و ندير بالفعل المرجع المصدق من المستوى الثالث من خلال Vault. لتخزين الشهادات الصادرة من أي مستوى ، بما في ذلك الشهادات الموقعة من المراجع المصدقة الخارجية ، نستخدم بادئة منفصلة ، ونضع جميع الشهادات الصالحة تقريبًا هناك لأغراض المحاسبة والمراقبة. يعد تنسيق تخزين الشهادات ملكية خاصة ، وهو مناسب لتخزين مفتاح خاص منفصل والشهادة نفسها.
ملخص
الكثير من العمل اليدوي للحارس الأمني ،
والكثير للغاية من عتبة الدخول للمطور ، ولا توجد أدوات تفويض مدمجة ، على الرغم من أنني أريد حقًا ...
كيف تكون ثم تبدأ الأحلام.
الأفكار: كيف نفعل ما هو أفضل
كيف يمكنني التخلص من مجموعة من النسخ السرية؟
تسليم السيد والعبد
لدينا سر رئيسي وشيطان خاص يتجول ، وينظر إلى السر والبيانات الوصفية الخاصة به ، ويضعها عند الضرورة ، ويتحول إلى سر للرقيق. في الطريق الذي نشر فيه الخفي العبد ، لا يمكن تغيير أي شيء باليد ، لأن الخفي سيأتي ويعيد وضع السر الرئيسي أعلى العبد.
في البداية ، أردنا إنشاء آلية للارتباط التشعبي للإشارة ببساطة إلى: "ابحث عن هذا السر هناك!" ، كما هو الحال في نظام Linux. لقد تبين أن هناك مشاكل في حقوق الوصول: من غير المعروف كيفية التحقق من حقوق الوصول - مثل نظام التشغيل Linux أم لا ، مع المسارات الرئيسية ، مع الانتقال بين نقاط التحميل. هناك الكثير من اللحظات والفرص الغامضة لارتكاب خطأ ، لذلك رفضنا الروابط.
إذن الملكية
الشيء الثاني الذي نريد القيام به هو
تحديد المالك لكل سر . بشكل افتراضي ، ينتمي السر إلى الشخص الذي قام بإنشائه. إذا لزم الأمر ، يمكنك توسيع مجال المسؤولية إلى الوحدة عن طريق إصدار مجموعة المالكين.
عندما نتعلم التفويض ، سنمنح المالك الحق في الحصول على سرية ، وسيكون قادرًا على القيام بالسرية بما يريد.
- تنتشر في k8s - يتم إنشاء سياسة ، يتم إنشاء نسخة الرقيق.
- انتشار على الخادم - يتم إنشاء سياسة ، ويتم إنشاء نسخة من الرقيق.
- انتشار في CI / CD - ...
- نقل إلى مالك آخر.
- منح وصول جديد ، وإنشاء قوائم ACL جديدة.
الآن نحن مسؤولون عن كل الأسرار والأمان ، لكننا نريد تحويل المسؤولية إلى الخالق.
لن يتأثر الأمان ، لأن الشخص الذي أتى إلينا لطلب الاحتفاظ بسرية يدرك أنه يحتاج إلى الاحتفاظ بسرية بأمان ويدرك مسؤوليته.
نظرًا لأنه هو مالك السر ، بالنسبة لخيار تسليم السيد والعبد ، فيمكنه اختيار مكان ونسق تسليمه إليه. اتضح أن المالك يدير كل شيء بنفسه ، ليست هناك حاجة لتقديم الطلبات ، يمكنك أن تأخذ البادئة اللازمة بنفسك ، كما يمكنك إنشاء وحذف الأسرار بنفسك.
تفويض من خلال قوالب ACL
تنقسم سياسة الوصول إلى قائمة التحكم في الوصول في Vault إلى قسمين:
- قائمة التحكم في الوصول في العرض الكلاسيكي ، الذي يصف الوصول إلى البادئة ، وطريقة القراءة والكتابة ، والتي للقراءة فقط ، إلخ.
- عند إنشاء قائمة ACL بالداخل ، يمكنك كتابة علامة نجمية في النهاية ، مما يعني "هذه البادئة ، وكل شيء تحتها". يمكن تعيين البادئة كعملية منفصلة ، تُعطى للمستخدم أو المجموعة ، أي ، مرفقة بعدة كيانات مختلفة.
الآن ، يمكن لمسؤول Vault فقط تغيير ACL. بعد الوصول إلى مثل هذا ACL ، يمكنك وصف كل ما تريده في الداخل ، على سبيل المثال ،
path “*” { capabilities = [sudo, ...] } ، والحصول على حق الوصول الكامل. هذا هو جوهر
أكبر عيب # 1 -
من المستحيل منع تغيير محتويات قائمة التحكم في الوصول (ACL).نريد تعيين قوائم ACL مع قالب جاهز يحتوي على المسار والعناصر النائبة التي يُسمح لها بإنشاء قوائم ACL جديدة لهذا القالب.
مثال
يوجد أدناه الخط الأصفر ومسار ACL القياسي النهائي من Vault ، بالإضافة إلى زيادة الإجراءات المسموح بها على هذا المسار. نحن نعتبرها ACL للحصول على إذن لتغيير قائمة ACL أخرى ، والتي يتم تقديمها في شكل قالب.
نريد تفويض الوصول إلى / k8s ، نسمح فقط بإنشاء مثل هذه القوالب. على سبيل المثال ، امنح حق الوصول للقراءة فقط إلى كتلة معينة أو مساحة اسم أو خدمة ، ولكن لا تقم بتغيير حقل القدرات.
بالإضافة إلى ذلك ، نريد منح إذن لربط قوائم ACL هذه وإصدار حقوق مختلفة.
طبقنا القالب لمنح حقوق للمطور. عندما templating ، كان يدير الأمر
$ vault write policy-mgr/create/k8s-microservice ... . ونتيجة لذلك ، حصلنا على قائمة ACL تنص على الكتلة = prod ، مساحة الاسم = ... ، الخدمة = ... إلخ. تم تعيين الحقوق تلقائيًا ، وتم إنشاء سياسة بالاسم
/k8s/some-srv - هذا هو مجرد اسم ACL الذي يمكن إنشاؤه من القالب.
نتيجةً لذلك ، يقوم المطور ، وفقًا لتقديرنا ، بتخصيص ACL لأي شخص يريد ، ويصبح المالك نفسه ، يمكنه إدارته كسرية: حذف المستخدمين والمجموعات وإعطائهم والابتعاد عنهم. الآن الشخص نفسه مسؤول عن البادئة: فهو يدير جميع الأسرار ، ويقوم بإنشاء قوائم ACL وفقًا للقالب ، ويمكنه تعيين قوائم ACL لمن يريد. بطبيعة الحال ، يمكننا الحد من ذلك أيضا.
كل السحر يعمل مع كيان Vault الجديد -
الإضافات . إنها خدمة منفصلة تشبه الخدمة التي ذكرتها في البداية وتعمل تمامًا تقريبًا. الفرق الوحيد المهم هو أنهم ليسوا وكلاء. يتم تشغيل المكونات الإضافية "على الجانب" من Vault ، وتطلق عملية Vault الرئيسية. نتيجةً لذلك ، لا تمر جميع الطلبات عبر الخدمة ، بل تذهب إلى Vault ، التي تتفاعل هي نفسها بالفعل مع المكون الإضافي ، وترسل إليها طلبًا تم التحقق منه ومسحه.
حول المكونات الإضافية ، وكيف يتم ترتيبها وكيفية كتابتها ، يمكنك أن تقرأ
على موقع Vault الإلكتروني . من الأفضل أن تكتبهم على Go ، وهو أمر بسيط للغاية ، لأن هناك إطار عمل لـ Go. يتصل Vault بالمكون الإضافي عبر grpc ، ويقوم بتشغيله كخدمة ، ولكن لا تخف ، لا تلمسها - كل شيء موجود بالفعل في الإطار. يمكنك فقط كتابة تطبيق REST قياسي أو أكثر تحدد فيه نقاط النهاية ، ومنحهم وظائف جاهزة ، ومعالجات لها منطق.
لا تخف من كسر شيء في المدفن الرئيسي. البرنامج المساعد هو خدمة منفصلة. حتى إذا أصيب المكوّن الإضافي بالذعر وتعطل ، فلن يكسر عمل Vault. سيقوم Vault ببساطة بإعادة تشغيل المكون الإضافي ومواصلة العمل.
بالإضافة إلى ذلك ، هناك إعدادات إضافية للمكون الإضافي نفسه: إنه يتحقق دائمًا من مبالغ التجزئة بحيث لا يغير أي شخص ثنائي.
يتم توفير أمان تشغيل الإضافات .
روابط مفيدة:
سنتحدث عن DevOps والأمان و CI / CD و k8s و Puppet وكل ذلك في HighLoad ++ (الأقرب في St. Petersburg في أبريل) و DevOpsConf . تعال شارك تجربتك أو انظر إلى الآخرين. حتى لا تنسَ ، اشترك في المدونة والرسائل الإخبارية ، والتي سنذكرك بالمواعيد النهائية وجمع المواد المفيدة.