पतवार सुरक्षा

कुबेरनेट्स के लिए सबसे लोकप्रिय पैकेज मैनेजर के बारे में कहानी का सार एक इमोजी का उपयोग करके दर्शाया जा सकता है:

• बॉक्स हेल्म है (जो नवीनतम इमोजी रिलीज़ के सबसे करीब है);
• ताला - सुरक्षा;
• छोटा आदमी समस्या का समाधान है.

वास्तव में, सब कुछ थोड़ा अधिक जटिल होगा, और कहानी तकनीकी विवरणों से भरी है हेल्म को सुरक्षित कैसे बनाएं.

• यदि आप नहीं जानते या भूल गए हैं तो संक्षेप में हेल्म क्या है। यह किन समस्याओं का समाधान करता है और यह पारिस्थितिकी तंत्र में कहाँ स्थित है।
• आइए हेल्म वास्तुकला को देखें। सुरक्षा और किसी उपकरण या समाधान को अधिक सुरक्षित बनाने के बारे में कोई भी बातचीत घटक की वास्तुकला को समझे बिना पूरी नहीं होती है।
• आइए हेल्म घटकों पर चर्चा करें।
• सबसे ज्वलंत प्रश्न भविष्य है - हेल्म 3 का नया संस्करण। 

इस लेख में दी गई सभी बातें हेल्म 2 पर लागू होती हैं। यह संस्करण वर्तमान में उत्पादन में है और सबसे अधिक संभावना है कि आप वर्तमान में इसका उपयोग कर रहे हैं, और यह वह संस्करण है जिसमें सुरक्षा जोखिम शामिल हैं।

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

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

पतवार

यह कुबेरनेट्स के लिए एक पैकेज (चार्ट) प्रबंधक है। कुबेरनेट्स क्लस्टर में एप्लिकेशन लाने का सबसे सहज और सार्वभौमिक तरीका।

निस्संदेह, हम आपके स्वयं के YAML मैनिफ़ेस्ट बनाने और छोटी उपयोगिताएँ लिखने की तुलना में अधिक संरचनात्मक और औद्योगिक दृष्टिकोण के बारे में बात कर रहे हैं।

हेल्म सर्वोत्तम है जो वर्तमान में उपलब्ध और लोकप्रिय है।

हेल्म क्यों? मुख्यतः क्योंकि यह सीएनसीएफ द्वारा समर्थित है। क्लाउड नेटिव एक बड़ा संगठन है और कुबेरनेट्स, आदि, फ़्लुएंट और अन्य परियोजनाओं की मूल कंपनी है।

एक और महत्वपूर्ण तथ्य यह है कि हेल्म एक बहुत लोकप्रिय परियोजना है। जब मैंने जनवरी 2019 में हेल्म को सुरक्षित बनाने के बारे में बात करना शुरू किया, तो इस प्रोजेक्ट में GitHub पर एक हजार स्टार थे। मई तक इनकी संख्या 12 हजार थी.

बहुत से लोग हेल्म में रुचि रखते हैं, इसलिए यदि आप अभी तक इसका उपयोग नहीं करते हैं, तो भी आपको इसकी सुरक्षा के बारे में जानने से लाभ होगा। सुरक्षा महत्वपूर्ण है.

कोर हेल्म टीम Microsoft Azure द्वारा समर्थित है और इसलिए कई अन्य के विपरीत, यह काफी स्थिर परियोजना है। जुलाई के मध्य में हेल्म 3 अल्फ़ा 2 की रिलीज़ से संकेत मिलता है कि इस परियोजना पर बहुत सारे लोग काम कर रहे हैं, और उनमें हेल्म को विकसित करने और सुधारने की इच्छा और ऊर्जा है।

हेल्म कुबेरनेट्स में एप्लिकेशन प्रबंधन की कई मूल समस्याओं का समाधान करता है।

