حاويات اليوم لن تفاجئ أحدا. سوف تفاجأ بسؤال حول سلامة الحاويات. من المثير للاهتمام بشكل خاص أن نسأل الزملاء الذين يستخدمون الحاويات والخدمات الدقيقة في الإنتاج بكل جدية حول هذا الأمر: غالبًا ما أرى وجوهًا مفاجئة وسؤالًا محيرًا ، يقولون ، "ماذا ، لماذا هذا"؟ اتضح أننا نعرف بالفعل عن التكنولوجيا (وكيف لا يمكننا أن نعرف: يبدو أنه حتى أطفال المدارس سيكونون قريبًا قادرين على بناء مجموعة Kubernetes ككل في دروس التكنولوجيا) ، لكنهم لم يتعلموا بعد كيفية حماية مكوناتها. ربما لم يكن هناك من يعلم.
في هذه المقالة وعلى
DevOops ، سيكون لدينا متحدثون تناولوا كلبًا حول موضوع الحلول الأمنية الصديقة للحاويات. نذهب إليهم للحصول على إجابات لأبسط أسئلة الأمان السحابية. من الضروري البدء بالتعليم الذاتي بشيء؟
المشاركون:
يدير سيث فارجو محامي المطورين في Google. عمل سابقًا في HashiCorp و Chef Software و CustomInk والعديد من الشركات الناشئة الأخرى في بيتسبرغ. وهو مؤلف كتاب Learning Chef ويدافع عن الحد من عدم المساواة في التكنولوجيا.
ليز رايس هو مبشر تقني في Aqua Security ، وهو حل أمان نشر التطبيقات القائم على السحابة وحل الحاويات. ليز شخص مشهور جدًا في المجتمع ، رئيس Kubeon-s .
أوليغ شيروخين ، محرري مجموعة JUG.ru
لنبدأ بسؤال سيحدد مناقشتنا الإضافية. ماذا يعني DevOps لك؟ كيف تختلف عن SRE الأقل شهرة؟
على سبيل المثال ، في وظيفة سابقة ، عندما طُلب مني "تنفيذ DevOps" ، تجولت للتو حول جدول محتويات SRE Book ، وأخذت الأفكار وطبقتها واحدة تلو الأخرى. حسنًا ، أو على الأقل حاولت نقلها إلى الآخرين. ماذا تقول - هل هذا هو النهج الصحيح؟
إذا تحدثنا عن DevOps ، فإننا نتحدث عن تجنب الهاوية ، من الفجوة التي كانت عادةً بين عمليات تطوير الكود (Dev) وصيانتها اللاحقة (Ops). تخيل أن لدينا جدار مرتفع ، على جانب واحد يجلس فيه المطورون ، يقوم بإنشاء رمز ، ويلقي به على الحائط. على الجانب الآخر من الجدار يوجد أشخاص يشاركون في الدعم. يمسكون بالتطبيق المحول ويبدأون في الإطلاق والصيانة. وهؤلاء الناس يعرفون التفاصيل المطلوبة أثناء العملية. على سبيل المثال ، أي منافذ وأين سيتم تخصيصها وفتحها.
بدلاً من وجود مجموعتين منفصلتين من الأشخاص ذوي اهتمامات مختلفة ، أريد أن أجعلهم يتواصلون مع بعضهم البعض ، وأن يقرروا ما يجب فعله بعد ذلك ، معًا تحديد الأهداف التي سيحاولون تحقيقها معًا خلال يوم العمل. لذا فإن DevOps هو تغيير في ثقافة الاتصال يساعد الزملاء في الفرق الفنية المختلفة على العمل من أجل الصالح العام: خلق قيمة للأعمال ونشر البرامج والحفاظ على عملها. أعتقد أن هذه تغييرات مهمة جدًا ، وهي تحمل معها أدوات جديدة ذات صلة: إذا لم تكن لديك ثقافة اتصال ، فليس هناك جدوى من تقديم نفس عمليات CI / CD.
غالبًا ما يكون هناك ارتباك مع مفاهيم DevOps و SRE. يعتقد بعض الناس أن SRE تتنافس مع DevOps ، والبعض الآخر يعتبرونها مختلفة تمامًا ، وتتداخل المفاهيم. في رأيي ، هم ليسوا منافسين ، لكن أصدقاء مقربين. فكر في الأساليب التي تكمن وراء DevOps - تقليل التكاليف التنظيمية ، ومعالجة الفشل كجزء طبيعي من سير العمل ، وإدخال التغييرات تدريجيًا ، وأتمتة وتنفيذ الأدوات اللازمة لذلك ، واستخدام المقاييس لتقييم العمليات. كما ترى ، كل هذا مجرد تجريدي: DevOps لا يخبرنا عن كيفية تقليل التكاليف التنظيمية أو إدخال تغييرات تدريجية ، بل يخبرك فقط أنه سيكون لطيفًا إذا تم تنفيذها.
الآن دعونا نلقي نظرة على SRE. على الرغم من أن نهج SRE قد تطور بشكل مستقل عن نهج DevOps ، يمكن القول أن SRE هو تنفيذ لمبادئ DevOps: إذا كنت تتخيل DevOps كفئة أو واجهة مجردة في البرمجة ، فإن SRE ستكون فئة محددة تنفذ هذه الواجهة. حددت SRE بشكل واضح مناهج لمجموعة من الأشياء والمفاهيم: الملكية المشتركة ، وتقاسم المخاطر ، وبعد الوفاة ، وجمع وتراكم القيم المترية وأكثر من ذلك بكثير. لذلك ، من الملائم أكثر بالنسبة للمنظمات التحدث عن اعتماد SRE بسبب وجود عمليات وكيانات مفهومة للغاية.
هل تعتقد أن مصطلح "DevOps engineer" صحيح؟ هل يمكن استبداله بطريقة ما؟
أنا شخصياً لا أعتقد أن مفهوم "DevOps engineer" موجود. يمكنك أن تقرأ بمزيد من التفصيل في مقالتي "10 أساطير من DevOps" أن "DevOps" هي في الواقع أيديولوجية: مزيد من التواصل والتعاون بين الوحدات التنظيمية المختلفة ، ولكنها متصلة بشكل أساسي. على الرغم من أنه يبدو اليوم قويًا ومألوفًا تمامًا ، إلا أن مثل هذا النهج أثار في البداية الثناء والنقد القاسي. منذ ذلك الحين ، نجحت العديد من المنظمات ، بما في ذلك Etsy و Facebook و Flick ، في تنفيذ مبادئ DevOps بنجاح.
لذا ، لم تقم أي من هذه المنظمات بتعيين "مهندسي DevOps". يمكن أن يعزى نجاح التنفيذ إلى التعاون الداخلي الناشئ من الفرق والاستعداد لتغيير عملياتها وإجراءاتها الحالية من أجل تحقيق هدف مشترك. كان دور ما يسمى بـ "مهندس DevOps" هو تشجيع التعاون بين المجموعات وضمان تبادل الوحدات التنظيمية للأفكار والأهداف بانتظام. في الواقع ، لدينا بالفعل هؤلاء الناس اليوم ، ونسميهم "مديرين".
سأضيف لحظة أخرى. عندما نعين شخصًا في منصب أو دور معين ، نبدأ في توقع أشياء وأفعال معينة منه ، لذا فإن اختيار المسمى الوظيفي مهم. لكن الأسماء الدقيقة للمشاركات قد تختلف بسبب الحقائق والتقاليد المحلية التي تتبناها المنظمة ، لذلك من المهم ليس الاسم على هذا النحو ، بل التوازن بين منشورات جميع الأشخاص الذين يعملون في الشركة.
منذ وقت ليس ببعيد تحدثت مع شخص عمل في منظمة كبيرة إلى حد ما ، ولذلك أنشأوا فريقًا من عدة موظفين وأطلقوا عليه ، على سبيل المثال ، فريق البنية التحتية. ثم أعيدت تسمية هذا الفريق إلى شيء آخر ، وبعد فترة تم إنشاء فريق آخر ، والآن أطلق عليه فريق البنية التحتية - ونتيجة لذلك ، كان الجميع في حيرة من أمرهم: من هم "متخصصو البنية التحتية" وما هو دورهم.
في رأيي ، الشيء الأكثر أهمية ليس وجود فريق أو منصب باسم معين ، ولكن وجود داخل المنظمة لفهم واضح لمن المسؤول عن ماذا. لا يهم ما إذا كانوا يسمونهم SRE أو DevOps: الشيء الرئيسي هو فهم ما يعنيه اسم معين لهذه المنظمة بعينها.
ليز ، أنت تتشاور ، كيف تشرح مبادئ DevOps لشركات العملاء؟ تبدو مجردة تمامًا ويصعب تفسيرها إلى حد ما. أو ربما قمت بتطوير نوع من النهج الذي يسمح لك بنقل هذه الأفكار للعملاء؟
يعتمد على الغرض. يأتي إلينا العديد من الأشخاص والشركات الذين أتواصل معهم كجزء من المشاورات ويقولون إنهم يريدون نشر Kubernetes والحاويات. ولكن قبل الحديث عن التكنولوجيا ، عليك أن تفهم لماذا يحاولون اتخاذ مثل هذه الخطوات. وتبين أن الفوائد المتوقعة للتغيير تأتي في الغالب إلى الرغبة في أن تكون أكثر مرونة. ومن هنا جاءت الحركة في الاتجاه الذي يمكن فيه للفرق الفنية الإفراج عن نتائج عملهم بشكل أسرع ، شيء من هذا القبيل ، أوضح "على الأصابع". في هذه المرحلة ، من المفيد تحويل المحادثة إلى جانب أن مشكلة الافتقار إلى الثقافة (العادات ، إذا أردت) للتواصل بين أعضاء الفريق لن تساعد من خلال "رمي" التقنيات الجديدة ، فإن هذا التواصل هو المورد الأكثر أهمية.
بالإضافة إلى ذلك ، نظرًا لأنني غالبًا ما أجد نفسي منخرطًا في تحسين أمان الحلول ، فإن محادثتنا تتحول إلى "Dev - ** Sec ** - Ops" ، وتبين أن بناء النظام يجب أن يتم بطريقة تجعل في المراحل الأولى من العمليات ، ولم يقتصر الأمر على طرح السؤال بالطريقة القديمة: أولاً نكتب رمز التطبيق ، ثم ننشره ، ثم نمرره إلى خدمة الصيانة ، وفي النهاية فقط يبدأ شخص ما في التفكير في أمان النظام الجاري تشغيله.
في الواقع ، العديد من مشكلات الأمان أرخص وأسهل في الحل في بداية العملية ، ولكنك تحتاج إلى وضع الكثير من النقاط في المشروع منذ البداية. على سبيل المثال ، إذا كنت تنوي العمل مع حاويات ، فلا داعي للقلق من أن يتم جمع الصور بطريقة آمنة إلى حد ما. قد يكون من المفيد مسحها بحثًا عن الثغرات الأمنية على الأقل لتجنب نشر برامج بها مشكلات أمنية معروفة بالفعل. ربما ستحاول تكوين الحاويات بحيث لا يبدأ البرنامج الموجود فيها افتراضيًا بجذر (كما هو الحال غالبًا من أجل البساطة ، دون الحاجة الخاصة ، يتم إجراؤها عند تجميع الحاويات). إذا اتخذت هذه الخطوات ، فستتلقى في النهاية زيادة في أمان تطبيقك ، ويمكنك ، في سياق كل DevOps هذا ، التحدث عن ثقافة SecOps.
ومع ذلك ، هذا يعني أن المطورين ، في الواقع ليسوا خبراء في أمان التطبيقات ، يضطرون إلى التفكير ليس فقط في رمز التطبيق ، ولكن أيضًا في إنشاء أنظمة الأمان الخاصة بهم. ما هو إذن ، في رأيك ، الحد الأدنى لمجموعة المهارات لمطور برامج حديث أو مهندس تشغيل؟
أنت وأنا ، سواء أحببنا ذلك أم لا ، نرى باستمرار ظهور قواعد ومتطلبات جديدة تبين في مرحلة ما أنها ضرورية للامتثال والامتثال: خذ على سبيل المثال نفس اللائحة العامة لحماية البيانات. ظهور ووجود هذه اللوائح يعني أن عددًا متزايدًا من الناس يجب أن يكون لديهم شعور بالأمن. على سبيل المثال ، لم يعد بإمكانك اليوم تخزين أسماء المستخدمين وكلمات المرور في شكل نص عادي في حقول قاعدة البيانات - لم يعد هذا مقبولًا على الأقل. أود أن أقول أنه في الصناعة هناك بالفعل بالفعل متطلبات واضحة للجميع "النظافة".
لمصنعي الأدوات والبنى التحتية أنفسهم تأثير كبير على هذه العملية ، حيث يحاولون تصميم وتغيير الأنظمة حتى يتمكن المستخدمون من بناء تطبيقات وأنظمة أكثر أمانًا منذ البداية. على سبيل المثال ، في Kubernetes على مدار العام الماضي ، تغيرت العديد من الإعدادات الافتراضية وقيم المعلمات نحو أمان أكبر ، وهذا أمر رائع حقًا. سابقًا ، كان خادم واجهة برمجة التطبيقات (API) مفتوحًا بشكل افتراضي للدخول المجهول - وهذا ليس تمامًا ما تتوقع رؤيته "خارج الصندوق". الآن ظهرت أشياء مثل التحكم في الوصول القائم على الأدوار ، لذلك لدينا الآن أذونات (نعم ، "خارج الصندوق") ، وعندما تبدأ Kubernetes لأول مرة ، فأنت لست مفتوحًا للعالم كله ، فأنت محمي افتراضيًا. أعتقد أن هذه طريقة جيدة لإتاحة الأمان للجميع في سياق العمليات المألوفة ، لأنه لا يتعين علينا تغيير القيم الافتراضية باستمرار إلى قيم آمنة (والتي ، علاوة على ذلك ، يجب وضعها في الاعتبار).
أنا شخصياً أعتقد أن كل مهندس برمجيات يجب أن يكون لديه على الأقل فهم أساسي للأمن. تأتي أشياء مثل نهج OWASP (مشروع أمان تطبيق الويب المفتوح) في طريق الإنقاذ ، ولكن في النهاية يحتاج المهندسون إلى التعليم الذاتي. من غير المحتمل أن يكون لكل مهندس شهادة دكتوراه في التشفير ، ولكن إذا أردنا أن يأخذ زملائنا الأمن على محمل الجد ، فيجب علينا أن نسهل عليهم اتخاذ القرارات الصحيحة. هذا هو المكان الذي يمكن أن تساعد فيه أدوات مثل Vault - ويمكن لفرق الأمان والمهنيين اتخاذ القرارات وتوفير "الأمان كواجهة برمجة تطبيقات".
إذا فهمت بشكل صحيح ، فهناك ميل لتحويل كل شيء إلى رمز. كل شيء كرمز. البنية التحتية ككود ، العمليات ككود ، رمز ككود. ما هي الآثار؟
قبل أن نتحدث عن العواقب ، نحتاج إلى التحدث عن الفوائد. الكود موجود منذ فترة طويلة. كانت التطبيقات دائمًا "رمز" ، وخلال هذا الوقت تم إنشاء نظام بيئي شامل من الأدوات والعمليات لدعم وتحسين عملية تطوير التطبيقات (CI / CD ، linting ، وأدوات التطوير المشترك ، وما إلى ذلك). بعد وصف البنية التحتية ككود ، وعمليات ككود ، وأمن ككود ، يمكننا استخدام نفس النظام البيئي ، دون دفع أي شيء إضافي لذلك. يمكنك تطوير تغييرات البنية التحتية معًا ، وإجراء مراجعات للسياسة ، وما إلى ذلك. يمكنك اختبار تغييرات البنية التحتية قبل نشرها. هذه ليست سوى بعض الفوائد التي تأتي مع ترجمة شيء إلى رمز.
أعتقد أن أكبر العواقب هي الوقت والتعقيد. عندما تتعامل مع شيء "مثل الرمز" (على سبيل المثال ، من خلال Terraform و Vault و CloudFormation و Deployment Manager وما إلى ذلك) ، في بعض الأحيان يجب أن تواجه اختلافات بين ما هو مكتوب في الرمز وما يحدث بالفعل في السحابة. يصعب أحيانًا إنشاء نماذج للعلاقات المعقدة بصريًا ، خاصة بالنظر إلى التوسع. بالإضافة إلى ذلك ، قد نواجه عدم دقة التجريد - على سبيل المثال ، قد لا يدرك النص الذي يعمل من خلال واجهة برمجة التطبيقات الحالة الراهنة كما يتم عرضها للمستخدمين من خلال واجهة الويب. ومع ذلك ، بمرور الوقت ، ينخفض التعقيد وتعود المرونة.
تعد الشفرة والنماذج الرسمية الأخرى مجالًا مناسبًا للتحليل الآلي وتعلم الآلة. متى ستحل الروبوتات محلنا بالضبط؟ كيف نرد؟
هل يمكن للروبوتات تكوين Kubernetes بدون بشر؟ على وجه الخصوص ، قد يحدث أن بعض المهن (مثل مسؤول النظام أو اختبار البرمجيات بمستوى عالٍ من التفاعل - كلمة مقبولة اجتماعيًا لـ "اختبار يدوي") تختفي ببساطة؟
لا أعتقد أن الناس سوف يختفون ، لكني أشك في أن بعض الوظائف التي لدينا اليوم لن يتم حفظها في المستقبل. أعيش في بيتسبرغ ، العاصمة العالمية لأنظمة التحكم في السيارات المستقلة ، وأرى السيارات ذاتية القيادة حرفياً كل يوم. بالطبع ، في المستقبل ، سيتم استبدال سائقي سيارات الأجرة بتقنيات القيادة الآلية. ربما ليس على الفور ، ولكن بعد 10 سنوات أو أكثر ، ولكن هذا المستقبل سيأتي حتمًا. ومع ذلك ، أعتقد أن سائقي سيارات الأجرة لن يختفيوا. الإنسانية تعيد اختراع نفسها باستمرار.
أعتقد أنه يمكن قول الشيء نفسه عن التعلم الآلي في مجال الإدارة. أتطلع لمزيد من الذكاء الاصطناعي لجعل أنظمتنا أكثر استقرارًا ومرونة ، وأعتقد أنه يمكننا أن نقرر محاربة هذا النهج - أو قبوله. يمكن استبدال دور مسؤولي النظام التقليدي بشخص يتحكم في نظام الذكاء الاصطناعي ، ولكن هذا لا يعني أن الأشخاص أنفسهم سيختفون. لقد شهدنا نفس التحولات في العديد من الصناعات حيث قدمت التكنولوجيا والابتكار سرعة ودقة أعلى من الناس ، ولكن في النهاية ، يحتاج شخص ما إلى متابعة الروبوتات :).
تخيل أن فريق التطوير المنتظم يقوم بإنشاء تطبيق ويب ، ووضعه في مجموعة Kubernetes. كيف يمكننا التأكد من أن التطبيق آمن؟ استأجر مخترقًا أو متخصصًا في Blackhat يحاول العثور على نقاط ضعف أمنية ، أو هل هناك طرق أقل تعقيدًا؟
أطلقنا في Aqua Security مؤخرًا أداة مفتوحة المصدر تسمى kube-hunter . إنه قادر على اختبار Kubernetes للقرصنة أو الاختراق - مما يجعله اختبارًا بسيطًا إلى حد ما. يمكنك استخدام هذه الأداة واختبار المجموعة الخاصة بك ، ومن شبه المؤكد أنك ستتعلم شيئًا مثيرًا للاهتمام لنفسك ، خاصةً إذا كان التثبيت الخاص بك يعتمد على الإصدار القديم من Kubernetes ، حيث كانت الإعدادات الافتراضية أقل أمانًا - ربما لديك ، على سبيل المثال المنافذ المفتوحة.
لقد سمعنا جميعًا قصصًا عن الأشخاص الذين "نسوا" إغلاق لوحة تحكم المجموعة الخاصة بهم من الوصول المجاني إلى الإنترنت بالكامل ، لذلك كان الهدف من إنشاء kube-hunter هو التحقق من نظامنا الخاص والتأكد من أنه محمي. في رأينا ، كان المخترقون يبحثون منذ فترة طويلة عن المضيفين على الإنترنت بحثًا عن موارد ومنافذ مفتوحة ومعروفة ، لذلك قد لا يكون من الصعب العثور على لوحة تحكم Kubernetes (وبالتالي مفتوحة للجميع) ، خاصة مع الأدوات التي اعتادوا على استخدامها.
نريد الصياد لمساعدة مسؤولي Kubernetes العاديين على فهم أفضل إذا كانت هناك مشكلات في التكوين في نشرهم ، لذلك فقد تم تصميمها حصريًا لـ Kubernetes والتقارير التي تم العثور عليها بلغة يفهمها مستخدمو Kubernetes. لذا سنخبرك بأنك لم تفتح أي منفذ 6443 ، ولكن لنفترض ، على سبيل المثال ، الوصول إلى هذا المكون الخاص بـ Kubernetes. بهذه الطريقة ، يكون من الأسهل على الأشخاص تحديد ما إذا كانوا قد وجدوا مشكلة في تكوين إضعاف الأمان وما إذا كان الأمر يستحق إصلاحه على الفور - دون أن يكون خبير أمن Kubernetes. نريد أن نجعل هذه الشيكات متاحة في أي وقت ، دون الحاجة إلى خبراء خارجيين.
هناك ملاحظة: لم يعد الكثيرون مهتمين بما هو داخل الحاويات التي يطلقونها.
نعم ، وليس لديهم أي فكرة عن التبعيات التي تم بناؤها في هذه الحاويات. على الرغم من أنك إذا كنت تخطط لاستخدام نهج الحاوية لنشر الخدمة ، فيبدو من المعقول معرفة نوع البرنامج الموجود داخل هذه الصورة أو تلك. لكن هذه ليست مشكلة نهج الحاوية نفسها ، إنها مجرد موقف للأمن من جانب أولئك الذين يستخدمون هذا النهج.
ليس من الصعب القيام بكل شيء بشكل صحيح وموثوق. لنفترض أنك عندما تنتقل إلى عالم السحابة ، تحتاج إلى البدء في استخدام أدوات إضافية - والتي ستضيف بالتأكيد مستويات إضافية من الأمان.
الغيوم لها تفاصيلها الخاصة. على سبيل المثال ، غالبًا ما أقابل الاعتقاد الخاطئ بأنه في عالم السحابة ، فإن الأداة التي اعتاد عليها الناس في العصور القديمة ستقوم تلقائيًا بكل ما يحتاجونه. في بعض النواحي ، هم على حق: لنفترض أنه يمكنك استخدام قائمة إعدادات جدار الحماية المعتادة (والعمل دائمًا) ، وهذا سيعزز الأمان ، ولكن بعض الأدوات القديمة لم تعد مناسبة اليوم. على سبيل المثال ، إذا قمت بنشر صورة حاوية واستخدمت الأداة القديمة المألوفة للمسح بحثًا عن نقاط الضعف ، فعندئذ إذا لم يعرف الماسح الضوئي كيفية النظر داخل الصورة ، فلن يجد ببساطة أي شيء ، وستحصل على ثقة (ربما خاطئة) بأن كل شيء في محله.
أنا حقًا أحب ذلك عندما تنتقل إلى بنية الخدمات المصغرة ، تحصل على عدد كبير إلى حد ما من الوظائف الصغيرة الموضوعة في حاويات (محتوياتها في راحة يدك) ويمكنك رؤية حركة المرور بينها. يمكن النظر إلى كل حاوية على أنها نوع من الصندوق الأسود ، والتي من المتوقع أن يتم اتخاذ إجراءات محددة بدقة. وبمجرد أن تبدأ هذه الحاوية أو تلك في التصرف بطريقة غير متوقعة أو تحقيق نتائج غريبة ، يصبح من الممكن الاستجابة لذلك. كلما كانت الصور الخاصة بالحاويات يتم تجميعها وتكوينها بشكل أفضل ، كلما كان من المفهوم أنها ستعمل بشكل صحيح.
وكيف تصطاد الشذوذ؟ استخدام شيء مثل الاستدلال مكافحة الفيروسات والشبكات العصبية؟
طوال دورة حياة البرنامج ، نستخدم أدوات أمان مختلفة. runtime enforcer — , , . «», , , nginx, , nginx . , , «» , . , , . : , , .
. Serverless , , . . « »? , ?
, severless , , , . serverless — . severless-, «», . , «- ». severless. serverless- . «» , ( «» ) .
serverless – « ». serverless- pub/sub, , Redis . , , - () .
severless- , . , , , serverless- . - . , , , . serverless, - .
, serverless- . , , . ?
, , — , , , DevOps. , , , , .
, , : YAML. , Kubernetes Kubernetes, YAML. , 30 000 YAML. , , , 30 000 YAML, , , .
, Kubernetes . , , ?
Kubernetes , . , , , , - , . , , YAML- , , Kubernetes . , . , .
, Kubernetes — , . . , Kubernetes CNCF graduated, , , , , CNCF .
, : YAML, , . , YAML Kubernetes.
, YAML, , , , YAML. , , , - YAML .
, Kubernetes, , ?
سؤال جيد. , , , , . – Istio ( service mesh), 1.0. , , , «».
, - , .
, ?
مسح صور حاوياتك بحثًا عن نقاط الضعف. سوف تفاجأ بمعرفة عدد الأشخاص الذين ينشرون الرمز دون معرفة ما بداخله!
تعلم باستمرار! بالعودة إلى السؤال السابق بأن الروبوتات تشغل وظائفنا: الطريقة الوحيدة لمنع ذلك هي عدم الاسترخاء والتعلم طوال الوقت.
يوم الأحد المقبل ، في مؤتمر DevOops 2018 ، سيقدم سيث عرضًا تقديميًا حول "الأمان الحديث مع الخدمات الصغيرة والسحابة" ، وستقدم ليز "خطوات عملية لتأمين نشر الحاوية الخاصة بك" . يمكن شراء التذاكر على الموقع الرسمي .