कंटेनर आज किसी को आश्चर्यचकित नहीं करेंगे। कंटेनर सुरक्षा के बारे में सवाल पर आपको आश्चर्य होगा। यह उन सहयोगियों से पूछना विशेष रूप से दिलचस्प है जो इस बारे में सभी गंभीरता से उत्पादन में कंटेनरों और माइक्रोसर्विसेज का उपयोग करते हैं: अक्सर मुझे आश्चर्यचकित चेहरे और एक चिंतित प्रश्न दिखाई देता है, वे कहते हैं, "यह क्या है, क्यों है"? यह पता चला है कि हम पहले से ही तकनीक के बारे में जानते हैं (और हम कैसे नहीं जान सकते हैं: ऐसा लगता है कि स्कूली बच्चे भी जल्द ही कुबेरनेट्स क्लस्टर को पूरी तरह से प्रौद्योगिकी पाठ में बना पाएंगे), लेकिन उन्होंने अभी तक यह नहीं सीखा है कि इसके घटकों की सुरक्षा कैसे करें। शायद सिखाने वाला कोई नहीं था।

इस लेख में और DevOops पर, हमारे पास ऐसे स्पीकर होंगे जो कंटेनर-अनुकूल सुरक्षा समाधान के विषय पर एक कुत्ते को खा गए। हम सबसे सरल क्लाउड सुरक्षा प्रश्नों के उत्तर के लिए उनके पास जाते हैं। कुछ के साथ स्व-शिक्षा शुरू करना आवश्यक है?

प्रतिभागी:

सेठ वर्गो Google पर डेवलपर एडवोकेट चलाते हैं। उन्होंने पहले हाशिकार्प, शेफ सॉफ्टवेयर, कस्टमइनक, और पिट्सबर्ग में कई अन्य स्टार्टअप में काम किया। वह लर्निंग शेफ के लेखक हैं और प्रौद्योगिकी असमानताओं को कम करने के लिए वकालत करते हैं।

लिज़ राइस एक्वा सिक्योरिटी में एक तकनीकी इंजीलवादी है, जो क्लाउड-आधारित एप्लिकेशन परिनियोजन सुरक्षा और कंटेनर एंटरप्राइज़ समाधान है। लिज़ समुदाय का एक बहुत प्रसिद्ध व्यक्ति है, जो कुबोन-एस का अध्यक्ष है।

ओलेग चिरुखिन, JUG.ru समूह के संपादक

---

आइए एक प्रश्न के साथ शुरू करें जो हमारी आगे की चर्चा को निर्धारित करेगा। DevOps का आपके लिए क्या मतलब है? यह कम ज्ञात एसआरई से कैसे अलग है?
उदाहरण के लिए, एक पिछली नौकरी में, जब मुझे "DevOps को लागू करने" के लिए कहा गया था, मैं सिर्फ सामग्री की SRE पुस्तक तालिका के आसपास चला गया, विचारों को पकड़ा और उन्हें एक-एक करके लागू किया। खैर, या कम से कम मैंने उन्हें दूसरों तक पहुँचाने की कोशिश की। आप क्या कहते हैं - क्या यह सही तरीका है?

---

यदि हम DevOps के बारे में बात करते हैं, तो हम खाई से बचने के बारे में बात कर रहे हैं, उस खाई से जो आमतौर पर कोड विकास प्रक्रियाओं (देव) और इसके बाद के रखरखाव (ऑप्स) के बीच थी। कल्पना करें कि हमारे पास एक ऊंची दीवार है, जिसके एक तरफ डेवलपर्स बैठते हैं, वह एक कोड बनाता है, इसे दीवार के ऊपर फेंकता है। दीवार के दूसरी तरफ लोग समर्थन में लगे हुए हैं। वे स्थानांतरित एप्लिकेशन को पकड़ते हैं और लॉन्च करना और बनाए रखना शुरू करते हैं। और ये लोग ऑपरेशन के दौरान आवश्यक विवरण जानते हैं। उदाहरण के लिए, कौन से पोर्ट और कहां आवंटित किए जाएंगे और खोले जाएंगे।