• अनुप्रयोग पैकेजिंग. यहां तक ​​कि वर्डप्रेस पर "हैलो, वर्ल्ड" जैसे एप्लिकेशन में पहले से ही कई सेवाएं शामिल हैं, और आप उन्हें एक साथ पैकेज करना चाहते हैं।
• इन अनुप्रयोगों को प्रबंधित करने में आने वाली जटिलता को प्रबंधित करना।
• एक जीवन चक्र जो एप्लिकेशन इंस्टॉल या तैनात होने के बाद समाप्त नहीं होता है। यह जीवित रहता है, इसे अद्यतन करने की आवश्यकता है और हेल्म इसमें मदद करता है और इसके लिए सही उपाय और नीतियां लाने का प्रयास करता है।

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

जटिलता प्रबंधन. यदि आपके पास एक ही प्रकार के कई एप्लिकेशन हैं, तो पैरामीटराइजेशन की आवश्यकता है। टेम्प्लेट इससे आते हैं, लेकिन टेम्प्लेट बनाने का अपना तरीका अपनाने से बचने के लिए, आप हेल्म द्वारा प्रदान की जाने वाली चीज़ों का उपयोग कर सकते हैं।

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

हेल्म आपको इसकी अनुमति देता है:

• परिनियोजन प्रबंधित करें, कॉन्फ़िगरेशन और संशोधन की अवधारणा का परिचय दें;
• सफलतापूर्वक रोलबैक करें;
• विभिन्न आयोजनों के लिए हुक का उपयोग करें;
• अतिरिक्त एप्लिकेशन जांच जोड़ें और उनके परिणामों पर प्रतिक्रिया दें।

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

हेल्म तीन मुख्य अवधारणाओं पर आधारित है:

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

हेल्म वास्तुकला

यह आरेख संकल्पनात्मक रूप से हेल्म की उच्च-स्तरीय वास्तुकला को दर्शाता है।

मैं आपको याद दिला दूं कि हेल्म कुबेरनेट्स से संबंधित कुछ है। इसलिए, हम कुबेरनेट्स क्लस्टर (आयत) के बिना नहीं कर सकते। क्यूब-एपिसर्वर घटक मास्टर पर रहता है। हेल्म के बिना हमारे पास Kubeconfig है। हेल्म एक छोटी बाइनरी लाता है, यदि आप इसे हेल्म सीएलआई उपयोगिता कह सकते हैं, जो कंप्यूटर, लैपटॉप, मेनफ्रेम - किसी भी चीज़ पर स्थापित होती है।

लेकिन इतना पर्याप्त नहीं है। हेल्म में टिलर नामक एक सर्वर घटक है। यह क्लस्टर के भीतर हेल्म के हितों का प्रतिनिधित्व करता है; यह किसी भी अन्य की तरह, कुबेरनेट्स क्लस्टर के भीतर एक एप्लिकेशन है।

चार्ट रेपो का अगला घटक चार्ट वाला एक भंडार है। एक आधिकारिक भंडार है, और किसी कंपनी या परियोजना का एक निजी भंडार भी हो सकता है।

इंटरेक्शन

आइए देखें कि जब हम हेल्म का उपयोग करके कोई एप्लिकेशन इंस्टॉल करना चाहते हैं तो आर्किटेक्चर घटक कैसे इंटरैक्ट करते हैं।

• हम बोल रहे है Helm install, रिपॉजिटरी (चार्ट रेपो) तक पहुंचें और हेल्म चार्ट प्राप्त करें।

• हेल्म यूटिलिटी (हेल्म सीएलआई) यह पता लगाने के लिए कि किस क्लस्टर से संपर्क करना है, क्यूबकॉन्फिग के साथ इंटरैक्ट करती है। 
• यह जानकारी प्राप्त करने के बाद, उपयोगिता टिलर को संदर्भित करती है, जो एक एप्लिकेशन के रूप में हमारे क्लस्टर में स्थित है। 
• टिलर कुबेरनेट्स में क्रियाएं करने, कुछ ऑब्जेक्ट (सेवाएं, पॉड्स, प्रतिकृतियां, रहस्य इत्यादि) बनाने के लिए क्यूब-एपिसर्वर को कॉल करता है।

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

