HashiCorp तिजोरी के साथ राज का प्रबंधन

कैसे रखें राज? रिपॉजिटरी में, परिनियोजन प्रणाली में या कॉन्फ़िगरेशन प्रबंधन प्रणाली में? एक व्यक्तिगत कंप्यूटर पर, सर्वर पर, या शायद बिस्तर के नीचे एक बॉक्स में? और लीक को रोकने के लिए रहस्यों का प्रबंधन कैसे करें?

सर्गेई नोसकोव ( अलिबेक ) - एविटो के मंच के सूचना सुरक्षा समूह के प्रमुख , इन सवालों का जवाब जानते हैं और हमारे साथ साझा करेंगे। Avito में, HashiCorp वॉल्ट सक्रिय रूप से दो वर्षों के लिए HashiCorp वॉल्ट का उपयोग कर रहा है, उस समय के दौरान उन्हें "मास्टर" स्तर पर धक्कों और पंप अनुभव मिला।

लेख में हम तिजोरी के बारे में विस्तार से बात करेंगे: यह क्या है, कंपनी में इसका उपयोग कहां और कैसे किया जाता है, एवितो HashiCorp वॉल्ट का उपयोग करके रहस्यों का प्रबंधन कैसे करता है, कठपुतली और कुबेरनेट का उपयोग कैसे किया जाता है, कठपुतली और अन्य SCM के मामलों का उपयोग करें, क्या समस्याएं उत्पन्न होती हैं, सुरक्षा में क्या दर्द होता है और डेवलपर्स, और निश्चित रूप से, इसे ठीक करने के तरीके पर विचार साझा करें।

एक रहस्य क्या है?

कोई भी गोपनीय जानकारी:

• लॉगिन और पासवर्ड, उदाहरण के लिए, डेटाबेस के लिए;
• एपीआई कुंजी
• सर्वर प्रमाणपत्र कुंजी (* .google.com)
• ग्राहक प्रमाणपत्र कुंजी (साझेदार, यांडेक्स मनी, क्यूआईडब्ल्यूआई);
• मोबाइल एप्लिकेशन पर हस्ताक्षर करने की कुंजी।

सभी जानकारी जो हम गुप्त रखना चाहते हैं, हम एक रहस्य कहते हैं। यह एक स्टोरेज समस्या पैदा करता है: भंडार में स्टोर करना बुरा है, एन्क्रिप्टेड रूप में - आपको एन्क्रिप्शन कुंजियों को कहीं न कहीं रखने की आवश्यकता है।

HashiCorp वॉल्ट समस्या के अच्छे समाधानों में से एक है।

• सुरक्षित रूप से स्टोर और चाबी का प्रबंधन करता है।
• Microservices की दुनिया पर पैनापन, क्योंकि microservice ही।
• HashiCorp वॉल्ट ने एसीएल और न्यूनतम विशेषाधिकार के सिद्धांत जैसे रहस्यों तक पहुंच को प्रमाणित और अधिकृत करने के लिए बहुत कुछ किया है।
• JSON के साथ REST इंटरफ़ेस।
• सुरक्षा सही नहीं है, लेकिन काफी उच्च स्तर पर है।

मेरी राय में, यह एक काफी सुविधाजनक उपकरण है।

HashiCorp वॉल्ट में नया क्या है

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

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

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

चिकन और अंडे की समस्या

जब आप गोपनीय जानकारी संग्रहीत करने का मुद्दा उठाते हैं और एन्क्रिप्ट करने का निर्णय लेते हैं, तो जैसे ही आप कुछ एन्क्रिप्ट करते हैं, आपका गुप्त एन्क्रिप्शन की जगह से कुंजी को संग्रहीत करने के लिए चलता है। यह हर समय होता है: जैसे ही आपने किसी रहस्य को बचाया है या किसी मौजूदा को बदल दिया है, आपके पास एक और एक है और एक मुग्ध चक्र शुरू होता है - जहां रहस्य तक पहुंच के लिए रहस्य रखना है ।

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

अवितो में हाशीकॉर्प वॉल्ट

Avito में, HashiCorp पूरे नेटवर्क पर एकमात्र बड़ी स्थापना में स्थापित है। HashiCorp वॉल्ट में कई अलग-अलग बैकेंड हैं। हम कंसूल के आधार पर बैकएंड का उपयोग हाशीकॉर्प से भी करते हैं, क्योंकि वॉल्ट केवल कॉन्सल के माध्यम से अपनी गलती सहनशीलता का समर्थन कर सकता है।

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

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