अलग-अलग रुचियों वाले लोगों के दो अलग-अलग समूह होने के बजाय, मैं उन्हें एक-दूसरे के साथ संवाद करना चाहता हूं, यह तय करना है कि आगे क्या करना है, साथ में यह निर्धारित करें कि वे कार्य दिवस के दौरान एक साथ क्या लक्ष्य हासिल करने की कोशिश करेंगे। तो DevOps संचार की संस्कृति में एक बदलाव है जो विभिन्न तकनीकी टीमों में सहयोगियों को अच्छे के लिए काम करने में मदद करता है: व्यवसाय के लिए मूल्य बनाएं, सॉफ़्टवेयर को तैनात करें और इसे काम करते रहें। मुझे लगता है कि ये बहुत महत्वपूर्ण परिवर्तन हैं, और वे अपने साथ नए संबंधित उपकरण लाते हैं: यदि आपके पास संचार की संस्कृति नहीं है, तो समान सीआई / सीडी प्रक्रियाओं को शुरू करने में बहुत अधिक बिंदु नहीं है।

---

अक्सर DevOps और SRE की अवधारणाओं के साथ भ्रम होता है। कुछ लोग सोचते हैं कि SRE DevOps के साथ प्रतिस्पर्धा करता है, अन्य उन्हें अवधारणाओं से पूरी तरह से अलग, अतिव्यापी मानते हैं। मेरी राय में, वे प्रतिस्पर्धी नहीं हैं, लेकिन करीबी दोस्त हैं। DevOps के तहत आने वाले दृष्टिकोणों के बारे में सोचें - संगठनात्मक लागतों को कम करना, विफलताओं को वर्कफ़्लो के एक सामान्य हिस्से के रूप में मानना, धीरे-धीरे परिवर्तन शुरू करना, इसके लिए आवश्यक उपकरणों को स्वचालित करना और लागू करना और प्रक्रियाओं का मूल्यांकन करने के लिए मैट्रिक्स का उपयोग करना। जैसा कि आप देख सकते हैं, यह सब बहुत सार है: DevOps हमें यह नहीं बताता है कि संगठनात्मक लागत को कैसे कम किया जाए या धीरे-धीरे बदलाव लाया जाए, यह सिर्फ आपको बताता है कि यदि वे लागू किए गए तो अच्छा होगा।

अब SRE को देखें। यद्यपि SRE दृष्टिकोण DevOps दृष्टिकोण से स्वतंत्र रूप से विकसित हुआ है, SRE है, कोई कह सकता है, DevOps सिद्धांतों का कार्यान्वयन: यदि आप DevOps को एक सार वर्ग या प्रोग्रामिंग में इंटरफ़ेस के रूप में कल्पना करते हैं, तो SRE एक ठोस वर्ग होगा जो इस इंटरफ़ेस को लागू करता है। एसआरई ने स्पष्ट रूप से चीजों और अवधारणाओं के एक मेजबान के लिए दृष्टिकोण को परिभाषित किया है: संयुक्त स्वामित्व, जोखिमों का साझाकरण, पोस्टमार्टम, मीट्रिक मूल्यों का संग्रह और संचय और बहुत कुछ। इसलिए, संगठनों के लिए यह बहुत सुविधाजनक है कि वे एसआरई के गोद लेने के बारे में बात कर सकें, जो कि बहुत ही समझने योग्य प्रक्रियाओं और संस्थाओं की उपस्थिति के कारण है।

---

क्या आपको लगता है कि "DevOps इंजीनियर" शब्द सही है? क्या इसे किसी तरह बदला जा सकता है?

---

मैं व्यक्तिगत रूप से यह नहीं मानता कि "DevOps इंजीनियर" की अवधारणा मौजूद है। आप मेरे लेख "DevOps के 10 मिथकों" में और अधिक विस्तार से पढ़ सकते हैं कि "DevOps" वास्तव में एक विचारधारा है: विभिन्न, लेकिन अनिवार्य रूप से जुड़े संगठनात्मक इकाइयों के बीच अधिक संचार और सहयोग। हालांकि आज यह काफी मजबूत और परिचित लग रहा है, पहले इस तरह के दृष्टिकोण ने प्रशंसा और कठोर आलोचना दोनों को जन्म दिया। तब से, Etsy, Facebook और Flick सहित कई संगठनों ने आश्चर्यजनक रूप से DevOps के सिद्धांतों को सफलतापूर्वक लागू किया है।