आक्रमण सदिश

पहला संभावित कमजोर बिंदु है विशेषाधिकार प्राप्त एपीआई-उपयोगकर्ता. योजना के हिस्से के रूप में, यह एक हैकर है जिसने हेल्म सीएलआई तक व्यवस्थापक पहुंच प्राप्त कर ली है।

अप्राप्त एपीआई उपयोगकर्ता अगर यह कहीं आस-पास हो तो भी खतरा पैदा हो सकता है। ऐसे उपयोगकर्ता के पास एक अलग संदर्भ होगा, उदाहरण के लिए, उसे Kubeconfig सेटिंग्स में एक क्लस्टर नेमस्पेस में तय किया जा सकता है।

सबसे दिलचस्प हमला वेक्टर एक ऐसी प्रक्रिया हो सकती है जो टिलर के पास कहीं क्लस्टर के भीतर रहती है और उस तक पहुंच सकती है। यह एक वेब सर्वर या माइक्रोसर्विस हो सकता है जो क्लस्टर के नेटवर्क वातावरण को देखता है।

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

आइए इन चारों तरफ से हमलों को रोकने की कोशिश करें और पता लगाएं कि हेल्म वास्तुकला में कहां समस्याएं हैं, और कहां, शायद, कोई नहीं है।

आइए आरेख को बड़ा करें, अधिक तत्व जोड़ें, लेकिन सभी बुनियादी घटकों को रखें।

हेल्म सीएलआई चार्ट रेपो के साथ संचार करता है, क्यूबकॉन्फिग के साथ इंटरैक्ट करता है, और कार्य को क्लस्टर में टिलर घटक में स्थानांतरित किया जाता है।

टिलर को दो वस्तुओं द्वारा दर्शाया गया है:

• टिलर-तैनाती एसवीसी, जो एक निश्चित सेवा को उजागर करता है;
• टिलर-डिप्लॉय पॉड (आरेख में एक प्रतिलिपि में एक प्रतिकृति में), जिस पर पूरा लोड चलता है, जो क्लस्टर तक पहुंचता है।

बातचीत के लिए विभिन्न प्रोटोकॉल और योजनाओं का उपयोग किया जाता है। सुरक्षा की दृष्टि से, हमारी सबसे अधिक रुचि इसमें है:

• वह तंत्र जिसके द्वारा हेल्म सीएलआई चार्ट रेपो तक पहुंचता है: कौन सा प्रोटोकॉल है, क्या प्रमाणीकरण है और इसके साथ क्या किया जा सकता है।
• वह प्रोटोकॉल जिसके द्वारा हेल्म सीएलआई, कुबेक्टल का उपयोग करके, टिलर के साथ संचार करता है। यह क्लस्टर के अंदर स्थापित एक RPC सर्वर है।
• टिलर स्वयं उन माइक्रोसर्विसेज के लिए पहुंच योग्य है जो क्लस्टर में रहते हैं और क्यूब-एपिसर्वर के साथ इंटरैक्ट करते हैं।

आइए इन सभी क्षेत्रों पर क्रम से चर्चा करें।

RBAC

जब तक आरबीएसी सक्षम नहीं है तब तक हेल्म या क्लस्टर के भीतर किसी अन्य सेवा के लिए किसी भी सुरक्षा के बारे में बात करने का कोई मतलब नहीं है।

ऐसा लगता है कि यह नवीनतम अनुशंसा नहीं है, लेकिन मुझे यकीन है कि कई लोगों ने अभी भी उत्पादन में भी आरबीएसी को सक्षम नहीं किया है, क्योंकि यह बहुत उपद्रव है और बहुत सी चीजों को कॉन्फ़िगर करने की आवश्यकता है। हालाँकि, मैं आपको ऐसा करने के लिए प्रोत्साहित करता हूँ।

https://rbac.dev/ - आरबीएसी के लिए वेबसाइट वकील। इसमें बड़ी मात्रा में दिलचस्प सामग्रियां शामिल हैं जो आपको आरबीएसी स्थापित करने में मदद करेंगी, बताएंगी कि यह क्यों अच्छा है और मूल रूप से उत्पादन में इसके साथ कैसे रहना है।

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

