सिस्टम डिज़ाइन इंटरव्यू: Kubernetes को KMS v2 पर कैसे माइग्रेट करें और साबित करें कि Secrets एन्क्रिप्टेड हैं?

प्रॉम्प्ट और दायरा

प्लेटफ़ॉर्म टीम को etcd में Secrets की सुरक्षा करनी होगी। क्लस्टर में कई kube-apiservers, एक बाहरी KMS प्लगइन और कई ऐतिहासिक ऑब्जेक्ट्स हैं, फिर भी माइग्रेशन के दौरान रिलीज़ रोकी नहीं जा सकतीं। कॉन्फ़िगरेशन, रोटेशन, रीराइट, सत्यापन, मॉनिटरिंग और रोलबैक डिज़ाइन करें।

इंटरव्यूअर क्या जांच रहा है

• KMS v2 एन्वेलप-एन्क्रिप्शन सीमा और DEK/KEK संबंध को समझना।
• एन्क्रिप्टेड नए राइट्स (writes) और रीराइट किए गए ऐतिहासिक ऑब्जेक्ट्स के बीच अंतर करना।
• एकाधिक apiservers, KMS आउटेज, रोटेशन और समवर्ती (concurrent) अपडेट्स को संभालना।
• केवल कॉन्फ़िग डिफ़ (diff) के बजाय etcd साक्ष्य और API रीड्स के साथ परिणाम साबित करना।

स्पष्टीकरण के लिए प्रश्न

1. कौन से Kubernetes और प्लगइन संस्करण और उच्च-उपलब्धता (high-availability) टोपोलॉजी तैनात हैं?
2. कस्टम संसाधन और ऑडिट लॉग सहित कौन से संसाधन सुरक्षित हैं?
3. बाहरी KMS क्या उपलब्धता, लेटेंसी, रोटेशन और डिजास्टर-रिकवरी गारंटी प्रदान करता है?
4. किस कंट्रोल-प्लेन विंडो, रोलबैक समय सीमा और अनुपालन साक्ष्य प्रारूप की आवश्यकता है?

30-सेकंड का उत्तर

गैर-उत्पादन (non-production) क्लस्टर में KMS v2 प्लगइन और अनुमतियों को मान्य करें। KMS को पहला प्रोवाइडर बनाएं, पुराने प्रोवाइडर को रीड फ़ॉलबैक के रूप में रखें, और प्रत्येक kube-apiserver को एक-एक करके रोल करें। नए राइट्स एन्क्रिप्ट हो जाते हैं, लेकिन ऐतिहासिक ऑब्जेक्ट्स के लिए नो-ऑप (no-op) अपडेट या स्टोरेज-वर्जन माइग्रेशन की आवश्यकता होती है। API रीड्स, etcd प्रीफिक्स, KMS मेट्रिक्स, विफलता अभ्यास (failure drills) और ऑडिट रिकॉर्ड्स को सत्यापित करें। पुराने प्रोवाइडर को केवल तभी हटाएं जब प्रत्येक ऑब्जेक्ट को रीराइट कर दिया गया हो और रोलबैक विंडो समाप्त हो गई हो।

चरण-दर-चरण डिज़ाइन

1. एन्क्रिप्शन मॉडल को परिभाषित करें

Kubernetes एन्वेलप एन्क्रिप्शन का उपयोग करता है: एक डेटा-एन्क्रिप्शन कुंजी (DEK) संसाधन की सुरक्षा करती है, जबकि एक कुंजी-एन्क्रिप्शन कुंजी (KEK) बाहरी KMS द्वारा सुरक्षित होती है। KMS v2 सर्वर-साइड कैशिंग और प्रति-apiserver DEK डिज़ाइन के साथ अनुरोध ओवरहेड को कम करता है, लेकिन यह प्रत्येक पुराने etcd मान को स्वचालित रूप से रीराइट नहीं करता है।

2. पहले प्लगइन और अनुमतियों को मान्य करें