इसलिए, इन संगठनों में से एक ने "DevOps इंजीनियरों" को काम पर नहीं रखा। कार्यान्वयन की सफलता को टीमों के उभरते आंतरिक सहयोग और एक सामान्य लक्ष्य को प्राप्त करने के लिए अपनी मौजूदा प्रक्रियाओं और प्रक्रियाओं को बदलने की इच्छा के लिए जिम्मेदार ठहराया जा सकता है। तथाकथित "DevOps इंजीनियर" की भूमिका समूहों के बीच सहयोग को प्रोत्साहित करने और यह सुनिश्चित करने के लिए थी कि संगठनात्मक इकाइयाँ नियमित रूप से विचारों और लक्ष्यों का आदान-प्रदान करती हैं। दरअसल, आज हमारे पास ये लोग हैं, और हम उन्हें "प्रबंधक" कहते हैं।

---

मैं एक और पल जोड़ दूंगा। जब हम किसी को किसी विशिष्ट पद या भूमिका के लिए नियुक्त करते हैं, तो हम उससे विशिष्ट चीजों और कार्यों की अपेक्षा करने लगते हैं, इसलिए नौकरी का शीर्षक चुनना महत्वपूर्ण है। लेकिन पदों के सटीक नाम स्थानीय वास्तविकताओं और संगठन द्वारा अपनाई गई परंपराओं के कारण भिन्न हो सकते हैं, इसलिए यह महत्वपूर्ण है कि यह नाम ऐसा न हो, बल्कि कंपनी में काम करने वाले सभी लोगों के पदों के बीच संतुलन हो।

बहुत पहले नहीं, मैंने एक ऐसे व्यक्ति के साथ बात की, जो एक बड़े संगठन में काम करता था, और इसलिए उन्होंने कई कर्मचारियों की एक टीम बनाई और इसे कहा, कहते हैं, एक बुनियादी ढांचा टीम। फिर इस टीम का नाम बदलकर कुछ और कर दिया गया, और थोड़ी देर बाद एक और टीम बनाई गई, और अब इसे इंफ्रास्ट्रक्चर टीम कहा जाने लगा - नतीजतन, हर कोई केवल उलझन में था: "बुनियादी ढांचा विशेषज्ञ" कौन हैं और उनकी भूमिका क्या है।

मेरी राय में, सबसे महत्वपूर्ण बात एक विशिष्ट नाम के साथ एक टीम या स्थिति का अस्तित्व नहीं है, लेकिन यह स्पष्ट रूप से समझने के संगठन के भीतर मौजूद है कि कौन जिम्मेदार है। इससे कोई फर्क नहीं पड़ता कि वे उन्हें SRE या DevOps कहते हैं: मुख्य बात यह समझना है कि इस विशिष्ट संगठन के लिए एक विशिष्ट नाम का क्या अर्थ है।

---

लिज़, आप परामर्श कर रहे हैं, आप ग्राहक कंपनियों को DevOps सिद्धांतों की व्याख्या कैसे करते हैं? वे काफी सारगर्भित लगते हैं और कुछ हद तक समझाना मुश्किल है। या हो सकता है कि आपने किसी तरह का दृष्टिकोण विकसित किया हो जिससे आप इन विचारों को ग्राहकों तक पहुंचा सकें?

---