जब आप हेल्म को इनिशियलाइज़ करते हैं और इसे पहली बार सर्वर पर इंस्टॉल करते हैं, तो आप सर्विस अकाउंट का उपयोग करके सेट कर सकते हैं --service-account. यह आपको न्यूनतम आवश्यक अधिकारों वाले उपयोगकर्ता का उपयोग करने की अनुमति देगा। सच है, आपको ऐसी "माला" बनानी होगी: भूमिका और भूमिका बंधन।

दुर्भाग्य से, हेल्म आपके लिए ऐसा नहीं करेगा। हेल्म पास करने के लिए आपको या आपके कुबेरनेट्स क्लस्टर व्यवस्थापक को सेवा-खाते के लिए भूमिकाओं और रोलबाइंडिंग का एक सेट पहले से तैयार करना होगा।

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

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

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

यह इस तरह दिखेगा.

उदाहरण के लिए, विभिन्न टीमों (दो नामस्थान) के लिए संदर्भ के साथ दो Kubeconfigs हैं: विकास टीम के लिए X टीम और व्यवस्थापक क्लस्टर। एडमिन क्लस्टर का अपना विस्तृत टिलर है, जो क्यूब-सिस्टम नेमस्पेस में स्थित है, जो एक समान रूप से उन्नत सेवा-खाता है। और विकास टीम के लिए एक अलग नामस्थान, वे अपनी सेवाओं को एक विशेष नामस्थान पर तैनात करने में सक्षम होंगे।

यह एक व्यावहारिक दृष्टिकोण है, टिलर इतना बिजली का भूखा नहीं है कि यह आपके बजट को बहुत प्रभावित करेगा। यह त्वरित समाधानों में से एक है.

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

अपनी कहानी को जारी रखते हुए, आइए आरबीएसी से आगे बढ़ें और कॉन्फिगमैप्स के बारे में बात करें।

कॉन्फ़िगमैप्स

हेल्म अपने डेटा स्टोर के रूप में कॉन्फिगमैप्स का उपयोग करता है। जब हमने आर्किटेक्चर के बारे में बात की, तो कहीं भी कोई डेटाबेस नहीं था जो रिलीज़, कॉन्फ़िगरेशन, रोलबैक आदि के बारे में जानकारी संग्रहीत करता। इसके लिए कॉन्फ़िगमैप्स का उपयोग किया जाता है।

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

यह बहुत सरलता से किया जाता है. टिलर सेटिंग को ओवरराइड करें और निर्दिष्ट करें कि भंडारण रहस्य होगा। फिर प्रत्येक परिनियोजन के लिए आपको कॉन्फ़िगमैप नहीं, बल्कि एक रहस्य प्राप्त होगा।

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

स्टोरेज हेल्म को रहस्यों में स्थानांतरित करना बेहतर है, और वे, बदले में, केंद्रीय रूप से सुरक्षित होते हैं।

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

चार्ट रिपोज

चार्ट सामाजिक रूप से सबसे कमजोर हैं और "बीच में आदमी" का स्रोत बन सकते हैं, खासकर यदि आप स्टॉक समाधान का उपयोग करते हैं। सबसे पहले, हम उन रिपॉजिटरी के बारे में बात कर रहे हैं जो HTTP के माध्यम से उजागर होती हैं।

आपको निश्चित रूप से HTTPS पर हेल्म रेपो को उजागर करने की आवश्यकता है - यह सबसे अच्छा विकल्प है और सस्ता है।

पर ध्यान दें चार्ट हस्ताक्षर तंत्र. प्रौद्योगिकी अत्यंत सरल है। यह वही चीज़ है जिसका उपयोग आप GitHub पर करते हैं, जो सार्वजनिक और निजी कुंजियों वाली एक नियमित PGP मशीन है। सेट अप करें और सुनिश्चित करें, आवश्यक कुंजियाँ रखते हुए और हर चीज़ पर हस्ताक्षर करते हुए, कि यह वास्तव में आपका चार्ट है।

