प्रॉम्प्ट और संदर्भ
एक प्लेटफ़ॉर्म टीम को उसी आइडेंटिटी को Kubelet debug या exec एंडपॉइंट्स तक एक्सेस दिए बिना kube-apiserver को नोड मेट्रिक्स पढ़ने की अनुमति देनी होगी। क्लस्टर मोटे (coarse) ऑथराइज़ेशन व्यवहार से Kubernetes v1.36 में अपग्रेड हो रहा है, जिसमें कोई मॉनिटरिंग आउटेज नहीं होना चाहिए, नोड-स्तरीय विशेषाधिकार विस्तार नहीं होना चाहिए, और ऑडिट करने योग्य साक्ष्य होने चाहिए। ऑथेंटिकेशन पाथ, ऑथराइज़ेशन एट्रिब्यूट्स, माइग्रेशन, रोलबैक और वैलिडेशन मेट्रिक्स की व्याख्या करें।
इंटरव्यूअर क्या मूल्यांकन करता है
- केवल RBAC पर चर्चा करने के बजाय Kubelet HTTPS एंडपॉइंट ऑथेंटिकेशन को ऑथराइज़ेशन से अलग करना।
- verb, resource, subresource, node और namespace एट्रिब्यूट्स के साथ न्यूनतम विशेषाधिकार (least privilege) को व्यक्त करना।
- यह समझना कि API Server की Kubelet क्लाइंट आइडेंटिटी को स्पष्ट ऑथराइज़ेशन नियमों की आवश्यकता होती है।
- कम्पैटिबिलिटी माइग्रेशन, फ़ेल-क्लोज़्ड (fail-closed) व्यवहार, ऑडिटेबिलिटी और रोलबैक को डिज़ाइन करना।
पूछे जाने वाले स्पष्टीकरण प्रश्न
- किन कॉलर्स को Kubelet API की आवश्यकता है: केवल API Server, मॉनिटरिंग एजेंट्स, या सीधे नोड्स से कनेक्ट होने वाले ऑपरेटर्स?
- किन क्षमताओं की आवश्यकता है: metrics, logs, रनिंग-कंटेनर स्टेट, कमांड निष्पादन (command execution), या पोर्ट फ़ॉरवर्डिंग?
- क्या Kubelet क्लाइंट सर्टिफिकेट या किसी अन्य ऑथेंटिकेशन विधि का उपयोग करता है, और क्या API Server ऑथराइज़ेशन कॉलबैक उपलब्ध है?
- क्या रोलआउट के दौरान कुछ समय के लिए केवल-पढ़ने योग्य (read-only) गिरावट स्वीकार्य है, और मॉनिटरिंग आउटेज बजट क्या है?
30-सेकंड उत्तर फ़्रेमवर्क
पाथ को तीन लेयर्स में विभाजित करें: TLS या कोई अन्य ऑथेंटिकेटर कॉलर आइडेंटिटी स्थापित करता है, Kubelet ऑथराइज़र अनुरोध को एट्रिब्यूट्स में मैप करता है, और एक ऑथराइज़ेशन सर्विस निर्णय लेती है। debug, exec और proxy क्षमताओं को अलग करते हुए, केवल आवश्यक नोड एंडपॉइंट्स पर न्यूनतम-विशेषाधिकार नियम लागू करें। कॉल्स की सूची बनाकर, अस्वीकृतियों (denials) का अवलोकन करके, बैचों में नियमों को कड़ा करके और मेट्रिक्स और रोलबैक स्विच तैयार होने के बाद ही लागू अस्वीकृति (enforced denial) पर स्विच करके माइग्रेट करें।
चरण-दर-चरण गहन विश्लेषण
1. ऑथेंटिकेशन, ऑथराइज़ेशन और अनुरोध एट्रिब्यूट्स
Kubelet HTTPS एंडपॉइंट पहले एक क्लाइंट सर्टिफिकेट या कॉन्फ़िगर किए गए ऑथेंटिकेटर को मान्य करता है और एक यूज़रनेम और ग्रुप्स प्राप्त करता है। ऑथराइज़ेशन HTTP अनुरोध को Kubernetes एट्रिब्यूट्स जैसे verb, resource, subresource, namespace, name और node में मैप करता है। ऑथेंटिकेशन की सफलता का अर्थ ऑथराइज़ेशन नहीं है; प्रत्येक एंडपॉइंट को एक निर्णय की आवश्यकता होती है। जब API Server Kubelet को कॉल करता है, तो --kubelet-client-certificate और मिलान वाली कुंजी एक नियंत्रित प्रिंसिपल की पहचान करती है जिसके पास ऑथराइज़ेशन सिस्टम में स्पष्ट अनुमतियां होनी चाहिए।
2. सब-रिसोर्स के साथ न्यूनतम विशेषाधिकार व्यक्त करें
Metrics, logs, कंटेनर स्टेट और डिबग निष्पादन को अलग-अलग क्षमताओं के रूप में मानें। केवल आवश्यक रीड-ओनली नोड रिसोर्स या सब-रिसोर्स प्रदान करें और नोड के दायरे (node scope) को सीमित करें। केवल मॉनिटरिंग को काम करने के लिए वाइल्डकार्ड रिसोर्स या व्यापक nodes/proxy एक्सेस न दें। कमांड निष्पादन, पोर्ट फ़ॉरवर्डिंग और डिबग एंडपॉइंट्स को अलग-अलग उच्च-जोखिम वाली भूमिकाएं (high-risk roles) दें जो API Server की सामान्य सर्विस आइडेंटिटी से जुड़ी नहीं हैं।
3. माइग्रेशन और कम्पैटिबिलिटी
वर्तमान ऑडिट और एक्सेस लॉग से एक कॉल मैट्रिक्स बनाएं: identity, path, verb, target node, result और caller version। फ़ाइन-ग्रेन्ड ऑथराइज़ेशन सक्षम करने के बाद, एक अवलोकन चरण (observation phase) चलाएं जो कलेक्शन को बाधित किए बिना संभावित अस्वीकृतियों को रिकॉर्ड करता है, केवल आवश्यक नियमों को भरता है, और बैचों में नोड्स को स्विच करता है। KubeletFineGrainedAuthz Kubernetes v1.36 में GA है और डिफ़ॉल्ट रूप से सक्षम है, लेकिन रोलआउट को अभी भी डिस्ट्रीब्यूशन डिफ़ॉल्ट्स, API Server क्लाइंट क्रेडेंशियल्स और प्रत्येक मॉनिटरिंग कंपोनेंट के पाथ को सत्यापित करना चाहिए।
4. ऑब्जर्वेबिलिटी, रोलबैक और डिफेंस इन डेप्थ
Identity, node, resource और reason के साथ अनुमतियों (allows) और अस्वीकृतियों (denials) दोनों के लिए ऑडिट इवेंट्स रिकॉर्ड करें। ऑथराइज़ेशन लेटेंसी, डिनायल रेट, मेट्रिक कलेक्शन की सफलता और अप्रत्याशित एंडपॉइंट एक्सेस की निगरानी करें। यदि रोलआउट मॉनिटरिंग को बाधित करता है, तो पहले क्लाइंट अनुमतियों को रोलबैक करें या उच्च-जोखिम वाले एंडपॉइंट्स को बंद रखते हुए अस्थायी रूप से एक कम्पैटिबिलिटी नियम पुनर्स्थापित करें। नेटवर्क कंट्रोल्स को अभी भी Kubelet पोर्ट की पहुंच को सीमित करना चाहिए; ऑथराइज़ेशन TLS, नेटवर्क आइसोलेशन या नोड आइडेंटिटी सुरक्षा का स्थान नहीं लेता है।
मॉडल उत्तर
मैं पहले Kubelet एंडपॉइंट ऑथेंटिकेटर को सत्यापित करूंगा, फिर प्रत्येक अनुरोध को मानक ऑथराइज़ेशन एट्रिब्यूट्स में मैप करूंगा। API Server एक नियंत्रित क्लाइंट सर्टिफिकेट का उपयोग करता है, और ऑथराइज़ेशन सिस्टम न्यूनतम विशेषाधिकार के लिए verb, resource, subresource, node और namespace का मूल्यांकन करता है। मेट्रिक्स कलेक्शन को केवल आवश्यक रीड-ओनली क्षमता प्राप्त होती है। exec, पोर्ट फ़ॉरवर्डिंग और डिबग एंडपॉइंट्स अलग-अलग उच्च-जोखिम वाली भूमिकाओं का उपयोग करते हैं; वाइल्डकार्ड अनुमतियां और व्यापक nodes/proxy एक्सेस सामान्य API Server आइडेंटिटी से नहीं जुड़े हैं।
माइग्रेशन के चार चरण हैं: कॉल मैट्रिक्स की सूची बनाना; कलेक्शन को बाधित किए बिना अस्वीकृतियों का अवलोकन करना; नोड और कंपोनेंट बैचों में न्यूनतम नियम जोड़ना; फिर रोलबैक स्विच के साथ लागू अस्वीकृति (enforced denial) लागू करना। KubeletFineGrainedAuthz v1.36 में GA है और डिफ़ॉल्ट रूप से सक्षम है, लेकिन मैं डिस्ट्रीब्यूशन सेटिंग्स, API Server क्रेडेंशियल्स और मॉनिटरिंग वर्ज़न को सत्यापित करूंगा। ऑडिट रिकॉर्ड्स आइडेंटिटी, नोड, रिसोर्स, रिजल्ट और रीज़न को बनाए रखते हैं, जबकि नेटवर्क पॉलिसी Kubelet पोर्ट्स को प्रतिबंधित करना जारी रखती है ताकि ऑथराइज़ेशन, ट्रांसपोर्ट और नेटवर्क कंट्रोल्स एक साथ काम कर सकें।
सामान्य गलतियाँ
- TLS ऑथेंटिकेशन कॉन्फ़िगर करना और यह मान लेना कि एक क्लाइंट सर्टिफिकेट प्रत्येक Kubelet API की अनुमति देता है।
- मॉनिटरिंग को ठीक करने के लिए वाइल्डकार्ड रिसोर्स या व्यापक
nodes/proxyअनुमतियों का उपयोग करना। - बिना कॉल मैट्रिक्स के अस्वीकृति लागू करना, जिससे अपग्रेड के बाद बैकग्राउंड में कलेक्शन विफलताएं (silent collection failures) होती हैं।
- API Server और ऑपरेटर डिबगिंग के लिए एक ही उच्च-विशेषाधिकार भूमिका का पुन: उपयोग करना।
- Kubelet पोर्ट एक्सपोज़र और ऑडिट अलर्ट की अनदेखी करते हुए केवल ऑथराइज़ेशन नियमों पर निर्भर रहना।
फ़ॉलो-अप प्रश्न और उत्तर
फ़ॉलो-अप 1: मॉनिटरिंग आइडेंटिटी को सीधे nodes/proxy क्यों न दें?
nodes/proxy API Server के माध्यम से नोड एंडपॉइंट्स तक पहुंच की अनुमति देता है और यह मेट्रिक रीड्स से कहीं अधिक कवर कर सकता है। वास्तविक अनुरोध पाथ की पुष्टि करें और ठोस रिसोर्स या सब-रिसोर्स अनुमतियां दें। यदि किसी कार्यान्वयन की बाधा के कारण प्रॉक्सी एक्सेस की आवश्यकता होती है, तो एक समर्पित आइडेंटिटी को नोड स्कोपिंग और ऑडिट अलर्ट के साथ जोड़ें।
फ़ॉलो-अप 2: आप कैसे साबित करेंगे कि अपग्रेड ने विशेषाधिकारों का विस्तार नहीं किया?
बदलाव से पहले और बाद के कॉल मैट्रिक्स और ऑथराइज़ेशन निर्णयों की तुलना करें, जिसमें नए verbs, resources, subresources और node scope पर ध्यान केंद्रित किया जाए। डिनायल डेल्टास का विश्लेषण करें, फिर सिंथेटिक अनुरोधों का उपयोग करके यह साबित करें कि मेट्रिक्स पठनीय बने हुए हैं जबकि exec अस्वीकृत रहता है। इन जांचों को रिलीज़ गेट्स बनाएं।
फ़ॉलो-अप 3: यदि ऑथराइज़ेशन सर्विस अनुपलब्ध हो तो क्या होगा?
एक स्पष्ट फ़ेल-क्लोज़्ड (fail-closed) नीति चुनें ताकि कॉलबैक विफलता एक अनुमति (allow) न बन सके। व्यावसायिक बजट के आधार पर, एक संक्षिप्त रीड-ओनली कैश रखें या कलेक्शन को रोक दें, लेकिन मेट्रिक्स को पुनर्स्थापित करने के लिए उच्च-जोखिम वाले एंडपॉइंट्स न खोलें। अलर्ट भेजें और कॉलबैक ठीक होने के बाद पुन: सत्यापन करें।