यह उद्देश्य पर निर्भर करता है। कई लोग और कंपनियां जिनके साथ मैं परामर्श के हिस्से के रूप में संवाद करता हूं, वे हमारे पास आते हैं और कहते हैं कि वे कुबेरनेट्स और कंटेनरों को तैनात करना चाहते हैं। लेकिन प्रौद्योगिकी के बारे में बात करने से पहले, आपको यह समझने की आवश्यकता है कि वे ऐसे कदम क्यों उठा रहे हैं। और यह पता चला है कि परिवर्तन के अपेक्षित लाभ अक्सर अधिक लचीले होने की इच्छा से आते हैं। इसलिए इस दिशा में आंदोलन कि तकनीकी टीमें अपने काम के परिणामों को तेजी से जारी कर सकती हैं, कुछ इस तरह, "उंगलियों पर" समझाया गया। इस बिंदु पर, इस बातचीत को उस पक्ष में स्थानांतरित करना उपयोगी है कि टीम के सदस्यों के बीच संचार की कमी (आदतें, अगर आपको पसंद हैं) नई प्रौद्योगिकियों के किसी भी "फेंकने" से मदद नहीं मिलेगी, यह संचार एक महत्वपूर्ण संसाधन है।

इसके अलावा, चूंकि मैं अक्सर समाधानों की सुरक्षा को बेहतर बनाने में खुद को शामिल पाता हूं, हमारी बातचीत "देव - ** सेक ** - ऑप्स" की ओर बढ़ती है, और यह पता चलता है कि सिस्टम का निर्माण इस तरह से किया जाना चाहिए कि सबसे प्रक्रियाओं के शुरुआती चरणों में, और न केवल पुराने ढंग से प्रश्न पर संपर्क किया: पहले हम आवेदन कोड लिखते हैं, फिर हम इसे तैनात करते हैं, फिर हम इसे रखरखाव सेवा में पास करते हैं, और केवल बहुत अंत में कोई व्यक्ति दौड़ने की सुरक्षा के बारे में सोचना शुरू कर देता है।

वास्तव में, कई सुरक्षा मुद्दे प्रक्रिया की शुरुआत में हल करने के लिए सस्ता और आसान है, लेकिन आपको शुरुआत से ही परियोजना में बहुत सारे बिंदुओं को रखना होगा। उदाहरण के लिए, यदि आप कंटेनरों के साथ काम करने का इरादा रखते हैं, तो आपको चिंता करने की ज़रूरत है कि चित्र काफी सुरक्षित तरीके से एकत्र किए गए हैं। कम से कम पहले से ज्ञात सुरक्षा समस्याओं वाले सॉफ़्टवेयर को लागू करने से बचने के लिए उन्हें कमजोरियों के लिए स्कैन करना उपयोगी हो सकता है। शायद आप कंटेनरों को कॉन्फ़िगर करने का प्रयास करेंगे ताकि उनमें सॉफ़्टवेयर डिफ़ॉल्ट रूप से रूट द्वारा शुरू न हो (जैसा कि अक्सर सादगी के लिए, विशेष आवश्यकता के बिना, कंटेनरों को इकट्ठा करते समय किया जाता है)। यदि आप ये कदम उठाते हैं, तो अंत में आपको अपने आवेदन की सुरक्षा में वृद्धि प्राप्त होगी, और आप इन सभी DevOps के संदर्भ में, SecOps संस्कृति के बारे में बात कर सकते हैं।

---

हालांकि, इसका मतलब है कि डेवलपर्स, वास्तव में एप्लिकेशन सुरक्षा विशेषज्ञ नहीं हैं, न केवल एप्लिकेशन कोड के बारे में सोचने के लिए मजबूर किया जाता है, बल्कि अपनी सुरक्षा प्रणाली भी बनाते हैं। फिर, आपकी राय में, आधुनिक सॉफ्टवेयर डेवलपर या ऑपरेटिंग इंजीनियर के लिए कौशल का न्यूनतम सेट होना चाहिए?

---

आप और मैं, चाहे हम इसे पसंद करें या न करें, लगातार नए नियमों और आवश्यकताओं के उद्भव को देखते हैं कि कुछ बिंदु पर यह पूरा करने और अनुपालन करने के लिए आवश्यक हो जाता है: उदाहरण के लिए उसी GDPR को लें। इन नियमों के उद्भव और अस्तित्व का मतलब है कि बढ़ती संख्या में लोगों में सुरक्षा की भावना होनी चाहिए। उदाहरण के लिए, आज आप डेटाबेस फ़ील्ड में उपयोगकर्ता के नाम और पासवर्ड को सादे रूप में स्टोर नहीं कर सकते हैं - यह अब कम से कम सहनीय नहीं माना जाता है। मैं कहूंगा कि उद्योग में "स्वच्छता" के लिए सभी आवश्यकताओं के लिए पहले से ही काफी स्पष्ट हैं।