इसके अलावा, हेल्म क्लाइंट टीएलएस का समर्थन करता है (सर्वर-साइड HTTP अर्थ में नहीं, बल्कि पारस्परिक TLS)। संचार करने के लिए आप सर्वर और क्लाइंट कुंजियों का उपयोग कर सकते हैं। ईमानदारी से कहूँ तो, मैं ऐसे तंत्र का उपयोग नहीं करता क्योंकि मुझे पारस्परिक प्रमाणपत्र पसंद नहीं हैं। मूल रूप से, चार्टम्यूजियम - हेल्म 2 के लिए हेल्म रेपो स्थापित करने का मुख्य उपकरण - बुनियादी प्रमाणीकरण का भी समर्थन करता है। यदि यह अधिक सुविधाजनक और शांत है तो आप बेसिक ऑथ का उपयोग कर सकते हैं।

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

यदि आप HTTPS या TLS सक्षम करते हैं, mTLS का उपयोग करते हैं, और जोखिमों को और कम करने के लिए बुनियादी प्रमाणीकरण सक्षम करते हैं, तो आपको हेल्म सीएलआई और चार्ट रेपो के साथ एक सुरक्षित संचार चैनल मिलेगा।

जीआरपीसी एपीआई

अगला कदम बहुत महत्वपूर्ण है - टिलर को सुरक्षित करना, जो क्लस्टर में स्थित है और एक ओर, एक सर्वर है, दूसरी ओर, यह स्वयं अन्य घटकों तक पहुंचता है और किसी के होने का दिखावा करने की कोशिश करता है।

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

उत्पादन और यहां तक ​​कि स्टेजिंग के लिए, मैं जीआरपीसी पर टीएलएस को सक्षम करने की सलाह देता हूं।

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

इस तरह आप क्लस्टर के बाहर से टिलर के सभी अनुरोधों से अपनी रक्षा करेंगे।

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

संरक्षित पतवार

आइए अंतिम आरेख देखें। यह समान तीरों के साथ समान वास्तुकला है।

सभी कनेक्शन अब सुरक्षित रूप से हरे रंग में खींचे जा सकते हैं:

• चार्ट रेपो के लिए हम टीएलएस या एमटीएलएस और बेसिक ऑथ का उपयोग करते हैं;
• टिलर के लिए एमटीएलएस, और इसे टीएलएस के साथ जीआरपीसी सेवा के रूप में उजागर किया गया है, हम प्रमाणपत्रों का उपयोग करते हैं;
• क्लस्टर रोल और रोलबाइंडिंग के साथ एक विशेष सेवा खाते का उपयोग करता है। 

हमने क्लस्टर को महत्वपूर्ण रूप से सुरक्षित कर लिया है, लेकिन किसी चतुर व्यक्ति ने कहा:

"केवल एक ही बिल्कुल सुरक्षित समाधान हो सकता है - एक बंद कंप्यूटर, जो एक कंक्रीट बॉक्स में स्थित है और सैनिकों द्वारा संरक्षित है।"

डेटा में हेरफेर करने और नए आक्रमण वैक्टर खोजने के विभिन्न तरीके हैं। हालाँकि, मुझे विश्वास है कि ये सिफारिशें सुरक्षा के लिए एक बुनियादी उद्योग मानक हासिल करेंगी।

बोनस

यह हिस्सा सीधे तौर पर सुरक्षा से जुड़ा नहीं है, लेकिन उपयोगी भी होगा. मैं आपको कुछ दिलचस्प चीजें दिखाऊंगा जिनके बारे में बहुत कम लोग जानते हैं। उदाहरण के लिए, चार्ट कैसे खोजें - आधिकारिक और अनौपचारिक।

