हेल्म सुरक्षा

Kubernetes साठी सर्वात लोकप्रिय पॅकेज व्यवस्थापकाच्या कथेचे सार इमोजी वापरून चित्रित केले जाऊ शकते:

• बॉक्स हेल्म आहे (जी नवीनतम इमोजी रिलीजच्या सर्वात जवळची गोष्ट आहे);
• लॉक - सुरक्षा;
• लहान माणूस समस्येवर उपाय आहे.

खरं तर, सर्वकाही थोडे अधिक क्लिष्ट असेल आणि कथा तांत्रिक तपशीलांनी भरलेली आहे हेल्म सुरक्षित कसे करावे.

• तुम्हाला माहीत नसेल किंवा विसरला असेल तर हेल्म म्हणजे काय. ते कोणत्या समस्यांचे निराकरण करते आणि ते इकोसिस्टममध्ये कोठे आहे.
• चला हेल्म आर्किटेक्चर पाहू. सुरक्षा आणि साधन किंवा उपाय अधिक सुरक्षित कसे बनवायचे याबद्दल कोणतेही संभाषण घटकाचे आर्किटेक्चर समजून घेतल्याशिवाय पूर्ण होत नाही.
• चला हेल्म घटकांवर चर्चा करूया.
• सर्वात ज्वलंत प्रश्न म्हणजे भविष्य - हेल्म 3 ची नवीन आवृत्ती. 

या लेखातील सर्व काही हेल्म 2 ला लागू होते. ही आवृत्ती सध्या उत्पादनात आहे आणि बहुधा तुम्ही सध्या वापरत असलेली आवृत्ती आहे आणि ही आवृत्ती आहे ज्यामध्ये सुरक्षा धोके आहेत.

स्पीकर बद्दल: अलेक्झांडर खयोरोव (allex) 10 वर्षांपासून विकसित होत आहे, सामग्री सुधारण्यात मदत करत आहे मॉस्को पायथन कॉन्फ++ आणि समितीत सामील झाले हेल्म समिट. आता तो चेनस्टॅकमध्ये डेव्हलपमेंट लीड म्हणून काम करतो - हे डेव्हलपमेंट मॅनेजर आणि अंतिम रिलीझ वितरीत करण्यासाठी जबाबदार असलेल्या व्यक्तीमधील संकर आहे. म्हणजेच, ते युद्धभूमीवर स्थित आहे, जिथे उत्पादनाच्या निर्मितीपासून ते ऑपरेशनपर्यंत सर्व काही घडते.

चेनस्टॅक हे एक लहान, सक्रियपणे वाढणारे स्टार्टअप आहे ज्याचे ध्येय क्लायंटला विकेंद्रित ऍप्लिकेशन्स चालवण्याच्या पायाभूत सुविधा आणि गुंतागुंत विसरून सक्षम करणे हे आहे; विकास संघ सिंगापूरमध्ये आहे. चेनस्टॅकला क्रिप्टोकरन्सी विकण्यास किंवा खरेदी करण्यास सांगू नका, परंतु एंटरप्राइझ ब्लॉकचेन फ्रेमवर्कबद्दल बोलण्याची ऑफर द्या आणि ते तुम्हाला आनंदाने उत्तर देतील.

प्रमुखपदी

हे Kubernetes साठी पॅकेज (चार्ट) व्यवस्थापक आहे. Kubernetes क्लस्टरमध्ये अनुप्रयोग आणण्याचा सर्वात अंतर्ज्ञानी आणि सार्वत्रिक मार्ग.

आम्ही अर्थातच तुमचे स्वतःचे YAML मॅनिफेस्ट तयार करणे आणि छोट्या उपयुक्तता लिहिण्यापेक्षा अधिक संरचनात्मक आणि औद्योगिक दृष्टिकोनाबद्दल बोलत आहोत.

हेल्म हे सर्वोत्कृष्ट आहे जे सध्या उपलब्ध आणि लोकप्रिय आहे.

हेलम का? मुख्यतः कारण ते CNCF द्वारे समर्थित आहे. Cloud Native ही एक मोठी संस्था आहे आणि Kubernetes, etcd, Fluentd आणि इतर प्रकल्पांसाठी मूळ कंपनी आहे.

आणखी एक महत्त्वाची वस्तुस्थिती अशी आहे की हेल्म हा एक अतिशय लोकप्रिय प्रकल्प आहे. मी जानेवारी 2019 मध्ये हेल्मला सुरक्षित कसे बनवायचे याबद्दल बोलायला सुरुवात केली तेव्हा GitHub वर प्रोजेक्टला हजार तारे होते. मे पर्यंत त्यापैकी 12 हजार होते.

बर्‍याच लोकांना हेल्ममध्ये स्वारस्य आहे, म्हणून तुम्ही अद्याप ते वापरत नसले तरीही, तुम्हाला त्याच्या सुरक्षिततेबद्दल जाणून घेण्याचा फायदा होईल. सुरक्षितता महत्त्वाची आहे.

कोर हेल्म टीमला Microsoft Azure द्वारे सपोर्ट आहे आणि त्यामुळे इतर बर्‍याच जणांप्रमाणे हा बर्‍यापैकी स्थिर प्रकल्प आहे. जुलैच्या मध्यात Helm 3 Alpha 2 चे प्रकाशन सूचित करते की या प्रकल्पावर बरेच लोक काम करत आहेत आणि त्यांच्यात हेल्म विकसित करण्याची आणि सुधारण्याची इच्छा आणि ऊर्जा आहे.

हेल्म कुबर्नेट्समधील ऍप्लिकेशन व्यवस्थापनाच्या अनेक मूळ समस्यांचे निराकरण करते.