टूल और इन्फ्रास्ट्रक्चर के निर्माता स्वयं इस प्रक्रिया पर एक महत्वपूर्ण प्रभाव डालते हैं, सिस्टम को डिजाइन और बदलने की कोशिश कर रहे हैं ताकि उपयोगकर्ता शुरू से ही अधिक सुरक्षित अनुप्रयोगों और प्रणालियों का निर्माण कर सकें। उदाहरण के लिए, पिछले एक साल में कुबेरनेट्स में, कई डिफ़ॉल्ट सेटिंग्स और पैरामीटर मान अधिक सुरक्षा की ओर बदल गए हैं, और यह वास्तव में बहुत अच्छा है। पहले, डिफ़ॉल्ट रूप से, एपीआई सर्वर अनाम पहुंच के लिए खुला था - यह काफी नहीं है जिसे आप "बॉक्स से बाहर" देखने की उम्मीद करते हैं। अब भूमिका-आधारित अभिगम नियंत्रण जैसी चीजें दिखाई देने लगी हैं, इसलिए अब हमारे पास अनुमतियाँ हैं (हाँ, "बॉक्स से बाहर"), और जब आप पहली बार कुबेरनेट शुरू करते हैं तो आप पूरी दुनिया के लिए खुले नहीं होते हैं, आप डिफ़ॉल्ट रूप से सुरक्षित रहते हैं। मुझे लगता है कि यह परिचित प्रक्रियाओं के दौरान सभी को सुरक्षा उपलब्ध कराने का एक अच्छा तरीका है, क्योंकि हमें लगातार डिफ़ॉल्ट मानों को सुरक्षित करने के लिए नहीं बदलना है (जो, इसके अलावा, ध्यान में रखा जाना चाहिए)।

---

व्यक्तिगत रूप से, मेरा मानना ​​है कि प्रत्येक सॉफ्टवेयर इंजीनियर को कम से कम सुरक्षा की बुनियादी समझ होनी चाहिए। ओडब्ल्यूएएसपी (ओपन वेब एप्लिकेशन सिक्योरिटी प्रोजेक्ट) जैसी चीजें बचाव के लिए आती हैं, लेकिन अंततः इंजीनियरों को स्वयं शिक्षित होने की आवश्यकता है। यह संभावना नहीं है कि हर इंजीनियर क्रिप्टोग्राफी में पीएचडी है, लेकिन अगर हम चाहते हैं कि हमारे सहकर्मी सुरक्षा को गंभीरता से लें, तो हमें उनके लिए सही निर्णय लेने में आसानी करनी चाहिए। यह वह जगह है जहां वॉल्ट जैसे उपकरण मदद कर सकते हैं - और सुरक्षा दल और पेशेवर निर्णय ले सकते हैं और "एपीआई के रूप में सुरक्षा" प्रदान कर सकते हैं।

---

अगर मैं सही तरीके से समझूं, तो हर चीज को कोड में बदलने की प्रवृत्ति है। कोड के रूप में सब कुछ। कोड के रूप में इन्फ्रास्ट्रक्चर, कोड के रूप में प्रक्रियाएं, कोड के रूप में कोड। निहितार्थ क्या हैं?

---

