Kubernetes Secrets को KMS v2 से सुरक्षित करें—पुराने रहस्य फिर लिखें

Kubernetes Secrets को संग्रहण में सुरक्षित करने के लिए KMS v2 के आधिकारिक निर्देश के अनुसार संगत प्लगइन और एन्क्रिप्शन विन्यास एपीआई सर्वर पर लागू करें; यह तरीका Kubernetes 1.29 से स्थिर है और एटसीडी के तीसरे प्रमुख संस्करण की माँग करता है। फिर नया रहस्य बनाकर उसकी संग्रहित प्रविष्टि जाँचें और पहले से मौजूद सभी रहस्य दोबारा लिखें।

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

बदलाव से पहले पढ़ने और वापसी की तैयारी करें

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

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

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

प्लगइन और एन्क्रिप्शन विन्यास लगाएँ

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

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

पहले से एन्क्रिप्ट रहस्यों को पढ़ने के लिए उनका पुराना प्रदाता और सही कुंजी केएमएस के बाद रखें। खुले रूप में संग्रहित रहस्यों को पढ़ने के लिए पहचान प्रदाता सूची के अंत में रखें। उसे पहले रखने पर अगला लेखन खुले रूप में संग्रहित होगा; उसे अभी हटाने पर पहले से खुले रूप में रखे रहस्य पढ़ना बंद हो सकता है।

एपीआई सर्वर सक्रिय करें और नया लेखन जाँचें

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

केएमएस प्रदाता की स्वास्थ्य जाँच करें, फिर परीक्षण के लिए नया रहस्य बनाएँ। एटसीडी के आदेश-पंक्ति औज़ार से उसके नामस्थान और नाम वाली संग्रहित प्रविष्टि पढ़ें; अपने क्लस्टर का वास्तविक संग्रहण पथ और एटसीडी से जुड़ने के प्रमाणपत्र इस्तेमाल करें। एन्क्रिप्ट मान की शुरुआत ठीक k8s:enc:kms:v2: से होनी चाहिए और उसके बाद रहस्य का साफ पाठ नहीं दिखना चाहिए।

उसी रहस्य को एपीआई से पढ़कर पुष्टि करें कि प्लगइन उसे खोल भी पा रहा है। इस जाँच से नया लेखन और पठन परखा जाता है; पुराने रहस्यों पर इसका निष्कर्ष लागू नहीं होता। उनके संग्रहित प्रारूप की पुष्टि पुनर्लेखन के बाद अलग से करनी होगी।

मौजूदा रहस्य फिर लिखें और परिणाम जाँचें

सभी एपीआई सर्वरों पर नया विन्यास सक्रिय होने के बाद प्रशासकीय खाते से kubectl get secrets --all-namespaces -o json | kubectl replace -f - चलाएँ। यह आदेश मौजूदा रहस्यों को उनके डेटा में बदलाव किए बिना फिर लिखता है। लिखते समय सूची का पहला प्रदाता नया संग्रहित प्रारूप तय करता है, इसलिए आदेश चलाने से पहले उसका क्रम दोबारा देखें।

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

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

पहचान प्रदाता हटाना और वापसी

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

पहचान प्रदाता हटाने वाला विन्यास सभी एपीआई सर्वरों पर लागू करें और प्रत्येक पुनःआरंभ के बाद रहस्यों का पठन जाँचें। यदि नए लेखन या पठन में समस्या आए, तो ऐसी प्रदाता सूची बहाल करें जो पुराने और नए, दोनों प्रारूप पढ़ सके। केएमएस प्लगइन तथा उसकी कुंजी को वापसी पूरी होने तक उपलब्ध रखें।

यह भी पढ़ें:

• YouTube कमाई की दहलीज दोगुनी करेगा—पुराने YPP सदस्य फिलहाल सुरक्षित हैं
• Copyright जाँच हरी आई तो भी गीत सुरक्षित साबित नहीं होता
• Upwork पर हाथ से जोड़े घंटे सुरक्षित नहीं—समय ट्रैकर सही चलाएँ