प्रांप्ट और कार्यक्षेत्र
यह एक पहचान-इन्फ्रास्ट्रक्चर (identity-infrastructure) और बैकएंड विश्वसनीयता से जुड़ा प्रश्न है। Kubernetes ServiceAccounts API सर्वर या पहचान पर भरोसा करने वाले अन्य सिस्टम्स तक पहुँचने के लिए हस्ताक्षरित JWTs का उपयोग करते हैं। v1.36 में, बाहरी ServiceAccount टोकन साइनिंग स्थिर (stable) है, जिससे साइनिंग अनुरोध एक स्थानीय Unix डोमेन सॉकेट के माध्यम से API सर्वर से बाहर जा सकते हैं। इस डिज़ाइन को TokenRequest, पब्लिक की सत्यापन, रोटेशन और उच्च उपलब्धता सिमेंटिक्स को बनाए रखते हुए प्राइवेट की के जोखिम (exposure) को कम करना चाहिए।
साक्षात्कारकर्ता क्या मूल्यांकन करता है
- क्या आप केवल "KMS कनेक्ट करें" कहने के बजाय साइनिंग, जारी करने (issuance), सत्यापन और प्राधिकरण (authorization) को अलग करते हैं।
- क्या आप UDS/gRPC कनेक्शन व्यवहार, डेडलाइन्स, समवर्तीता (concurrency), पुनः प्रयास (retries), और फेल-क्लोज्ड हैंडलिंग को डिज़ाइन करते हैं।
- क्या आप ओवरलैपिंग कीज, JWT
kid, कैश और सत्यापनकर्ता रिफ्रेश को संभालते हैं। - क्या आप वैध अल्पकालिक (short-lived) टोकनों को समय से पहले रद्द किए बिना रोटेट और रोलबैक करते हैं।
- क्या आप ऑडिट, लेटेंसी, त्रुटि और की-उपयोग मेट्रिक्स को परिभाषित करते हैं।
पूछने के लिए स्पष्टीकरण प्रश्न
- टोकन TTL, ऑडियंस, जारी करने की QPS और API सर्वर रेप्लिकस की संख्या क्या है?
- क्या बाहरी साइनर HSM गारंटी, हेल्थ प्रोब्स, वर्ज़न की गई कीज और आइडेम्पोटेंसी IDs प्रदान करता है?
- सत्यापनकर्ता JWKS कैसे प्राप्त करते हैं, और रिफ्रेश विलंब व कैश TTL क्या हैं?
- जब साइनर अनुपलब्ध हो, तो क्या नए टोकनों को अस्वीकार किया जा सकता है, या क्या कोई नियंत्रित पुरानी-की फ़ॉलबैक व्यवस्था है?
- क्या रोटेशन के दौरान ऑफ़लाइन जॉब्स या क्लस्टर से बाहर के सिस्टम इन JWTs पर निर्भर हैं?
एक 30-सेकंड का उत्तर
"मैं इस पथ को TokenRequest प्राधिकरण, बाहरी साइनर को API-सर्वर कॉल्स, पब्लिक की वितरण और RBAC प्राधिकरण में विभाजित करूँगा। API सर्वर एक सुरक्षित Unix सॉकेट पर डेडलाइन, अनुरोध ID और सीमित पुनः प्रयासों के साथ साइनर को कॉल करता है; प्राइवेट की KMS या HSM के अंदर ही रहती है। रोटेशन के दौरान, नई पब्लिक की प्रकाशित करें और सत्यापनकर्ताओं को ओवरलैप के साथ रिफ्रेश करने दें, फिर नए kid के साथ जारी करें; पुराने टोकन का TTL समाप्त होने के बाद ही पुरानी की को रिटायर करें। यदि साइनर अनुपलब्ध है, तो अनपेक्षित रूप से असुरक्षित टोकन बनाने के बजाय नए जारी करने को अस्वीकार करें और अलर्ट भेजें। साइनिंग लेटेंसी, अस्वीकृति दर, सॉकेट त्रुटियां, की IDs और JWKS की आयु को मापें, और रोलबैक के लिए पुराने साइनर और की को बनाए रखें।"
चरण-दर-चरण गहन विश्लेषण
चरण 1: विश्वास और डेटा प्रवाह को परिभाषित करें
TokenRequest प्राधिकरण यह निर्धारित करता है कि कौन किस ServiceAccount और ऑडियंस के लिए टोकन का अनुरोध कर सकता है। अनुरोध को मान्य करने के बाद, API सर्वर JWT पेलोड को बाहरी साइनर को भेजता है; साइनर हस्ताक्षर लौटाता है और API सर्वर टोकन लौटाता है। API सर्वर अभी भी जारीकर्ता (issuer), ऑडियंस, समाप्ति (expiry), और RBAC सिमेंटिक्स का स्वामी है। बाहरी सिस्टम केवल नियंत्रित साइनिंग करता है और उसे अतिरिक्त अनुमतियां नहीं देनी चाहिए।
चरण 2: स्थानीय साइनर इंटरफ़ेस डिज़ाइन करें
प्रलेखित कॉन्फ़िगरेशन --service-account-signing-endpoint को एक Unix डोमेन सॉकेट पर इंगित करता है जहाँ एक वर्ज़न किया गया साइनिंग प्रोटोकॉल चल सकता है। सॉकेट अनुमतियों, डायरेक्टरी, प्रोसेस पहचान और SELinux या AppArmor नीतियों को केवल API सर्वर तक सीमित रखें। अनुरोध में की वर्ज़न, एल्गोरिदम, डाइजेस्ट या साइनिंग बाइट्स, अनुरोध ID और डेडलाइन शामिल करें; हस्ताक्षर, kid और एक ऑडिट सहसंबंध ID लौटाएं। कभी भी प्राइवेट कीज या पूरे टोकन को सामान्य लॉग में न रखें।
चरण 3: डेडलाइन्स, पुनः प्रयास और आइडेम्पोटेंसी को संभालें
साइनिंग एक लेटेंसी-संवेदनशील पथ है, इसलिए एक छोटी डेडलाइन और सीमित समवर्तीता का उपयोग करें। एक क्षणिक नेटवर्क या HSM विफलता के लिए सीमित पुनः प्रयास किए जा सकते हैं, लेकिन अनंत पुनः प्रयास API-सर्वर कतार को बढ़ा देंगे। अनुरोध IDs साइनर और API-सर्वर ऑडिट को सहसंबद्ध करते हैं; यदि प्रोटोकॉल आइडेम्पोटेंट कैशिंग का समर्थन करता है, तो डुप्लिकेट लेखांकन से बचा जा सकता है। टाइमआउट के बाद, एक स्पष्ट त्रुटि लौटाएं और नए जारी करने को अस्वीकार करें। क्या मौजूदा टोकन सत्यापित होते रहेंगे, यह पब्लिक कीज और समाप्ति नीति पर निर्भर करता है।
चरण 4: की रोटेशन और JWKS ओवरलैप डिज़ाइन करें
एक नई की बनाएं और साइनर को उसके नए kid का उपयोग करने की अनुमति दें, फिर JWKS में नई पब्लिक की प्रकाशित करें। सत्यापनकर्ताओं द्वारा रिफ्रेश करने के बाद, उस की के साथ नए टोकन जारी करें। सबसे लंबे टोकन TTL के साथ-साथ कैश और क्लॉक-स्क्यू विंडो तक पुरानी पब्लिक की को बनाए रखें। इसे केवल इसलिए न हटाएं क्योंकि जारीकर्ता ने स्विच कर लिया है। रोटेशन को रोकने योग्य (pausable), ऑडिट योग्य और प्रतिवर्ती (reversible) होना चाहिए।
चरण 5: रेप्लिकस और डिज़ास्टर रिकवरी को सुरक्षित रखें
प्रत्येक API-सर्वर रेप्लिका को सुसंगत की वर्ज़न्स और क्लॉक के साथ एक स्थानीय या अत्यधिक उपलब्ध साइनर तक पहुँचना चाहिए। एक केंद्रीकृत साइनर के लिए, क्रॉस-नोड नेटवर्क, विफलता डोमेन और ब्लास्ट रेडियस का आकलन करें। प्रति-नोड साइडकार्स के लिए, सुनिश्चित करें कि HSM कनेक्टिविटी और की वितरण में भिन्नता न आए। साइनर पुनरारंभ, अनुपलब्ध सॉकेट फ़ाइलों, HSM थ्रॉटलिंग, अनुपलब्ध JWKS और API-सर्वर रोलिंग अपग्रेड का परीक्षण करें।
चरण 6: सत्यापित करें, ऑडिट करें और रोलबैक करें
कैनरी API सर्वर पर कॉन्फ़िगरेशन सक्षम करें और TokenRequest जारीकर्ता, ऑडियंस, kid, समाप्ति और RBAC व्यवहार को सत्यापित करें। पुरानी और नई कीज, सत्यापनकर्ता प्रकारों और क्लॉक स्क्यू में एकीकरण परीक्षण चलाएं। साइनिंग p50/p95, विफलता के कारणों, सॉकेट लेटेंसी, HSM काउंट्स, JWKS आयु और टोकन अस्वीकृति दर को ट्रैक करें। पुरानी पब्लिक की को बनाए रखते हुए पुराने साइनर और की कॉन्फ़िगरेशन को पुनर्स्थापित करके रोलबैक करें; जब तक पुराने टोकन और ऑडिट विंडो समाप्त न हो जाएं, इसे न हटाएं।
उच्च-गुणवत्ता वाला नमूना उत्तर
"मैं बाहरी साइनर को एक संकीर्ण साइनिंग सीमा बनाऊँगा। API सर्वर अभी भी TokenRequest, जारीकर्ता, ऑडियंस, समाप्ति और RBAC को मान्य करता है, एक सुरक्षित Unix सॉकेट पर साइनर को कॉल करता है, और प्राइवेट की को केवल KMS या HSM में रखता है। अनुरोधों में वर्ज़न, kid, ID, डेडलाइन और सीमित पुनः प्रयास शामिल होते हैं; साइनर की विफलता नए टोकनों को अस्वीकार करती है और अलर्ट करती है। रोटेशन नए JWKS को प्रकाशित करता है, सत्यापनकर्ता रिफ्रेश की प्रतीक्षा करता है, नए kid पर स्विच करता है, और सबसे लंबे TTL, कैश और क्लॉक-स्क्यू विंडो के माध्यम से पुरानी की को बनाए रखता है। प्रत्येक रेप्लिका के पास सुसंगत स्थानीय-सॉकेट एक्सेस, की वर्ज़न्स और समय होना चाहिए। कैनरी लेटेंसी, अस्वीकृति दर, की-ID वितरण, JWKS आयु और RBAC एकीकरण की जांच करती है, जबकि रोलबैक पुराने साइनर और पब्लिक की को सुरक्षित रखता है।"
सामान्य गलतियाँ
- बाहरी साइनर को RBAC या ऑडियंस तय करने देना और उसकी ज़िम्मेदारी का विस्तार करना।
- प्राइवेट की को साइडकार या लॉग में कॉपी करना, जिससे सुरक्षा लाभ खत्म हो जाता है।
- रोटेशन के तुरंत बाद पुरानी पब्लिक की को हटाना और अभी भी वैध टोकनों को तोड़ना।
- साइनर टाइमआउट के लिए बिना किसी सीमा के पुनः प्रयास करना और API-सर्वर कतार को अभिभूत करना।
- JWKS कैश, क्लॉक स्क्यू और रेप्लिका निरंतरता के बजाय केवल सफल साइनिंग का परीक्षण करना।
- बिना ऑडिट सीमाओं के साइनर विफलता के दौरान मूक पुरानी-की जारी करने को एक विश्वसनीय फ़ॉलबैक के रूप में मानना।
अनुवर्ती प्रश्न और उत्तर
क्या साइनर डाउन होने पर API सर्वर स्थानीय पुरानी प्राइवेट की का उपयोग जारी रख सकता है?
केवल तभी जब स्पष्ट थ्रेट मॉडल, ऑडिट और रोलबैक योजना इसकी अनुमति देती है। डिफ़ॉल्ट रूप से नए जारी करने को अस्वीकार करना चाहिए ताकि सीक्रेट्स API सर्वर पर वापस न आएं। मौजूदा टोकन अपने TTL समाप्त होने तक पुरानी पब्लिक की के साथ सत्यापन जारी रख सकते हैं।
पुरानी पब्लिक की को हटाना कब सुरक्षित है?
सबसे लंबे टोकन TTL, सत्यापनकर्ता JWKS कैश TTL, अधिकतम क्लॉक स्क्यू और ऑफ़लाइन-उपभोक्ता प्रतिधारण से एक सुरक्षा विंडो की गणना करें, फिर सत्यापित करें कि पुराने-kid का उपयोग शून्य है। विंडो के बाद ही हटाएं और पहले एक पुनर्प्राप्त करने योग्य बैकअप बनाए रखें।
HTTP के बजाय Unix सॉकेट का उपयोग क्यों करें?
एक स्थानीय सॉकेट सुनने की सतह (listening surface) को संकीर्ण करता है और एक्सेस को नियंत्रित करने के लिए फ़ाइल अनुमतियों और होस्ट नीति का उपयोग करता है। यह अपने आप में प्रोटोकॉल प्रमाणीकरण, प्रोसेस अलगाव या उपलब्धता को हल नहीं करता है; वर्ज़न किए गए APIs, ऑडिट, डेडलाइन्स और विफलता अभ्यासों की अभी भी आवश्यकता है।