इससे पहले कि हम परिणामों के बारे में बात करें, हमें लाभों के बारे में बात करनी होगी। कोड बहुत लंबे समय से है। अनुप्रयोग हमेशा "कोड" होते हैं, और इस दौरान अनुप्रयोग विकास प्रक्रिया (CI / CD, linting, संयुक्त विकास के लिए उपकरण, आदि) का समर्थन और सुधार करने के लिए उपकरणों और प्रक्रियाओं का एक व्यापक पारिस्थितिकी तंत्र बनाया गया है। कोड के रूप में आधारभूत संरचना, कोड के रूप में प्रक्रियाओं, सुरक्षा को कोड के रूप में वर्णित करने के बाद, हम इसके लिए कुछ भी अतिरिक्त भुगतान किए बिना, समान पारिस्थितिकी तंत्र का उपयोग कर सकते हैं। आप संयुक्त रूप से बुनियादी ढांचे में बदलाव कर सकते हैं, नीति समीक्षा कर सकते हैं, आदि। आप उन्हें लागू करने से पहले बुनियादी ढांचे में बदलाव का परीक्षण कर सकते हैं। ये कुछ लाभ हैं जो कोड में कुछ का अनुवाद करने के साथ आते हैं।

मुझे लगता है कि सबसे बड़ा परिणाम समय और जटिलता है। जब आप कुछ "जैसे कोड के साथ" (उदाहरण के लिए, टेराफॉर्म, वॉल्ट, क्लाउडफ़ॉर्मेशन, परिनियोजन प्रबंधक, आदि) के साथ काम करते हैं, तो कभी-कभी आपको कोड में लिखे गए और वास्तव में क्या होता है, के बीच विसंगतियों के बारे में आना होगा। बादल में। जटिल संबंधों को बनाना कभी-कभी नेत्रहीन बनाना मुश्किल होता है, खासकर स्केलिंग को देखते हुए। इसके अलावा, हम अमूर्तताओं की अशुद्धि का सामना कर सकते हैं - उदाहरण के लिए, एपीआई के माध्यम से काम करने वाली एक स्क्रिप्ट वर्तमान मामलों की स्थिति को नहीं देख सकती है क्योंकि यह वेब इंटरफ़ेस के माध्यम से उपयोगकर्ताओं को प्रदर्शित किया जाता है। हालांकि, समय के साथ, जटिलता कम हो जाती है और लचीलापन लौट आता है।

---

कोड और अन्य औपचारिक मॉडल मशीन विश्लेषण और मशीन सीखने के लिए उपयुक्त क्षेत्र हैं। जब वास्तव में रोबोट हमारी जगह लेंगे? हमें कैसे जवाब देना चाहिए?
क्या रोबोट मनुष्यों के बिना कुबेरनेट्स को कॉन्फ़िगर कर सकते हैं? विशेष रूप से, ऐसा हो सकता है कि कुछ पेशे (जैसे सिस्टम एडमिनिस्ट्रेटर या सॉफ्टवेयर टेस्टर के साथ उच्च स्तर की अन्तरक्रियाशीलता - एक "मैनुअल परीक्षक" के लिए एक सामाजिक रूप से स्वीकार्य शब्द) बस गायब हो जाए?

---

मुझे नहीं लगता कि लोग गायब हो जाएंगे, लेकिन मुझे संदेह है कि हमारे पास आज जो कुछ नौकरियां हैं, वे भविष्य में नहीं बचेंगे। मैं स्वायत्त कार नियंत्रण प्रणालियों की दुनिया की राजधानी पिट्सबर्ग में रहता हूं, और मैं हर दिन स्व-ड्राइविंग कार देखता हूं। भविष्य में, निश्चित रूप से, टैक्सी ड्राइवरों को रोबोट ड्राइविंग प्रौद्योगिकियों द्वारा प्रतिस्थापित किया जाएगा। शायद तुरंत नहीं, लेकिन 10 या अधिक वर्षों के बाद, लेकिन यह भविष्य अनिवार्य रूप से आएगा। हालांकि, मुझे लगता है कि टैक्सी ड्राइवर गायब नहीं होंगे। मानवता लगातार खुद को मजबूत कर रही है।