एक अलग (isolated) क्लस्टर में सॉकेट, पहचान, टाइमआउट, रीस्टार्ट और KMS-अनुपलब्ध व्यवहार का परीक्षण करें। पुष्टि करें कि kube-apiserver पुराने प्रोवाइडर द्वारा लिखे गए ऑब्जेक्ट्स को डिक्रिप्ट कर सकता है और नए प्रोवाइडर के माध्यम से एक नया Secret लिख सकता है। लेटेंसी, त्रुटियां, कैश हिट और KMS कॉल वॉल्यूम रिकॉर्ड करें।

providers:
  - kms:
      apiVersion: v2
      name: external-kms
      endpoint: unix:///var/run/kms/plugin.sock
  - aescbc:
      keys:
        - name: old-key
          secret: <base64-secret>

3. उच्च-उपलब्धता कंट्रोल प्लेन को रोल करें

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

4. ऐतिहासिक ऑब्जेक्ट्स को फिर से लिखें (Rewrite)

प्रोवाइडर का क्रम बदलने से केवल भविष्य के राइट्स प्रभावित होते हैं। Secrets और अन्य संरक्षित संसाधनों के लिए बैच नो-ऑप अपडेट करें, या रीराइट ट्रिगर करने के लिए स्टोरेज-वर्जन माइग्रेशन का उपयोग करें; संघर्षों (conflicts) का पुनः प्रयास करें। नेमस्पेस द्वारा शार्ड करें, कार्य को दर-सीमित (rate-limit) करें, और ऑब्जेक्ट संस्करणों को रिकॉर्ड करें ताकि API सर्वर, etcd और KMS पर अत्यधिक भार न पड़े।

5. एन्क्रिप्शन साक्ष्य एकत्र करें

एक नया Secret बनाएं, etcd से इसके रॉ बाइट्स पढ़ें, और KMS v2 एन्क्रिप्शन प्रीफिक्स को सत्यापित करें; फिर इसे API के माध्यम से पढ़ें और प्लेनटेक्स्ट की तुलना करें। पुराने ऑब्जेक्ट्स और प्रत्येक संरक्षित संसाधन प्रकार का नमूना लें, जिनकी अभी तक रीराइट नहीं हुई है उनकी गणना करें। अकेले एक सफल API रीड यह साबित नहीं करता है कि डिस्क मान एन्क्रिप्टेड है।

6. रोटेट करें, विफलता का परीक्षण करें, और रोलबैक करें

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

मॉडल उच्च-गुणवत्ता वाला उत्तर

मैं KMS v2 प्लगइन, अनुमतियों, लेटेंसी और विफलता व्यवहार को अलग से मान्य करूंगा। प्रोडक्शन KMS v2 को पहले रखेगा, पढ़ने के लिए पुराने प्रोवाइडर को संक्षेप में बनाए रखेगा, और kube-apiservers को व्यक्तिगत रूप से रोल करेगा। एक बार नए राइट्स एन्क्रिप्ट हो जाने के बाद, मैं प्रगति, संघर्षों और पुनरावृत्तियों को रिकॉर्ड करते हुए, सीमित संसाधन और नेमस्पेस बैचों में ऑब्जेक्ट्स को फिर से लिखूंगा। साक्ष्य में API रीड्स, etcd प्रीफिक्स और नमूना लिए गए ऐतिहासिक ऑब्जेक्ट्स शामिल होंगे। कवरेज पूरा होने के बाद ही मैं पुराने प्रोवाइडर को हटाऊंगा। रोटेशन और KMS विफलता के लिए अभ्यास, थ्रेशोल्ड और एक स्कोप्ड रोलबैक की आवश्यकता होती है।

सामान्य गलतियाँ

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

अनुवर्ती प्रश्न और उत्तर

क्या KMS v2 कॉन्फ़िगर होने के बाद सभी नए Secrets सुरक्षित हैं?

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

क्या KMS अनुपलब्ध होने पर राइट्स जारी रह सकते हैं?

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

पुराने प्रोवाइडर को बनाए रखना स्थायी समाधान के बजाय एक जोखिम क्यों है?

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