• अनुप्रयोग पॅकेजिंग. वर्डप्रेसवरील “हॅलो, वर्ल्ड” सारख्या ऍप्लिकेशनमध्ये आधीपासून अनेक सेवा असतात आणि तुम्ही त्या एकत्र पॅकेज करू इच्छिता.
• या ऍप्लिकेशन्स व्यवस्थापित करताना येणारी जटिलता व्यवस्थापित करणे.
• एक जीवन चक्र जे अनुप्रयोग स्थापित केल्यानंतर किंवा तैनात केल्यानंतर समाप्त होत नाही. हे जगणे सुरूच आहे, ते अद्ययावत करणे आवश्यक आहे आणि हेल्म यासाठी मदत करतो आणि यासाठी योग्य उपाययोजना आणि धोरणे आणण्याचा प्रयत्न करतो.

बॅगिंग हे स्पष्टपणे आयोजित केले आहे: लिनक्स, विंडोज किंवा मॅकओएससाठी नियमित पॅकेज मॅनेजरच्या कामाच्या अनुषंगाने मेटाडेटा आहे. म्हणजे, एक रेपॉजिटरी, विविध पॅकेजेसवरील अवलंबित्व, ऍप्लिकेशन्ससाठी मेटा माहिती, सेटिंग्ज, कॉन्फिगरेशन वैशिष्ट्ये, माहिती अनुक्रमणिका, इ. हेल्म तुम्हाला ऍप्लिकेशन्ससाठी हे सर्व मिळवण्याची आणि वापरण्याची परवानगी देते.

जटिलता व्यवस्थापन. आपल्याकडे एकाच प्रकारचे अनेक अनुप्रयोग असल्यास, पॅरामीटरायझेशन आवश्यक आहे. टेम्पलेट्स यातून येतात, परंतु टेम्पलेट्स तयार करण्याचा तुमचा स्वतःचा मार्ग येऊ नये म्हणून, तुम्ही हेल्म ऑफर केलेल्या बॉक्सचा वापर करू शकता.

ऍप्लिकेशन लाइफसायकल व्यवस्थापन - माझ्या मते, हा सर्वात मनोरंजक आणि निराकरण न झालेला प्रश्न आहे. त्यामुळेच मी परवाच हेल्ममध्ये आलो. आम्हाला अॅप्लिकेशन लाइफसायकलचे निरीक्षण करायचे होते आणि आमची CI/CD आणि अॅप्लिकेशन सायकल या पॅराडाइममध्ये हलवायची होती.

हेल्म तुम्हाला याची अनुमती देते:

• उपयोजन व्यवस्थापित करा, कॉन्फिगरेशन आणि पुनरावृत्तीची संकल्पना सादर करा;
• यशस्वीरित्या रोलबॅक पार पाडणे;
• वेगवेगळ्या कार्यक्रमांसाठी हुक वापरा;
• अतिरिक्त ऍप्लिकेशन चेक जोडा आणि त्यांच्या परिणामांना प्रतिसाद द्या.

याव्यतिरिक्त हेल्ममध्ये "बॅटरी" आहेत - मोठ्या संख्येने चवदार गोष्टी ज्या प्लगइनच्या रूपात समाविष्ट केल्या जाऊ शकतात, आपले जीवन सुलभ करतात. प्लगइन स्वतंत्रपणे लिहिल्या जाऊ शकतात, ते अगदी वेगळ्या असतात आणि त्यांना कर्णमधुर आर्किटेक्चरची आवश्यकता नसते. तुम्हाला एखादी गोष्ट अंमलात आणायची असल्यास, मी ते प्लगइन म्हणून करण्याची शिफारस करतो आणि नंतर ते अपस्ट्रीममध्ये समाविष्ट करू शकतो.

हेल्म तीन मुख्य संकल्पनांवर आधारित आहे:

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

हेल्म आर्किटेक्चर

आकृती हेल्मच्या उच्च-स्तरीय आर्किटेक्चरचे संकल्पनात्मकपणे चित्रण करते.

मी तुम्हाला आठवण करून देतो की हेल्म हे कुबर्नेट्सशी संबंधित आहे. म्हणून, आम्ही कुबर्नेट्स क्लस्टर (आयत) शिवाय करू शकत नाही. कुबे-अपिसर्व्हर घटक मास्टरवर राहतो. हेल्मशिवाय आमच्याकडे Kubeconfig आहे. हेल्म एक लहान बायनरी आणते, जर तुम्ही त्याला असे म्हणू शकता, हेल्म सीएलआय युटिलिटी, जी संगणक, लॅपटॉप, मेनफ्रेम - कशावरही स्थापित केली जाते.

पण हे पुरेसे नाही. हेल्ममध्ये टिलर नावाचा सर्व्हर घटक आहे. हे क्लस्टरमधील हेल्मच्या स्वारस्यांचे प्रतिनिधित्व करते; हे इतर कोणत्याही प्रमाणेच कुबर्नेट्स क्लस्टरमधील एक ऍप्लिकेशन आहे.

चार्ट रेपोचा पुढील घटक चार्ट्ससह एक भांडार आहे. तेथे अधिकृत भांडार आहे आणि कंपनी किंवा प्रकल्पाचे खाजगी भांडार असू शकते.

संवाद

हेल्म वापरून अॅप्लिकेशन इन्स्टॉल करायचे असेल तेव्हा आर्किटेक्चरचे घटक कसे परस्परसंवाद करतात ते पाहू.

• आम्ही बोलत आहोत Helm install, रेपॉजिटरीमध्ये प्रवेश करा (चार्ट रेपो) आणि हेल्म चार्ट मिळवा.