भण्डार में github.com/hem/charts अब लगभग 300 चार्ट और दो धाराएँ हैं: स्थिर और इनक्यूबेटर। जो कोई भी योगदान देता है वह अच्छी तरह से जानता है कि इनक्यूबेटर से स्टेबल तक जाना कितना मुश्किल है, और स्टेबल से बाहर उड़ना कितना आसान है। हालाँकि, प्रोमेथियस और जो कुछ भी आपको पसंद हो, उसके लिए चार्ट खोजने के लिए यह सबसे अच्छा उपकरण नहीं है, एक साधारण कारण से - यह एक पोर्टल नहीं है जहाँ आप आसानी से पैकेज खोज सकते हैं।

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

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

मैं आपका ध्यान इस ओर भी आकर्षित करना चाहूंगा सर्विस ब्रोकर एपीआई एकीकरण खोलें. यह बोझिल और अस्पष्ट लगता है, लेकिन यह उन समस्याओं का समाधान करता है जिनका सामना हर कोई करता है। मैं एक सरल उदाहरण से समझाता हूँ।

एक कुबेरनेट्स क्लस्टर है जिसमें हम एक क्लासिक एप्लिकेशन - वर्डप्रेस चलाना चाहते हैं। आम तौर पर, पूर्ण कार्यक्षमता के लिए एक डेटाबेस की आवश्यकता होती है। कई अलग-अलग समाधान हैं, उदाहरण के लिए, आप अपनी स्वयं की स्टेटफुल सेवा लॉन्च कर सकते हैं। यह बहुत सुविधाजनक नहीं है, लेकिन बहुत से लोग ऐसा करते हैं।

चेनस्टैक में हमारे जैसे अन्य लोग अपने सर्वर के लिए MySQL या PostgreSQL जैसे प्रबंधित डेटाबेस का उपयोग करते हैं। इसीलिए हमारे डेटाबेस क्लाउड में कहीं स्थित हैं।

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

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

हम कह सकते हैं कि हेल्म एक गोंद के रूप में कार्य करता है, जो एक ओर, आपको सेवाओं को तैनात करने की अनुमति देता है, और दूसरी ओर, क्लाउड प्रदाताओं के संसाधनों का उपभोग करता है।

आप अपना खुद का प्लगइन लिख सकते हैं और इस पूरी कहानी का ऑन-प्रिमाइसेस उपयोग कर सकते हैं। तब आपके पास कॉर्पोरेट क्लाउड प्रदाता के लिए बस अपना स्वयं का प्लगइन होगा। मैं इस दृष्टिकोण को आज़माने की सलाह देता हूं, खासकर यदि आपके पास बड़े पैमाने पर है और आप किसी सुविधा के लिए डेव, स्टेजिंग या संपूर्ण बुनियादी ढांचे को जल्दी से तैनात करना चाहते हैं। इससे आपके संचालन या DevOps का जीवन आसान हो जाएगा।

एक और खोज जिसका मैंने पहले ही उल्लेख किया है हेल्म-जीसीएस प्लगइन, जो आपको हेल्म चार्ट को संग्रहीत करने के लिए Google-बकेट (ऑब्जेक्ट स्टोरेज) का उपयोग करने की अनुमति देता है।

इसका उपयोग शुरू करने के लिए आपको केवल चार कमांड की आवश्यकता है:

1. प्लगइन स्थापित करें;
2. इसे आरंभ करें;
3. बाल्टी के लिए पथ निर्धारित करें, जो जीसीपी में स्थित है;
4. मानक तरीके से चार्ट प्रकाशित करें.

ख़ूबसूरती यह है कि प्राधिकरण के लिए मूल gcp पद्धति का उपयोग किया जाएगा। आप एक सेवा खाता, एक डेवलपर खाता, जो भी आप चाहें, उपयोग कर सकते हैं। यह बहुत सुविधाजनक है और इसे चलाने में कोई लागत नहीं आती। यदि आप, मेरी तरह, ऑप्सलेस दर्शन को बढ़ावा देते हैं, तो यह बहुत सुविधाजनक होगा, खासकर छोटी टीमों के लिए।

विकल्प

हेल्म एकमात्र सेवा प्रबंधन समाधान नहीं है। इसके बारे में बहुत सारे सवाल हैं, शायद यही वजह है कि तीसरा संस्करण इतनी जल्दी सामने आ गया। निःसंदेह विकल्प मौजूद हैं।

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