यहाँ अब हम तिजोरी में क्या स्टोर करते हैं:

• Kubernetes microservices के लिए लगभग सभी रहस्य: डेटाबेस पासवर्ड, एपीआई कुंजी, उपरोक्त सभी।
• "लोहा" सर्वर और एलएक्ससी पर बिछाने के लिए रहस्य।
• हम तिजोरी में टीमकिट में CI / CD बिल्ड के लिए सीक्रेट्स भी डालते हैं। कवरेज 100% नहीं है, लेकिन काफी स्वीकार्य है।
• सभी प्रमाणपत्रों की कुंजी: आंतरिक PKI, बाहरी CA, उदाहरण के लिए, GeoTrust और पसंद।
• टीमों के लिए सामान्य रहस्य।

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

हम फाइलों के रूप में रहस्यों को देने की कोशिश करते हैं।

हम डेवलपर को नहीं बताते: "तिजोरी में जाओ, एक रहस्य लो!", लेकिन फ़ाइल को डिस्क पर रखें और कहें: "डेवलपर, एक फ़ाइल आपकी डिस्क पर दिखाई देगी, उससे रहस्य ले लो, और हम पहले ही पता लगाएंगे कि वॉल्ट से कैसे प्राप्त करें और इसे लाएं। आप को। "


हमने JSON क्षेत्रों के लिए एक सरल समझौता अपनाया, जिसमें हम फ़ाइल को अपलोड करने के अधिकार के साथ संकेत देते हैं। यह फ़ाइल सिस्टम के लिए मेटाडेटा है, और डेटा फ़ील्ड गुप्त के साथ एक एन्कोडेड स्ट्रिंग है, जो फ़ाइल की सामग्री बन जाएगी।

कठपुतली + हिरा + तिजोरी

लगभग सभी एविटो इन्फ्रास्ट्रक्चर कठपुतली का उपयोग करता है, यह सभी सर्वरों को रोल आउट करता है।

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

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

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


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

कठपुतली में एक नए रहस्य का खुलासा करने की हमारी प्रक्रिया में निम्नलिखित चरण हैं।

• हम कहीं न कहीं एक रहस्य लेते हैं - कोई इसे हमें देता है या इसे बाहर रखता है।
• तिजोरी में एक रहस्य रखना, पदानुक्रम के साथ जैसे कि हिरा में: /puppet/role/www/site.ssl.key ।
• हम कठपुतली मेनिफेस्ट में एक उपसर्ग दर्ज करते हैं, यह दर्शाता है कि फ़ाइल वॉल्ट में है और इसे कहां प्राप्त करना है।
• हम हिलेरा राउटर और बैकएंड के लिए यमल्टी में वॉल्ट में पथ लिखते हैं ताकि हिरे इसे पा सकें।
• प्रकट रिपॉजिटरी के लिए जीआईटी के माध्यम से अनुरोध करें।
• रन या Puppet एजेंट के चलने की प्रतीक्षा करें।

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

एक अतिरिक्त प्लस हमें "चिप" हिरा मिलता है - रहस्य को मेजबानों के समूह के लिए या मेजबान की भूमिका के आधार पर तुरंत रखा जा सकता है , जिसे हम चर भूमिका में सेट करते हैं।

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

एक जादूगर के बिना SCM के साथ क्या करना है?

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

स्थानीय एजेंट

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

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

विपक्ष:

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

ट्रांजिट एन्क्रिप्शन

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

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

एक खामी भी है - प्रत्येक व्यवस्थापक को रहस्यों तक पहुंच मिलती है । लेकिन एक ऑडिट है: वॉल्ट जानता है कि एक गतिविधि कैसे रखी जाए, जिसके बारे में उपयोगकर्ता आए, वे किस रहस्य को पढ़ते हैं, किसको एक्सेस मिला। आप हमेशा जानते हैं कि किसने, कब और क्या एक रहस्य के साथ किया। यह विकल्प मुझे अच्छा लगता है।

बड़ा फंदा # १

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


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

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

यह सबसे बड़ी समस्याओं में से एक है। मुझे पता है कि इसे कैसे हल किया जाए, मैं आपको इसके बारे में बाद में बताऊंगा।

Kubernetes