• कोणत्या क्लस्टरशी संपर्क साधावा हे शोधण्यासाठी हेल्म युटिलिटी (हेल्म सीएलआय) कुबेकॉन्फिगशी संवाद साधते. 
• ही माहिती मिळाल्यानंतर, युटिलिटी टिलरचा संदर्भ देते, जे आमच्या क्लस्टरमध्ये आहे, अनुप्रयोग म्हणून. 
• टिलर कुबेरनेटमध्ये क्रिया करण्यासाठी, काही वस्तू (सेवा, पॉड्स, प्रतिकृती, रहस्ये इ.) तयार करण्यासाठी कुबे-एपिसर्व्हरला कॉल करतो.

पुढे, संपूर्ण हेल्म आर्किटेक्चर ज्या अटॅक वेक्टरच्या समोर येऊ शकते ते पाहण्यासाठी आकृती क्लिष्ट करू. आणि मग आम्ही तिचे संरक्षण करण्याचा प्रयत्न करू.

हल्ला वेक्टर

पहिला संभाव्य कमकुवत बिंदू आहे विशेषाधिकार प्राप्त API-वापरकर्ता. योजनेचा भाग म्हणून, हा एक हॅकर आहे ज्याने हेल्म CLI मध्ये प्रशासक प्रवेश मिळवला आहे.

विशेषाधिकार नसलेला API वापरकर्ता ते जवळपास कुठेतरी असल्यास धोका देखील देऊ शकतो. अशा वापरकर्त्याचा संदर्भ वेगळा असेल, उदाहरणार्थ, तो कुबेकॉन्फिग सेटिंग्जमधील एका क्लस्टर नेमस्पेसमध्ये निश्चित केला जाऊ शकतो.

सर्वात मनोरंजक हल्ला वेक्टर ही अशी प्रक्रिया असू शकते जी टिलरच्या जवळ कुठेतरी क्लस्टरमध्ये राहते आणि त्यात प्रवेश करू शकते. हे क्लस्टरचे नेटवर्क वातावरण पाहणारे वेब सर्व्हर किंवा मायक्रोसर्व्हिस असू शकते.

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

चला या चारही बाजूंनी होणारे हल्ले रोखण्याचा प्रयत्न करूया आणि हेल्म आर्किटेक्चरमध्ये कुठे समस्या आहेत आणि कुठे, कदाचित, कुठेच नाही हे शोधून काढूया.

चला आकृती मोठे करू, अधिक घटक जोडा, परंतु सर्व मूलभूत घटक ठेवा.

हेल्म सीएलआय चार्ट रेपोशी संवाद साधते, कुबेकॉन्फिगशी संवाद साधते आणि काम क्लस्टरमध्ये टिलर घटकाकडे हस्तांतरित केले जाते.

टिलर दोन वस्तूंनी दर्शविले जाते:

• टिलर-डिप्लॉय एसव्हीसी, जी विशिष्ट सेवा उघड करते;
• टिलर-डिप्लॉय पॉड (एका प्रतिकृतीमध्ये एकाच प्रतीमध्ये आकृतीमध्ये), ज्यावर संपूर्ण भार चालतो, जो क्लस्टरमध्ये प्रवेश करतो.

परस्परसंवादासाठी वेगवेगळे प्रोटोकॉल आणि योजना वापरल्या जातात. सुरक्षेच्या दृष्टिकोनातून, आम्हाला यामध्ये सर्वात जास्त स्वारस्य आहे:

• हेल्म सीएलआय ज्या यंत्रणेद्वारे चार्ट रेपोमध्ये प्रवेश करते: कोणता प्रोटोकॉल, तेथे प्रमाणीकरण आहे आणि त्याद्वारे काय केले जाऊ शकते.
• प्रोटोकॉल ज्याद्वारे हेल्म CLI, kubectl वापरून, टिलरशी संप्रेषण करते. हा क्लस्टरमध्ये स्थापित केलेला RPC सर्व्हर आहे.
• टिलर स्वतः मायक्रोसर्व्हिसेससाठी प्रवेशयोग्य आहे जे क्लस्टरमध्ये राहतात आणि कुबे-एपिसर्व्हरशी संवाद साधतात.

चला या सर्व क्षेत्रांची क्रमाने चर्चा करूया.

RBAC

RBAC सक्षम केल्याशिवाय हेल्म किंवा क्लस्टरमधील इतर कोणत्याही सेवेबद्दल बोलण्यात काही अर्थ नाही.

असे दिसते की ही नवीनतम शिफारस नाही, परंतु मला खात्री आहे की बर्याच लोकांनी अद्याप उत्पादनात देखील RBAC सक्षम केले नाही, कारण ही खूप गडबड आहे आणि बर्याच गोष्टी कॉन्फिगर करणे आवश्यक आहे. तथापि, मी तुम्हाला हे करण्यास प्रोत्साहित करतो.

https://rbac.dev/ - RBAC साठी वेबसाइट वकील. यात मोठ्या प्रमाणात मनोरंजक सामग्री आहे जी तुम्हाला RBAC सेट करण्यात मदत करेल, ते चांगले का आहे आणि उत्पादनात मूलतः त्यासह कसे जगायचे ते दर्शवेल.

टिलर आणि RBAC कसे कार्य करतात हे मी समजावून सांगण्याचा प्रयत्न करेन. टिलर एका विशिष्ट सेवा खात्याच्या अंतर्गत क्लस्टरमध्ये कार्य करते. सामान्यतः, जर RBAC कॉन्फिगर केलेले नसेल, तर हा सुपरयूजर असेल. मूलभूत कॉन्फिगरेशनमध्ये, टिलर प्रशासक असेल. म्हणूनच टिलर हा तुमच्या क्लस्टरसाठी एक SSH बोगदा आहे असे अनेकदा म्हटले जाते. खरेतर, हे खरे आहे, त्यामुळे तुम्ही वरील आकृतीमध्ये डीफॉल्ट सेवा खात्याऐवजी स्वतंत्र समर्पित सेवा खाते वापरू शकता.