मेरा मानना ​​है कि प्रबंधन के क्षेत्र में मशीन सीखने के बारे में भी यही कहा जा सकता है। मैं अपने सिस्टम को अधिक स्थिर और लचीला बनाने के लिए अधिक AI की प्रतीक्षा कर रहा हूं, और मुझे लगता है कि हम इस दृष्टिकोण से लड़ने का निर्णय ले सकते हैं - या इसे स्वीकार कर सकते हैं। पारंपरिक प्रणाली प्रशासकों की भूमिका को एआई प्रणाली को नियंत्रित करने वाले किसी व्यक्ति द्वारा प्रतिस्थापित किया जा सकता है, लेकिन इसका मतलब यह नहीं है कि लोग खुद ही गायब हो जाएंगे। हमने कई उद्योगों में समान बदलाव का अनुभव किया जहां प्रौद्योगिकी और नवाचार लोगों की तुलना में उच्च गति और सटीकता प्रदान करते हैं, लेकिन अंत में, किसी को रोबोट का पालन करने की आवश्यकता है :)।

---

कल्पना करें कि एक नियमित विकास टीम एक वेब एप्लिकेशन बनाती है, इसे कुबेरनेट क्लस्टर में रखती है। हम कैसे सुनिश्चित कर सकते हैं कि आवेदन सुरक्षित है? एक ब्लैकहैट हैकर या विशेषज्ञ को किराए पर लें जो सुरक्षा कमजोरियों को खोजने की कोशिश कर रहा है, या क्या कोई कम जटिल तरीके हैं?

---

हमने एक्वा सिक्योरिटी में हाल ही में एक ओपन सोर्स टूल जारी किया है जिसे क्यूब-हंटर कहा जाता है। यह हैकिंग या पैठ के लिए कुबेरनेट्स का परीक्षण करने में सक्षम है - यह एक काफी सरल परीक्षण है। आप इस टूल को ले सकते हैं और अपने स्वयं के क्लस्टर का परीक्षण कर सकते हैं, और आप लगभग निश्चित रूप से अपने लिए कुछ दिलचस्प पाएंगे, खासकर यदि आपकी स्थापना कुबेरनेट्स के पुराने संस्करण पर आधारित थी, जहां डिफ़ॉल्ट सेटिंग्स कम सुरक्षित थीं - आपके पास अच्छी तरह से हो सकता है, उदाहरण के लिए खुले बंदरगाह।

हम सभी लोगों ने उन कहानियों के बारे में सुना, जो अपने क्लस्टर कंट्रोल पैनल को पूरे इंटरनेट तक मुफ्त पहुंच से बंद करने के लिए "भूल गए", इसलिए क्यूब-हंटर बनाने का लक्ष्य हमारी खुद की प्रणाली की जांच करना और यह सुनिश्चित करना था कि यह संरक्षित है। हमारी राय में, हैकर्स लंबे समय से खुले, प्रसिद्ध संसाधनों और बंदरगाहों के लिए इंटरनेट पर मेजबानों को स्कैन कर रहे हैं, इसलिए आपके कुबेरनेट्स नियंत्रण कक्ष, जो संयोग से संरक्षित नहीं है (और इसलिए सभी के लिए खुला है), विशेष रूप से टूल के साथ, खोजने में इतना मुश्किल नहीं हो सकता है वे उपयोग करने के लिए उपयोग किया जाता है।

हम चाहते हैं कि साधारण कुबेरनेट्स प्रशासकों को बेहतर तरीके से समझने में मदद करें कि क्या उनकी तैनाती में कॉन्फ़िगरेशन समस्याएं हैं, इसलिए यह विशेष रूप से कुबेरनेट्स और रिपोर्ट के लिए डिज़ाइन किया गया है जो कि कुबरनेट्स उपयोगकर्ताओं को समझने वाली भाषा में पाया गया था। इसलिए हम आपको सूचित करेंगे कि आपने कोई पोर्ट 6443 नहीं खोला है, लेकिन कहते हैं, कुबेरनेट्स के इस विशेष घटक तक पहुंच है। इस तरह, लोगों के लिए यह निर्धारित करना आसान है कि जो उन्होंने पाया है वह एक सुरक्षा-कमजोर कॉन्फ़िगरेशन के साथ एक समस्या है और क्या यह इसे तुरंत ठीक करने के लिए लायक है - कुबेरनेट्स सुरक्षा विशेषज्ञ होने के बिना। हम बाहरी विशेषज्ञों की आवश्यकता के बिना, इन चेक को किसी भी समय उपलब्ध कराने का प्रयास करना चाहते हैं।