RIT ++ में, मैंने एक अलग प्रणाली के बारे में बात की जिसे हमने कुबेरनेट्स के लिए लागू किया था : यह एक तीसरे पक्ष के रूप में कार्य करता है, एपीआई पर जाता है, पहुंच की जांच करता है और फिर तिजोरी में एक गुप्त अनुरोध करता है।

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

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

कुबेरनेट्स नियम

सेवा नाम और अतिरिक्त मेटाडेटा के संदर्भ में, हम डेवलपर्स पर भरोसा करते हैं। एक छोटा सा मौका है कि डेवलपर्स गलती से या जानबूझकर अन्य सेवाओं के रहस्यों को प्राप्त कर सकते हैं जो एक नाम स्थान में घूमते हैं, इसलिए हमने एक नियम पेश किया: एक सेवा - एक नाम स्थान।

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

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

कुबेरनेट्स डिलीवरी

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


पहला वितरण विकल्प।

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

डेवलपर को केवल उस मार्ग को याद रखने की आवश्यकता है जिसमें उसका रहस्य निहित है।

हम कुछ इस तरह उपसर्ग का उपयोग करें:

/k8s/<cluster>/<namespace>/<service>/some_secret 

उपसर्ग नाम में क्लस्टर नाम, नाम स्थान और सेवा नाम शामिल हैं। प्रत्येक सेवा का अपना रहस्य है, प्रत्येक नामस्थान का अपना रहस्य है।

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

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

हमारा एंट्रीपॉइंट init-container के समान है: यह वॉल्ट में एक सर्विस अकाउंट टोकन के साथ जाता है, रहस्य लेता है और उन्हें बाहर रखता है। फ़ाइलों के अलावा, वह उन्हें पर्यावरण में वापस रखता है। आपको बारह फैक्टर ऐप कॉन्सेप्ट द्वारा सुझाई गई एप्लिकेशन को चलाने का अवसर मिलता है: एप्लिकेशन वातावरण सहित सभी सेटिंग्स को रहस्य से लेता है।

प्रकट और डैशबोर्ड में पर्यावरण चर दिखाई नहीं देते हैं, क्योंकि वे स्टार्टअप पर PID 1 (मुख्य कंटेनर प्रक्रिया) द्वारा निर्धारित किए गए हैं। ये परिनियोजन से पर्यावरण चर नहीं हैं। सत्य, लेकिन प्रक्रिया में प्रविष्टि बिंदु द्वारा निर्धारित पर्यावरण चर हैं। वे डैशबोर्ड में दिखाई नहीं दे रहे हैं, वे दिखाई नहीं दे रहे हैं, भले ही आप कुबेटेल को एक कंटेनर में निष्पादित करते हैं, क्योंकि इस मामले में एक और प्रक्रिया लॉन्च की जाती है, पीआईडी ​​1 के समानांतर।

कार्यप्रवाह

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

डेवलपर इंतजार कर रहा है, और यह बुरा है, क्योंकि उसके लिए मुख्य चीज समय-समय पर बाजार है। फिर वह निर्देश पढ़ता है, लंबी फाइलों से संबंधित है - "उस लाइन को वहां डालें, इस लाइन को यहां डालें"। एक डेवलपर ने पहले कभी भी एक इन्टि-कंटेनर शुरू नहीं किया है, लेकिन वह इसे बाहर निकालने और इसे तैनाती में पंजीकृत करने के लिए मजबूर है ।yaml (helm चार्ट)।

Commit -> deploy -> feel pain -> fix -> repeat

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

मूल रूप से, डेवलपर अपनी गलतियों के कारण ग्रस्त है: गलत तरीके से निर्दिष्ट इनिट-कंटेनर या प्रलेखन नहीं पढ़ा ।

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

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

कुबेरनेट रहस्य के साथ स्पष्ट मुद्दे।

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

हम कहते हैं: “आपको देव क्लस्टर में उत्पादन रहस्यों की आवश्यकता क्यों है? एक परीक्षण रहस्य प्राप्त करें, इसके साथ जाओ! " नतीजतन, ऐसी खदानें और रहस्य हैं जिन्हें प्रबंधित करना मुश्किल है। यदि रहस्य बदल गया है, तो आपको इसके बारे में नहीं भूलना चाहिए, इसे हर जगह बदलना होगा, और जबकि यह निर्धारित करने का कोई तरीका नहीं है कि यह सेवा के नाम के अलावा, एक ही रहस्य है।