जेव्हा तुम्ही हेल्म सुरू करता आणि प्रथमच सर्व्हरवर स्थापित करता, तेव्हा तुम्ही सेवा खाते वापरून सेट करू शकता --service-account. हे तुम्हाला किमान आवश्यक अधिकार संचासह वापरकर्ता वापरण्यास अनुमती देईल. खरे आहे, आपल्याला अशी "माला" तयार करावी लागेल: भूमिका आणि भूमिका बंधनकारक.

दुर्दैवाने, हेल्म तुमच्यासाठी हे करणार नाही. हेल्म पास करण्यासाठी तुम्ही किंवा तुमच्या कुबर्नेट्स क्लस्टर अॅडमिनिस्ट्रेटरला सेवा-खात्यासाठी भूमिका आणि रोलबाइंडिंगचा संच आधीच तयार करणे आवश्यक आहे.

प्रश्न उद्भवतो - रोल आणि क्लस्टररोलमध्ये काय फरक आहे? फरक असा आहे की क्लस्टररोल सर्व नेमस्पेससाठी कार्य करते, नियमित भूमिका आणि रोलबाइंडिंग्सच्या विपरीत, जे केवळ विशिष्ट नेमस्पेससाठी कार्य करते. तुम्ही संपूर्ण क्लस्टर आणि सर्व नेमस्पेससाठी पॉलिसी कॉन्फिगर करू शकता किंवा प्रत्येक नेमस्पेससाठी वैयक्तिकरित्या वैयक्तिकृत करू शकता.

हे लक्षात घेण्यासारखे आहे की RBAC आणखी एक मोठी समस्या सोडवते. बरेच लोक तक्रार करतात की हेल्म, दुर्दैवाने, मल्टीटेनन्सी नाही (मल्टीटेनन्सीला समर्थन देत नाही). जर अनेक संघ क्लस्टर वापरतात आणि हेल्म वापरतात, तर या क्लस्टरमध्ये धोरणे सेट करणे आणि त्यांचा प्रवेश मर्यादित करणे मुळात अशक्य आहे, कारण हेल्म ज्या अंतर्गत चालते त्याखाली एक विशिष्ट सेवा खाते आहे आणि ते क्लस्टरमधील सर्व संसाधने त्याच्या अंतर्गत तयार करते. , जे कधीकधी खूप गैरसोयीचे असते. हे खरे आहे - बायनरी फाइल प्रमाणे, प्रक्रियेप्रमाणे, हेल्म टिलरकडे मल्टीटेनन्सीची कोणतीही संकल्पना नाही.

तथापि, एक उत्कृष्ट मार्ग आहे जो आपल्याला क्लस्टरमध्ये टिलर अनेक वेळा चालविण्यास अनुमती देतो. यामध्ये कोणतीही अडचण नाही, टिलर प्रत्येक नेमस्पेसमध्ये लॉन्च केला जाऊ शकतो. अशा प्रकारे, तुम्ही संदर्भ म्हणून RBAC, Kubeconfig वापरू शकता आणि विशेष हेल्ममध्ये प्रवेश मर्यादित करू शकता.

हे असे दिसेल.

उदाहरणार्थ, वेगवेगळ्या टीम्ससाठी (दोन नेमस्पेसेस) संदर्भासह दोन कुबेकॉन्फिग्स आहेत: डेव्हलपमेंट टीमसाठी एक्स टीम आणि अॅडमिन क्लस्टर. अ‍ॅडमिन क्लस्टरचे स्वतःचे विस्तृत टिलर आहे, जे कुबे-सिस्टम नेमस्पेसमध्ये स्थित आहे, एक अनुरुप प्रगत सेवा-खाते. आणि डेव्हलपमेंट टीमसाठी स्वतंत्र नेमस्पेस, ते त्यांच्या सेवा एका खास नेमस्पेसवर तैनात करू शकतील.

हा एक कार्यक्षम दृष्टीकोन आहे, टिलर इतका वीज भुकेलेला नाही की त्याचा तुमच्या बजेटवर खूप परिणाम होईल. हा एक द्रुत उपाय आहे.

टिलर स्वतंत्रपणे कॉन्फिगर करा आणि टीमसाठी, विशिष्ट विकसकासाठी किंवा पर्यावरणासाठी संदर्भासह Kubeconfig प्रदान करा: देव, स्टेजिंग, उत्पादन (सर्व काही एकाच क्लस्टरवर असेल यात शंका नाही, तथापि, हे केले जाऊ शकते).

आमची कथा पुढे चालू ठेवत, चला RBAC वरून स्विच करूया आणि ConfigMaps बद्दल बोलूया.

कॉन्फिगमॅप्स

हेल्म कॉन्फिगमॅप्सचा डेटा स्टोअर म्हणून वापर करते. जेव्हा आम्ही आर्किटेक्चरबद्दल बोललो तेव्हा कुठेही असा डेटाबेस नव्हता जो रिलीझ, कॉन्फिगरेशन, रोलबॅक इ. बद्दल माहिती संग्रहित करेल. यासाठी ConfigMaps वापरला जातो.

ConfigMaps सह मुख्य समस्या ज्ञात आहे - ते तत्त्वतः असुरक्षित आहेत; संवेदनशील डेटा संग्रहित करणे अशक्य आहे. आम्ही सेवेच्या पलीकडे जाऊ नये अशा प्रत्येक गोष्टीबद्दल बोलत आहोत, उदाहरणार्थ, पासवर्ड. हेल्मसाठी सध्याचा सर्वात मूळ मार्ग म्हणजे कॉन्फिगमॅप्स वापरण्यापासून सिक्रेट्सवर स्विच करणे.