---

एक अवलोकन है: बहुत से लोग अब उन कंटेनरों में दिलचस्पी नहीं रखते हैं जो उनके द्वारा लॉन्च किए गए कंटेनरों के अंदर हैं।

---

हां, और उन्हें इस बात का कोई अंदाजा नहीं है कि इन कंटेनरों में क्या निर्भरताएं बनी थीं। यद्यपि, यदि आप सेवा को लागू करने के लिए कंटेनर दृष्टिकोण का उपयोग करने की योजना बनाते हैं, तो यह पता लगाना उचित है कि इस या उस छवि के अंदर किस तरह का सॉफ्टवेयर है। लेकिन यह कंटेनर के दृष्टिकोण की समस्या नहीं है, यह केवल दृष्टिकोण का उपयोग करने वालों की सुरक्षा के लिए एक दृष्टिकोण है।

सब कुछ सही और मज़बूती से करना इतना मुश्किल नहीं है। कहते हैं, जैसे ही आप क्लाउड की दुनिया में जाते हैं, आपको अतिरिक्त उपकरणों का उपयोग शुरू करने की आवश्यकता होती है - जो निश्चित रूप से सुरक्षा के अतिरिक्त स्तरों को जोड़ देगा।

बादलों की अपनी विशिष्टता होती है। उदाहरण के लिए, मैं अक्सर गलतफहमी को पूरा करता हूं कि क्लाउड की दुनिया में, एक उपकरण जो पुराने समय में लोगों द्वारा उपयोग किया जाता है वह स्वचालित रूप से वह सब कुछ करेगा जिसकी उन्हें आवश्यकता है। कुछ मायनों में, वे सही हैं: मान लें कि आप फ़ायरवॉल सेटिंग्स की सामान्य (और हमेशा काम की गई) सूची का उपयोग कर सकते हैं, और यह सुरक्षा को बढ़ाएगा, लेकिन कुछ पुराने उपकरण आज उपयुक्त नहीं हैं। उदाहरण के लिए, यदि आप एक कंटेनर छवि को तैनात करते हैं और कमजोरियों के लिए स्कैनिंग के लिए पुराने परिचित उपकरण का उपयोग करते हैं, तो अगर स्कैनर को छवि के अंदर देखने का तरीका नहीं पता है, यह बस कुछ भी नहीं मिलेगा, और आपको (संभवतः गलत) विश्वास मिलेगा कि सब कुछ क्रम में है।

मुझे वास्तव में यह पसंद है कि जब आप माइक्रोसर्विसेस की वास्तुकला की ओर बढ़ते हैं, तो आपको कंटेनरों में रखे गए कार्यों के छोटे टुकड़े मिलते हैं (जिनमें से सामग्री आपके हाथ की हथेली में होती है) और आप उनके बीच यातायात देख सकते हैं। प्रत्येक कंटेनर को एक प्रकार का ब्लैक बॉक्स माना जा सकता है, जिसमें से कड़ाई से परिभाषित क्रियाएं अपेक्षित हैं। और जैसे ही यह या वह कंटेनर अप्रत्याशित तरीके से व्यवहार करना शुरू कर देता है या अजीब परिणाम उत्पन्न करता है, इस पर प्रतिक्रिया करना संभव हो जाता है। कंटेनरों की विशिष्ट छवियों को बेहतर तरीके से इकट्ठा और कॉन्फ़िगर किया गया है, जितना अधिक समझ में आता है कि क्या वे ठीक से काम करेंगे।

---

और विसंगतियों को कैसे पकड़ें? एंटीवायरस ह्यूरिस्टिक्स, न्यूरल नेटवर्क जैसी किसी चीज़ का उपयोग करें?

---

सॉफ्टवेयर जीवन चक्र के दौरान, हम विभिन्न सुरक्षा उपकरणों का उपयोग करते हैं। 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. , , , «».

, - , .

---

, ?

---

C . , , , , !

---

! , : — .

---

DevOops 2018 «Modern security with microservices and the cloud» , «Practical steps for securing your container deployment» . .