विचार: कुबेरनेट्स केएमएस

Kubernetes के नए संस्करणों में, KMS सबसिस्टम, कुंजी प्रबंधन सेवा, एक नया Kubernetes गुप्त एन्क्रिप्शन सुविधा है। V1.11 में यह अल्फा अवस्था में था, v1.12 में इसे बीटा में स्थानांतरित कर दिया गया था।

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

केएमएस का अर्थ एक एकल दोष को खत्म करना है - आदि में अनएन्क्रिप्टेड डेटा स्टोरेज।

KMS, जैसे कि Ansible, ऐसा कर सकता है।

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

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

कंस KMS।

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

केएमएस के पेशेवरों।

• कुबेरनेट्स में मूल समर्थन , जिसमें पर्यावरण दिखाते समय छिपाना भी शामिल है।
• जिम्मेदारी के कुबेरनेट्स क्षेत्र में प्राधिकरण ।
• वस्तुतः कोई तिजोरी समर्थन की जरूरत है ।
• बॉक्स के बाहर कुंजी रोटेशन ।

सीआई / सीडी: टीमसिटी

TeamCity में सब कुछ सरल है, क्योंकि JetBrains ने एक प्लग-इन लिखा है जो स्वयं गुप्त तक पहुंचने के लिए रहस्यों को लिख सकता है, उन्हें TeamCity के साथ एन्क्रिप्ट कर सकता है, और फिर इसे टेम्पलेट में कहीं पर प्रतिशत में स्थानापन्न कर सकता है। इस समय, टीमसिटी एजेंट स्वयं वॉल्ट में जाता है, गुप्त लेता है और इसे एक पैरामीटर के रूप में बिल्ड पर लाता है।

तैनाती के दौरान कुछ रहस्यों की आवश्यकता होती है, उदाहरण के लिए, डेटाबेस माइग्रेशन या स्लैक में अलर्ट। प्रत्येक प्रोजेक्ट के लिए AppRole शुरू किया गया है - सेटिंग्स में एक गुप्त (AppRole के लिए डेटा) भी शामिल है, लेकिन इसे केवल-लेखन मोड में दर्ज किया गया है - TeamCity इसे बाद में पढ़ने की अनुमति नहीं देता है।

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

सीआई / सीडी टीमसिटी नहीं है?

ये विचार करने के लिए मुख्य मुद्दे हैं कि क्या आप सीआई के रूप में एक अलग सिस्टम (टीमकिटी नहीं) का उपयोग कर रहे हैं।

• अलगाव: किसी परियोजना, टीम आदि के लिए एक रहस्य का दायरा सीमित करता है।
• कौन रहस्य तक पहुंच को अधिकृत करता है।
• अधिकृत पार्टी के रहस्य को देखने की क्षमता को छोड़ दें।
• बिल्ड का एक अलग चरण गुप्त को फाइलों में आयात करना है।
• अपने आप को साफ करें।

नतीजतन, सबसे अधिक संभावना है कि आप अपने CI / CD के लिए TeamCity प्लगइन के समान कुछ लिखेंगे। यहां अधिकृत पार्टी सबसे अधिक सीआई / सीडी होने की संभावना होगी, और यह वह होगी जो यह तय करेगी कि इस निर्माण में इस रहस्य तक पहुंच हो सकती है या नहीं, और परिणाम के आधार पर खुद को गुप्त देना है या नहीं।

यह महत्वपूर्ण है कि विधानसभा के अंत में निर्माण परिणामों को साफ करने के लिए मत भूलना, अगर उन्हें डिस्क पर रखा गया था, या यह सुनिश्चित करने के लिए कि वे केवल स्मृति में हैं।

प्रमाणपत्र

प्रमाण पत्र के साथ कुछ खास नहीं है - हम तिजोरी का उपयोग मुख्य रूप से उनके भंडारण के लिए करते हैं।


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

सारांश

सुरक्षा गार्ड के लिए बहुत अधिक मैनुअल काम , डेवलपर के लिए बहुत अधिक प्रवेश सीमा, और कोई बिल्ट-इन डेलिगेशन टूल नहीं है, हालांकि मैं चाहता हूं ...

कैसे हो? फिर सपने शुरू होते हैं।

विचार: बेहतर कैसे करें

मैं एक रहस्य की प्रतियों के एक समूह से कैसे छुटकारा पा सकता हूं?