हे अगदी सोप्या पद्धतीने केले जाते. टिलर सेटिंग ओव्हरराइड करा आणि स्टोरेज गुप्त असेल हे निर्दिष्ट करा. मग प्रत्येक डिप्लॉयमेंटसाठी तुम्हाला कॉन्फिगमॅप नाही तर एक गुप्त मिळेल.

आपण असा युक्तिवाद करू शकता की रहस्ये ही एक विचित्र संकल्पना आहे आणि ती खूप सुरक्षित नाही. तथापि, हे समजण्यासारखे आहे की कुबर्नेट्स विकसक स्वतः हे करत आहेत. आवृत्ती 1.10 पासून सुरू होत आहे, म्हणजे गेल्या काही काळापासून, किमान सार्वजनिक ढगांमध्ये, रहस्ये साठवण्यासाठी योग्य स्टोरेज कनेक्ट करणे शक्य झाले आहे. टीम आता गुपिते, वैयक्तिक पॉड्स किंवा इतर संस्थांमध्ये प्रवेश चांगल्या प्रकारे वितरित करण्याच्या मार्गांवर काम करत आहे.

स्टोरेज हेल्मला सिक्रेट्समध्ये हस्तांतरित करणे चांगले आहे आणि त्या बदल्यात ते मध्यभागी सुरक्षित आहेत.

अर्थातच राहील 1 MB ची डेटा स्टोरेज मर्यादा. हेल्म येथे कॉन्फिगमॅप्ससाठी वितरित स्टोरेज म्हणून etcd वापरते. आणि तेथे त्यांनी विचार केला की प्रतिकृती इत्यादीसाठी हा एक योग्य डेटा भाग आहे. Reddit वर याबद्दल एक मनोरंजक चर्चा आहे, मी आठवड्याच्या शेवटी हे मजेदार वाचन किंवा अर्क वाचण्याची शिफारस करतो येथे.

चार्ट रेपो

चार्ट हे सर्वात सामाजिकदृष्ट्या असुरक्षित आहेत आणि "मॅन इन द मिडल" चे स्त्रोत बनू शकतात, विशेषतः जर तुम्ही स्टॉक सोल्यूशन वापरत असाल. सर्व प्रथम, आम्ही रिपॉजिटरीजबद्दल बोलत आहोत जे HTTP द्वारे उघड केले जातात.

तुम्हाला निश्चितपणे हेल्म रेपो HTTPS वर उघड करणे आवश्यक आहे - हा सर्वोत्तम पर्याय आहे आणि स्वस्त आहे.

च्याकडे लक्ष देणे चार्ट स्वाक्षरी यंत्रणा. तंत्रज्ञान नरकासारखे सोपे आहे. हीच गोष्ट तुम्ही GitHub वर वापरता, सार्वजनिक आणि खाजगी की सह नियमित PGP मशीन. सेट करा आणि खात्री करा, आवश्यक की आणि प्रत्येक गोष्टीवर स्वाक्षरी करा, की हा खरोखर तुमचा चार्ट आहे.

शिवाय, हेल्म क्लायंट TLS चे समर्थन करते (सर्व्हर-साइड HTTP अर्थाने नाही, परंतु परस्पर TLS). संवाद साधण्यासाठी तुम्ही सर्व्हर आणि क्लायंट की वापरू शकता. खरे सांगायचे तर, मी अशी यंत्रणा वापरत नाही कारण मला परस्पर प्रमाणपत्रे आवडत नाहीत. मुळात, चार्ट संग्रहालय - हेल्म 2 साठी हेल्म रेपो सेट करण्यासाठी मुख्य साधन - मूलभूत प्रमाणीकरणास देखील समर्थन देते. जर ते अधिक सोयीस्कर आणि शांत असेल तर तुम्ही मूलभूत प्रमाणीकरण वापरू शकता.

एक प्लगइन देखील आहे हेल्म-जीसीएस, जे तुम्हाला Google Cloud Storage वर चार्ट रेपो होस्ट करण्याची अनुमती देते. हे अगदी सोयीस्कर आहे, उत्तम कार्य करते आणि अगदी सुरक्षित आहे, कारण वर्णन केलेल्या सर्व यंत्रणा पुनर्नवीनीकरण केल्या आहेत.

तुम्ही HTTPS किंवा TLS सक्षम केल्यास, mTLS वापरल्यास आणि जोखीम कमी करण्यासाठी मूलभूत प्रमाणीकरण सक्षम केल्यास, तुम्हाला हेल्म सीएलआय आणि चार्ट रेपोसह एक सुरक्षित संप्रेषण चॅनेल मिळेल.

gRPC API

पुढची पायरी खूप महत्वाची आहे - टिलर सुरक्षित करण्यासाठी, जो क्लस्टरमध्ये स्थित आहे आणि एकीकडे, सर्व्हर आहे, दुसरीकडे, तो स्वतः इतर घटकांमध्ये प्रवेश करतो आणि कोणीतरी असल्याचे भासवण्याचा प्रयत्न करतो.

मी आधीच म्हटल्याप्रमाणे, टिलर ही एक सेवा आहे जी जीआरपीसीचा पर्दाफाश करते, हेल्म क्लायंट त्याच्याकडे gRPC द्वारे येतो. डीफॉल्टनुसार, अर्थातच, TLS अक्षम आहे. हे का केले गेले हा एक वादाचा प्रश्न आहे, मला असे वाटते की सुरुवातीला सेटअप सुलभ करा.

उत्पादनासाठी आणि अगदी स्टेजिंगसाठी, मी gRPC वर TLS सक्षम करण्याची शिफारस करतो.