आख़िरकार एक समाधान है ऑपरेटर ढाँचाजिनकी लोकप्रियता बढ़ती जा रही है.

ऑपरेटर फ्रेमवर्क विचार करने के लिए शीर्ष हेल्म विकल्प है।

यह सीएनसीएफ और कुबेरनेट्स का अधिक मूल निवासी है, लेकिन प्रवेश की बाधा बहुत अधिक है, आपको अधिक प्रोग्राम करने और मैनिफ़ेस्ट का कम वर्णन करने की आवश्यकता है।

ड्राफ्ट, स्कैफोल्ड जैसे विभिन्न ऐडऑन हैं। वे जीवन को बहुत आसान बनाते हैं, उदाहरण के लिए, वे डेवलपर्स के लिए परीक्षण वातावरण तैनात करने के लिए हेल्म भेजने और लॉन्च करने के चक्र को सरल बनाते हैं। मैं उन्हें सशक्त बनाने वाला कहूंगा।

यहां एक विज़ुअल चार्ट है कि सब कुछ कहां है।

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

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

एक्सटेंडर बस नियंत्रण में थोड़ा सुधार करते हैं, वर्कफ़्लो को पूरक करते हैं, या सीआई/सीडी पाइपलाइनों पर कोनों को काटते हैं।

हेल्म का भविष्य

अच्छी खबर यह है कि हेल्म 3 आ रहा है। हेल्म 3.0.0-अल्फा.2 का अल्फा संस्करण पहले ही जारी किया जा चुका है, आप इसे आज़मा सकते हैं। यह काफी स्थिर है, लेकिन कार्यक्षमता अभी भी सीमित है।

आपको हेल्म 3 की आवश्यकता क्यों है? सबसे पहले, यह एक कहानी है टिलर का गायब होना, एक घटक के रूप में। जैसा कि आप पहले ही समझ चुके हैं, यह एक बहुत बड़ा कदम है, क्योंकि वास्तुकला की सुरक्षा के दृष्टिकोण से, सब कुछ सरल हो गया है।

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

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

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

अंततः, जो चीज़ मैं निश्चित रूप से खो रहा था वह थी स्कीमा उद्भव और डेटा प्रकार सत्यापन. इंट या स्ट्रिंग के साथ कोई और समस्या नहीं होगी, शून्य को दोहरे उद्धरण चिह्नों में लपेटने की आवश्यकता नहीं होगी। एक JSONS स्कीमा दिखाई देगी जो आपको मानों के लिए इसका स्पष्ट रूप से वर्णन करने की अनुमति देगी।

बड़े पैमाने पर दोबारा काम किया जाएगा घटना-संचालित मॉडल. इसका वैचारिक वर्णन पहले ही किया जा चुका है। हेल्म 3 शाखा को देखें, और आप देखेंगे कि कितने ईवेंट और हुक और अन्य चीजें जोड़ी गई हैं, जो बहुत सरल हो जाएंगी और दूसरी ओर, तैनाती प्रक्रियाओं और उन पर प्रतिक्रियाओं पर नियंत्रण जोड़ देंगी।

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

एक और अच्छी खबर ये है DevOpsConf अलेक्जेंडर खायोरोव आपको बताएंगे, क्या कंटेनर सुरक्षित हो सकते हैं? आपको याद दिला दें कि विकास, परीक्षण और संचालन प्रक्रियाओं के एकीकरण पर सम्मेलन मास्को में आयोजित किया जाएगा 30 सितंबर और 1 अक्टूबर. आप इसे अभी भी 20 अगस्त तक कर सकते हैं एक सूचना प्रस्तुत करें और समाधान के साथ अपने अनुभव के बारे में हमें बताएं कई में से एक DevOps दृष्टिकोण के कार्य।

सम्मेलन चौकियों और समाचारों का अनुसरण करें मेलिंग सूची и टेलीग्राम चैनल.

स्रोत: www.habr.com