डिलीवरी मास्टर-गुलाम

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

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

स्वामित्व प्राधिकरण

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

जब हम प्रतिनिधि बनाना सीखते हैं, तो हम मालिक को एक रहस्य का अधिकार देंगे, और वह गुप्त के साथ वह कर पाएगा जो वह चाहता है।

• K8s में फैला हुआ - एक नीति बनाई जाती है, एक दास प्रतिलिपि बनाई जाती है।
• सर्वर पर फैल - एक नीति उत्पन्न होती है, एक दास प्रतिलिपि बनाई जाती है।
• CI / CD में फैला - ...
• किसी अन्य स्वामी को स्थानांतरित करें।
• नई एक्सेस दें, नए ACL जनरेट करें।

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

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

ACL टेम्प्लेट के माध्यम से प्रतिनिधिमंडल

तिजोरी में एक्सेस कंट्रोल लिस्ट एक्सेस पॉलिसी को दो भागों में विभाजित किया गया है:

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

अभी, केवल वॉल्ट एडमिनिस्ट्रेटर ही ACL को बदल सकता है। इस तरह के एसीएल तक पहुँच प्राप्त करने के बाद, आप अपने अंदर की हर चीज को लिख सकते हैं, उदाहरण के लिए, path “*” { capabilities = [sudo, ...] } , और पूर्ण पहुँच प्राप्त करें। यह सबसे बड़ा दोष # 1 का सार है - ACL की सामग्री को बदलने पर रोक लगाना असंभव है ।

हम एसीएल को एक तैयार किए गए टेम्पलेट के साथ सेट करना चाहते हैं जिसमें पथ और प्लेसहोल्डर हैं, जिस पर इस टेम्पलेट के लिए नए एसीएल उत्पन्न करने की अनुमति है।

उदाहरण

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


हम / k8s तक पहुंच को प्रत्यायोजित करना चाहते हैं, हम केवल ऐसे टेम्पलेट उत्पन्न करने की अनुमति देते हैं। उदाहरण के लिए, किसी विशिष्ट क्लस्टर, नामस्थान, सेवा पर केवल पढ़ने के लिए पहुँच दें, लेकिन क्षमताओं के क्षेत्र को न बदलें।


इसके अतिरिक्त, हम इन ACL को बांधने और विभिन्न अधिकारों को जारी करने की अनुमति देना चाहते हैं।

हमने डेवलपर को अधिकार प्रदान करने के लिए टेम्पलेट लागू किया है। $ vault write policy-mgr/create/k8s-microservice ... , उन्होंने $ vault write policy-mgr/create/k8s-microservice ... । और नतीजतन, हमें एक एसीएल मिला जो क्लस्टर = ठेस, नाम स्थान = ..., सेवा = ... आदि बताता है। अधिकार स्वचालित रूप से सेट किए गए थे, नाम /k8s/some-srv के साथ एक नीति बनाई गई थी - यह सिर्फ ACL नाम है जिसे टेम्पलेट से उत्पन्न किया जा सकता है।


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

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

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

डरो मत कि आप मुख्य वॉल्ट में कुछ तोड़ देंगे। एक प्लगइन एक अलग सेवा है। यहां तक ​​कि अगर आपका प्लगइन घबरा गया और दुर्घटनाग्रस्त हो गया, तो उसने वॉल्ट के काम को नहीं छोड़ा। वॉल्ट बस प्लगइन को पुनरारंभ करेगा और काम करना जारी रखेगा।

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

उपयोगी लिंक:

• www.vaultproject.io
• github.com/jovandeginste/hiera-router
• github.com/jsok/hiera-vault
• www.owasp.org/index.php/Security_Champions
• blog.jetbrains.com/teamcity/2017/09/vault
• github.com/oracle/kubernetes-vault-kms-plugin

हम DevOps और सुरक्षा, CI / CD, k8s, कठपुतली और उन सभी के बारे में बात करेंगे जो HighLoad ++ (अप्रैल में सेंट पीटर्सबर्ग में सबसे नज़दीकी) और DevOpsConf में हैं । अपना अनुभव साझा करें या दूसरों को देखें। भूलने के लिए, ब्लॉग और समाचार पत्र की सदस्यता न लें, जिसमें हम आपको समय सीमा की याद दिलाएंगे और उपयोगी सामग्री एकत्र करेंगे।