माझ्या मते, चार्टसाठी mTLS च्या विपरीत, हे येथे योग्य आहे आणि अगदी सोप्या पद्धतीने केले जाते - PQI इन्फ्रास्ट्रक्चर व्युत्पन्न करा, एक प्रमाणपत्र तयार करा, टिलर लाँच करा, सुरुवातीच्या वेळी प्रमाणपत्र हस्तांतरित करा. यानंतर, तुम्ही व्युत्पन्न प्रमाणपत्र आणि खाजगी कीसह स्वतःला सादर करून, सर्व हेल्म कमांड्स कार्यान्वित करू शकता.

अशा प्रकारे तुम्ही क्लस्टरच्या बाहेरून टिलरला केलेल्या सर्व विनंत्यांपासून स्वतःचे संरक्षण कराल.

म्हणून, आम्ही टिलरशी कनेक्शन चॅनेल सुरक्षित केले आहे, आम्ही आधीच RBAC वर चर्चा केली आहे आणि Kubernetes apiserver चे अधिकार समायोजित केले आहेत, ज्या डोमेनशी ते संवाद साधू शकतात ते कमी केले आहे.

संरक्षित हेलम

चला अंतिम आकृती पाहू. हे त्याच बाणांसह समान आर्किटेक्चर आहे.

सर्व कनेक्शन आता सुरक्षितपणे हिरव्या रंगात काढले जाऊ शकतात:

• चार्ट रेपोसाठी आम्ही TLS किंवा mTLS आणि मूलभूत प्रमाणीकरण वापरतो;
• टिलरसाठी mTLS, आणि ती TLS सह gRPC सेवा म्हणून उघडकीस आली आहे, आम्ही प्रमाणपत्रे वापरतो;
• क्लस्टर रोल आणि रोलबाइंडिंगसह एक विशेष सेवा खाते वापरते. 

आम्ही क्लस्टर लक्षणीयरित्या सुरक्षित केले आहे, परंतु कोणीतरी हुशार म्हणाला:

"फक्त एक पूर्णपणे सुरक्षित उपाय असू शकतो - एक बंद केलेला संगणक, जो काँक्रीट बॉक्समध्ये स्थित आहे आणि सैनिकांनी पहारा दिला आहे."

डेटा हाताळण्याचे आणि नवीन आक्रमण वेक्टर शोधण्याचे वेगवेगळे मार्ग आहेत. तथापि, मला खात्री आहे की या शिफारशी सुरक्षिततेसाठी मूलभूत उद्योग मानक साध्य करतील.

बोनस

हा भाग थेट सुरक्षेशी संबंधित नाही, पण उपयोगीही ठरेल. मी तुम्हाला काही मनोरंजक गोष्टी दाखवतो ज्याबद्दल फार कमी लोकांना माहिती आहे. उदाहरणार्थ, चार्ट कसे शोधायचे - अधिकृत आणि अनधिकृत.

भांडारात github.com/helm/charts आता सुमारे 300 चार्ट आणि दोन प्रवाह आहेत: स्थिर आणि इनक्यूबेटर. इनक्यूबेटरमधून स्थिरापर्यंत जाणे किती कठीण आहे आणि स्थिरतेतून बाहेर पडणे किती सोपे आहे हे योगदान देणार्‍या कोणालाही चांगले माहित आहे. तथापि, प्रोमिथियससाठी चार्ट शोधण्यासाठी हे सर्वोत्तम साधन नाही आणि तुम्हाला जे काही आवडते ते, एका साध्या कारणासाठी - हे एक पोर्टल नाही जिथे तुम्ही पॅकेजेस शोधू शकता.

पण एक सेवा आहे hub.helm.sh, जे चार्ट शोधणे अधिक सोयीस्कर बनवते. सर्वात महत्त्वाचे म्हणजे, तेथे बरेच बाह्य भांडार आणि जवळजवळ 800 आकर्षणे उपलब्ध आहेत. शिवाय, जर काही कारणास्तव तुम्हाला तुमचे चार्ट स्टेबलवर पाठवायचे नसतील तर तुम्ही तुमचा रेपॉजिटरी कनेक्ट करू शकता.

hub.helm.sh वापरून पहा आणि चला एकत्र विकसित करूया. ही सेवा हेल्म प्रकल्पांतर्गत आहे आणि जर तुम्ही फ्रंट-एंड डेव्हलपर असाल आणि फक्त देखावा सुधारू इच्छित असाल तर तुम्ही त्याच्या UI मध्ये योगदान देऊ शकता.

मी तुमचे लक्ष वेधून घेऊ इच्छितो सेवा ब्रोकर API एकत्रीकरण उघडा. हे अवजड आणि अस्पष्ट वाटते, परंतु ते प्रत्येकाला तोंड देत असलेल्या समस्यांचे निराकरण करते. मी एका साध्या उदाहरणाने स्पष्ट करतो.

एक कुबर्नेट्स क्लस्टर आहे ज्यामध्ये आम्हाला एक क्लासिक ऍप्लिकेशन चालवायचे आहे - वर्डप्रेस. साधारणपणे, संपूर्ण कार्यक्षमतेसाठी डेटाबेस आवश्यक असतो. अनेक भिन्न उपाय आहेत, उदाहरणार्थ, तुम्ही तुमची स्वतःची स्टेटफुल सेवा सुरू करू शकता. हे फार सोयीचे नाही, परंतु बरेच लोक ते करतात.

चेनस्टॅकवरील आमच्यासारखे इतर, त्यांच्या सर्व्हरसाठी MySQL किंवा PostgreSQL सारखे व्यवस्थापित डेटाबेस वापरतात. म्हणूनच आमचे डेटाबेस क्लाउडमध्ये कुठेतरी स्थित आहेत.

परंतु एक समस्या उद्भवते: आम्हाला आमची सेवा डेटाबेसशी जोडणे आवश्यक आहे, डेटाबेसची चव तयार करणे, क्रेडेन्शियल हस्तांतरित करणे आणि ते कसे तरी व्यवस्थापित करणे आवश्यक आहे. हे सर्व सहसा सिस्टम प्रशासक किंवा विकासकाद्वारे व्यक्तिचलितपणे केले जाते. आणि जेव्हा काही अनुप्रयोग असतील तेव्हा कोणतीही समस्या नाही. जेव्हा ते बरेच असतात, तेव्हा आपल्याला एकत्र करणे आवश्यक आहे. असा एक कापणी यंत्र आहे - तो सर्व्हिस ब्रोकर आहे. हे तुम्हाला सार्वजनिक क्लाउड क्लस्टरसाठी विशेष प्लगइन वापरण्याची आणि ब्रोकरद्वारे प्रदात्याकडून संसाधने ऑर्डर करण्याची अनुमती देते, जसे की ते API आहे. हे करण्यासाठी, आपण मूळ कुबर्नेट्स टूल्स वापरू शकता.

हे खूप सोपे आहे. तुम्ही क्वेरी करू शकता, उदाहरणार्थ, बेस टियरसह Azure मध्ये व्यवस्थापित MySQL (हे कॉन्फिगर केले जाऊ शकते). Azure API वापरून, डेटाबेस तयार केला जाईल आणि वापरासाठी तयार केला जाईल. आपल्याला यामध्ये हस्तक्षेप करण्याची आवश्यकता नाही, प्लगइन यासाठी जबाबदार आहे. उदाहरणार्थ, OSBA (Azure प्लगइन) सेवेला क्रेडेन्शिअल परत करेल आणि हेल्मला पास करेल. तुम्ही क्लाउड MySQL सह वर्डप्रेस वापरण्यास सक्षम असाल, व्यवस्थापित डेटाबेसशी अजिबात व्यवहार करू नका आणि आत स्टेटफुल सेवांबद्दल काळजी करू नका.

आम्ही असे म्हणू शकतो की हेल्म एक गोंद म्हणून कार्य करते जे एकीकडे, आपल्याला सेवा तैनात करण्याची परवानगी देते आणि दुसरीकडे, क्लाउड प्रदात्यांच्या संसाधनांचा वापर करते.

तुम्ही तुमचे स्वतःचे प्लगइन लिहू शकता आणि ही संपूर्ण कथा ऑन-प्रिमाइस वापरू शकता. मग तुमच्याकडे कॉर्पोरेट क्लाउड प्रदात्यासाठी तुमचे स्वतःचे प्लगइन असेल. मी हा दृष्टीकोन वापरण्याची शिफारस करतो, विशेषत: जर तुमच्याकडे मोठ्या प्रमाणावर असेल आणि एखाद्या वैशिष्ट्यासाठी dev, स्टेजिंग किंवा संपूर्ण इन्फ्रास्ट्रक्चर त्वरित तैनात करायचे असेल. हे तुमच्या ऑपरेशन्स किंवा DevOps साठी आयुष्य सोपे करेल.

मी आधीच नमूद केलेला आणखी एक शोध आहे हेल्म-जीसीएस प्लगइन, जे तुम्हाला हेल्म चार्ट संचयित करण्यासाठी Google-बकेट्स (ऑब्जेक्ट स्टोरेज) वापरण्याची परवानगी देते.

ते वापरणे सुरू करण्यासाठी तुम्हाला फक्त चार कमांडची आवश्यकता आहे:

1. प्लगइन स्थापित करा;
2. ते सुरू करा;
3. gcp मध्ये असलेल्या बकेटचा मार्ग सेट करा;
4. मानक पद्धतीने तक्ते प्रकाशित करा.

सौंदर्य हे आहे की अधिकृततेसाठी मूळ जीसीपी पद्धत वापरली जाईल. तुम्ही सेवा खाते, विकासक खाते, तुम्हाला हवे ते वापरू शकता. हे खूप सोयीस्कर आहे आणि ऑपरेट करण्यासाठी काहीही खर्च लागत नाही. जर तुम्ही, माझ्याप्रमाणे, opsless तत्वज्ञानाचा प्रचार करत असाल, तर हे विशेषतः लहान संघांसाठी खूप सोयीचे असेल.

विकल्प

हेल्म हा एकमेव सेवा व्यवस्थापन उपाय नाही. याबद्दल बरेच प्रश्न आहेत, म्हणूनच कदाचित तिसरी आवृत्ती इतक्या लवकर का आली. अर्थात पर्याय आहेत.

हे विशेष उपाय असू शकतात, उदाहरणार्थ, Ksonnet किंवा Metaparticle. तुम्ही तुमची क्लासिक इन्फ्रास्ट्रक्चर मॅनेजमेंट टूल्स (Ansible, Terraform, Chef, इ.) वापरू शकता त्याच उद्देशांसाठी ज्याबद्दल मी बोललो.

शेवटी एक उपाय आहे ऑपरेटर फ्रेमवर्क, ज्यांची लोकप्रियता वाढत आहे.

ऑपरेटर फ्रेमवर्क हा विचार करण्यासाठी शीर्ष हेल्म पर्याय आहे.

हे CNCF आणि Kubernetes चे अधिक मूळ आहे, पण प्रवेशाचा अडथळा जास्त आहे, तुम्हाला अधिक प्रोग्राम करणे आणि मॅनिफेस्टचे कमी वर्णन करणे आवश्यक आहे.

ड्राफ्ट, स्कॅफोल्ड असे विविध अॅडऑन्स आहेत. ते जीवन खूप सोपे करतात, उदाहरणार्थ, ते चाचणी वातावरण तैनात करण्यासाठी विकसकांसाठी हेल्म पाठवण्याचे आणि लॉन्च करण्याचे चक्र सुलभ करतात. मी त्यांना सशक्त म्हणेन.

सर्व काही कुठे आहे याचा एक व्हिज्युअल चार्ट येथे आहे.

x-अक्षावर जे घडत आहे त्यावर आपल्या वैयक्तिक नियंत्रणाची पातळी आहे, y-अक्षावर कुबर्नेट्सच्या मूळत्वाची पातळी आहे. हेल्म आवृत्ती 2 मध्यभागी कुठेतरी येते. आवृत्ती 3 मध्ये, मोठ्या प्रमाणावर नाही, परंतु नियंत्रण आणि मूळपणाची पातळी दोन्ही सुधारली गेली आहेत. Ksonnet स्तरावरील उपाय अजूनही हेल्म 2 पेक्षा कमी दर्जाचे आहेत. तथापि, या जगात आणखी काय आहे हे जाणून घेण्यासाठी ते पाहण्यासारखे आहेत. अर्थात, तुमचा कॉन्फिगरेशन मॅनेजर तुमच्या नियंत्रणाखाली असेल, पण तो कुबेर्नेट्सचा मुळीच नाही.

ऑपरेटर फ्रेमवर्क पूर्णपणे कुबेरनेटचे मूळ आहे आणि तुम्हाला ते अधिक सुंदर आणि काळजीपूर्वक व्यवस्थापित करण्याची परवानगी देते (परंतु एंट्री लेव्हलबद्दल लक्षात ठेवा). त्याऐवजी, हेल्म वापरून मोठ्या संख्येने ऍप्लिकेशन्सचे पॅकेजिंग करण्यासाठी मास हार्वेस्टरऐवजी हे विशेष ऍप्लिकेशन आणि त्यासाठी व्यवस्थापन निर्मितीसाठी योग्य आहे.

विस्तारक फक्त नियंत्रण थोडे सुधारतात, वर्कफ्लो पूरक करतात किंवा CI/CD पाइपलाइनवरील कोपरे कापतात.

हेल्मचे भविष्य

चांगली बातमी अशी आहे की हेल्म 3 येत आहे. हेल्म 3.0.0-अल्फा.2 ची अल्फा आवृत्ती आधीच रिलीज झाली आहे, तुम्ही ते वापरून पाहू शकता. हे बरेच स्थिर आहे, परंतु कार्यक्षमता अद्याप मर्यादित आहे.

तुम्हाला हेल्म 3 ची गरज का आहे? सर्व प्रथम, ही एक कथा आहे टिलर गायब, एक घटक म्हणून. हे, जसे आपण आधीच समजले आहे, हे एक मोठे पाऊल आहे, कारण आर्किटेक्चरच्या सुरक्षिततेच्या दृष्टिकोनातून, सर्वकाही सरलीकृत आहे.

जेव्हा हेल्म 2 तयार केले गेले, जे कुबर्नेट्स 1.8 किंवा त्याहूनही पूर्वीचे होते, तेव्हा अनेक संकल्पना अपरिपक्व होत्या. उदाहरणार्थ, CRD संकल्पना आता सक्रियपणे अंमलात आणली जात आहे आणि हेल्म करेल CRD वापरासंरचना साठवण्यासाठी. केवळ क्लायंट वापरणे शक्य होईल आणि सर्व्हरचा भाग राखणे शक्य होणार नाही. त्यानुसार, स्ट्रक्चर्स आणि रिसोर्सेससह काम करण्यासाठी नेटिव्ह Kubernetes कमांड वापरा. हे एक मोठे पाऊल पुढे आहे.

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

माझ्यासाठी वादग्रस्त कथा आहे लुआ समर्थन, स्क्रिप्ट लिहिण्यासाठी टेम्प्लेटिंग इंजिन म्हणून. मी लुआचा मोठा चाहता नाही, परंतु हे पूर्णपणे वैकल्पिक वैशिष्ट्य असेल. मी हे 3 वेळा तपासले - लुआ वापरणे आवश्यक नाही. म्हणून ज्यांना लुआ वापरण्याची इच्छा आहे, ज्यांना गो आवडते त्यांनी आमच्या मोठ्या शिबिरात सामील व्हा आणि यासाठी go-tmpl वापरा.

शेवटी, मी निश्चितपणे गमावले होते स्कीमा उदय आणि डेटा प्रकार प्रमाणीकरण. इंट किंवा स्ट्रिंगमध्ये यापुढे कोणतीही समस्या येणार नाही, दुहेरी अवतरणांमध्ये शून्य गुंडाळण्याची गरज नाही. एक JSONS स्कीमा दिसेल जो तुम्हाला मूल्यांसाठी याचे स्पष्टपणे वर्णन करण्यास अनुमती देईल.

जोरदारपणे पुन्हा काम केले जाईल इव्हेंट-चालित मॉडेल. हे आधीच संकल्पनात्मक वर्णन केले गेले आहे. हेल्म 3 शाखा पहा, आणि तुम्हाला दिसेल की किती घटना आणि हुक आणि इतर गोष्टी जोडल्या गेल्या आहेत, ज्या मोठ्या प्रमाणात सुलभ होतील आणि दुसरीकडे, उपयोजन प्रक्रिया आणि त्यांच्यावरील प्रतिक्रियांवर नियंत्रण जोडेल.

हेल्म 3 अधिक सोपे, सुरक्षित आणि अधिक मनोरंजक असेल, कारण आम्हाला हेल्म 2 आवडत नाही, परंतु कुबर्नेट्स अधिक प्रगत होत आहेत म्हणून. त्यानुसार, हेल्म कुबर्नेट्सच्या विकासाचा वापर करू शकतो आणि त्यावर कुबर्नेट्ससाठी उत्कृष्ट व्यवस्थापक तयार करू शकतो.

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

येथे कॉन्फरन्स चेकपॉईंट आणि बातम्यांचे अनुसरण करा पत्रव्यवहाराची यादी и टेलिग्राम चॅनेल.

स्त्रोत: www.habr.com