सिस्टम डिज़ाइन इंटरव्यू: आप फेडेरेटेड SPIFFE वर्कलोड आइडेंटिटी कैसे डिज़ाइन करेंगे?

समस्या और संदर्भ

एक कंपनी दो क्लाउड्स और एक प्राइवेट क्लस्टर में मल्टी-टेनेंट माइक्रोसर्विसेज चलाती है। अलग-अलग टीमें प्रत्येक एनवायरनमेंट को ऑपरेट करती हैं, और प्रोडक्शन को स्टेजिंग से अलग रखा जाना चाहिए। एक पेमेंट्स सर्विस एक रिपोर्टिंग सर्विस को कॉल करती है, लेकिन लंबे समय तक चलने वाले (long-lived) API सीक्रेट्स और क्लाउड-विशिष्ट रोल्स को इमेजिस में कॉपी नहीं किया जा सकता है। ट्रस्ट डोमेन्स के बीच फेडेरेटेड वर्कलोड आइडेंटिटी डिज़ाइन करें।

वर्कलोड्स को कम समय के लिए मान्य (short-lived), सत्यापन योग्य पहचान (identities) की आवश्यकता होती है। प्राप्तकर्ताओं (recipients) को केवल स्वीकृत बाहरी ट्रस्ट डोमेन्स, SPIFFE IDs, ऑडियंस और व्यावसायिक कार्रवाइयों (business actions) पर भरोसा करना चाहिए। SPIFFE ID नेमिंग, SPIRE Server और Agent, नोड और वर्कलोड अटेस्टेशन, X.509-SVID या JWT-SVID, फॉरेन-बंडल रिट्रीवल, ऑथराइजेशन मैपिंग, रोटेशन, रिवोकेशन, कैशिंग, डिजास्टर रिकवरी और स्टैटिक क्रेडेंशियल्स से माइग्रेशन को कवर करें।

इन इनवेरिएंट्स (invariants) को बनाए रखें:

1. आइडेंटिटी सोर्स यह साबित करता है कि कौन सी नियंत्रित प्रक्रिया (controlled process) चल रही है, न कि केवल यह कि मशीन के पास एक नेटवर्क एड्रेस है।
2. एक ट्रस्ट-डोमेन बंडल स्वचालित रूप से प्रत्येक बाहरी वर्कलोड को स्थानीय अधिकार (local authority) नहीं देता है।
3. एक प्राप्तकर्ता घोषित सीमा (declared bound) के भीतर समाप्त (expired) या रद्द (revoked) किए गए SVID को स्वीकार करना बंद कर देता है।
4. प्राइवेट कीज़ वर्कलोड या एक नियंत्रित की-मैनेजर द्वारा जनरेट की जाती हैं; कंट्रोल प्लेन लंबे समय तक चलने वाली प्राइवेट कीज़ वितरित नहीं करता है।
5. फेडरेशन आइडेंटिटी और ट्रस्ट मटेरियल का आदान-प्रदान करता है; रिसोर्स सर्विस अभी भी व्यावसायिक ऑथराइजेशन निष्पादित करती है।

इंटरव्यूअर क्या मूल्यांकन कर रहा है

एक मजबूत उत्तर ट्रस्ट डोमेन, SPIFFE ID, SVID, SPIRE Server, Agent और Workload API के बीच स्पष्ट सीमाएं खींचता है। SPIFFE आइडेंटिटी नेमिंग और सत्यापन योग्य दस्तावेज़ों को परिभाषित करता है; SPIRE नोड और वर्कलोड अटेस्टेशन और SVID जारी करने की प्रक्रिया को लागू करता है। आइडेंटिटी अनुमति (permission) नहीं है: spiffe://prod.example/ns/payments/sa/worker को अभी भी रिपोर्टिंग सर्विस पर एक अनुमति नीति (allow policy) की आवश्यकता होती है।

दूसरा संकेत फेडरेशन है। SPIFFE Federation एक कॉन्फ़िगर और TLS-प्रमाणीकृत बंडल एंडपॉइंट के माध्यम से सार्वजनिक ट्रस्ट सामग्री का आदान-प्रदान करता है। एक प्राप्तकर्ता को पता होना चाहिए कि URL किस ट्रस्ट डोमेन का प्रतिनिधित्व करता है; उसे किसी रिक्वेस्ट से किसी मनमाने डोमेन के लिए रूट डाउनलोड नहीं करना चाहिए। Workload API फॉरेन बंडल्स वापस कर सकता है, और एक वेरिफायर SVID के ट्रस्ट डोमेन से मेल खाने वाले बंडल का चयन करता है।

तीसरा संकेत प्रूफ चेन (proof chain) है। नोड अटेस्टेशन Agent के नोड को साबित करता है, और वर्कलोड अटेस्टेशन रजिस्ट्रेशन सिलेक्टर्स के खिलाफ विश्वसनीय कर्नेल, kubelet, या कंटेनर-रनटाइम विशेषताओं का मिलान करता है। चोरी हुए सर्विस क्रेडेंशियल के खिलाफ केवल एक नेमस्पेस, लेबल या स्वयं-दावा की गई क्लाइंट आइडेंटिटी पर्याप्त नहीं है।

अंत में, संचालन (operations) पर चर्चा करें: एक एक्सपायर्ड फेडरेशन बंडल, रूट-की रोटेशन, एक डिस्कनेक्ट किया गया Agent, बासी (stale) कैश, एक कंट्रोल-प्लेन सिंगल पॉइंट ऑफ़ फेलियर, क्लाउड्स के बीच क्लॉक स्क्यू, लेगेसी सर्विसेज जो SVIDs लोड नहीं कर सकती हैं, और वेरिफिकेशन को अक्षम किए बिना रोलबैक।

पहले स्पष्ट करने योग्य प्रश्न

• किन ट्रस्ट डोमेन्स को वास्तव में विश्वास की आवश्यकता है? यदि पेमेंट्स केवल रिपोर्ट्स को कॉल करता है, तो पूरी तरह से मेश्ड (meshed) ट्रस्ट ग्राफ न बनाएं; एकतरफा या न्यूनतम एज (edge) को परिभाषित करें।
• X.509-SVID या JWT-SVID? mTLS और कनेक्शन आइडेंटिटी लंबे समय तक चलने वाले सर्विस लिंक्स के लिए उपयुक्त हैं; क्रॉस-क्लाउड HTTP या बाहरी OIDC रिसोर्सेज को एक JWT ऑडियंस की आवश्यकता हो सकती है। उनके वैलिडेशन कैश और लीक विंडो भिन्न होते हैं।
• फॉरेन बंडल एंडपॉइंट को कौन ऑपरेट करता है? एक ही कंपनी गवर्नेंस साझा कर सकती है; एक अलग कंपनी को स्पष्ट सार्वजनिक सामग्री, TLS आइडेंटिटी और समीक्षित डोमेन मैपिंग की आवश्यकता होती है।
• रिवोकेशन का लक्ष्य क्या है? उदाहरण के लिए, अधिकतम 15 मिनट का SVID लाइफटाइम, 60-सेकंड की बंडल पोलिंग, और आपातकालीन रिवोकेशन के बाद नए कनेक्शन्स को पांच मिनट में ब्लॉक करना।
• वर्कलोड खुद को कैसे साबित करता है? Kubernetes ServiceAccount, एक क्लाउड इंस्टेंस डॉक्यूमेंट, TPM, और एक नियंत्रित वन-टाइम जॉइन टोकन की अलग-अलग मान्यताएं (assumptions) होती हैं।
• क्या लेगेसी सर्विसेज SPIFFE का उपभोग कर सकती हैं? यदि नहीं, तो क्या कोई साइडकार या गेटवे सीमित तरीके से अनुवाद कर सकता है? उसकी आइडेंटिटी और अनुमतियों को अपनी सीमा की आवश्यकता होती है।

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

"मैं प्रोडक्शन, स्टेजिंग और ऑन-प्रेमिस के लिए स्वतंत्र ट्रस्ट डोमेन बनाऊंगा और स्थिर SPIFFE IDs असाइन करूंगा जिनमें कोई टेनेंट सीक्रेट न हो। प्रत्येक डोमेन का SPIRE Server रजिस्ट्रेशन एंट्रीज का स्वामित्व रखता है। एक Agent अपने नोड को साबित करता है, फिर वर्कलोड अटेस्टेशन के लिए स्थानीय प्रोसेस विशेषताओं का उपयोग करता है; वर्कलोड Workload API से एक शॉर्ट-लिव्ड X.509-SVID या JWT-SVID प्राप्त करता है।

पेमेंट्स डोमेन केवल रिपोर्टिंग डोमेन के फॉरेन बंडल एंडपॉइंट को कॉन्फ़िगर करेगा और डोमेन, TLS आइडेंटिटी और अनुमत मैपिंग को पिन करेगा। रिपोर्टिंग सिग्नेचर, SVID समाप्ति, ऑडियंस और पीयर बंडल को मान्य करती है, फिर पूर्ण SPIFFE ID, एनवायरनमेंट, टेनेंट संदर्भ और कार्रवाई को ऑथराइज़ करती है। बंडल और SVID अपडेट स्ट्रीमिंग APIs, छोटे TTLs और वर्जन मेट्रिक्स का उपयोग करते हैं। यदि कंट्रोल प्लेन अनुपलब्ध है, तो बाउंडेड पहले से सत्यापित सामग्री कम जोखिम वाले ट्रैफ़िक की सेवा कर सकती है, लेकिन उच्च जोखिम वाले नए कनेक्शन्स फेल-क्लोज्ड (fail closed) होते हैं। माइग्रेशन पुराने क्रेडेंशियल्स और SVIDs को समानांतर में चलाता है, सर्विस पूल द्वारा कैनरी करता है, और ऑडिट और रिवोकेशन लक्ष्यों के साबित होने के बाद ही सीक्रेट्स को हटाता है।"

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

चरण 1: ट्रस्ट डोमेन्स को विभाजित करें और पहचानों को नाम दें

एक ट्रस्ट डोमेन एक आइडेंटिटी नेमस्पेस और रूट-ऑफ़-ट्रस्ट सीमा है। प्रोडक्शन, स्टेजिंग, PCI एनवायरनमेंट्स, या अलग से शासित संगठनों को एक वैश्विक रूट के बजाय अलग-अलग डोमेन का उपयोग करना चाहिए। एक ID इस प्रकार हो सकती है:

spiffe://prod.example/ns/payments/sa/worker
spiffe://reports.partner/ns/analytics/sa/reader

पाथ को एक स्थिर व्यावसायिक प्रिंसिपल और गवर्नेंस स्कोप को व्यक्त करना चाहिए, न कि पॉड नाम, IP, या शॉर्ट-लिव्ड परिनियोजन (deployment) हैश को। वर्जन, टेनेंट और रीजन सिलेक्टर्स, पॉलिसी इनपुट्स या टोकन क्लेम्स हो सकते हैं। ID में प्रत्येक डिप्लॉयमेंट को एनकोड करने से रोटेशन और ऑथराइजेशन का रखरखाव पूरे फ्लीट के माइग्रेशन में बदल जाता है।

फेडरेशन को स्पष्ट किनारों (edges) के रूप में रिकॉर्ड करें: prod.example, reports.partner के बंडल को मान्य कर सकता है, लेकिन केवल ऑडियंस reports-api और एक्शन ReportRead के लिए। एक प्राप्तकर्ता को केवल इसलिए कॉल की अनुमति नहीं देनी चाहिए क्योंकि दोनों डोमेन SPIFFE का उपयोग करते हैं।

चरण 2: Server, Agent और रजिस्ट्रेशन एंट्रीज स्थापित करें

SPIRE Server रजिस्ट्रेशन एंट्रीज, साइनिंग मटेरियल और नोड ऑथराइजेशन को स्टोर करता है। एक Agent प्रत्येक वर्कलोड नोड पर चलता है और स्थानीय Workload API को एक्सपोज़ करता है। Server एक Agent को केवल वही एंट्रीज भेजता है जिन्हें प्रबंधित करने के लिए Agent ऑथराइज़्ड है, जिससे एक नोड के खतरे में पड़ने पर प्रभाव का दायरा (blast radius) सीमित हो जाता है।

एक प्रविष्टि को एक SPIFFE ID, पैरेंट SPIFFE ID, सिलेक्टर सेट, अनुमत SVID प्रोफ़ाइल और ऑडियंस को बांधना चाहिए। सिलेक्टर्स एक विश्वसनीय ऑर्केस्ट्रेटर या नोड प्रॉपर्टी से आते हैं: Kubernetes नेमस्पेस, सर्विस अकाउंट, इमेज डाइजेस्ट, या क्लाउड इंस्टेंस आइडेंटिटी। केवल यूजर द्वारा संपादन योग्य लेबल्स पर भरोसा न करें या किसी मनमानी कॉन्फ़िगरेशन स्ट्रिंग को अटेस्टेशन साक्ष्य के रूप में न मानें।

चरण 3: टू-स्टेज अटेस्टेशन डिज़ाइन करें

नोड स्टार्टअप पर, Agent क्लाउड इंस्टेंस डॉक्यूमेंट, Kubernetes ServiceAccount, TPM, या वन-टाइम जॉइन टोकन के साथ अपनी पहचान साबित करता है। Server स्वतंत्र रूप से प्रमाण को मान्य करता है और Agent आइडेंटिटी जारी करता है। वर्कलोड तब यूनिक्स डोमेन सॉकेट या प्रतिबंधित एंडपॉइंट के माध्यम से Workload API को कॉल करता है। Agent सिलेक्टर्स प्राप्त करने के लिए प्रोसेस ID, कर्नेल, kubelet, या कंटेनर-रनटाइम तथ्यों का उपयोग करता है, रजिस्ट्रेशन एंट्रीज से मिलान करता है, और एक SVID लौटाता है।

यह बताता है कि Workload API को सामान्य नेटवर्क क्लाइंट ऑथेंटिकेशन का उपयोग करने की आवश्यकता क्यों नहीं है: Agent एक स्थानीय कॉलर को आउट-ऑफ़-बैंड पहचानता है। सॉकेट अनुमतियाँ, नेमस्पेस आइसोलेशन, और होस्ट कर्नेल या kubelet में विश्वास थ्रेट मॉडल का हिस्सा हैं। यदि Agent कॉलर की पहचान नहीं कर सकता है, तो उसे डिफ़ॉल्ट उच्च-विशेषाधिकार वाली पहचान के बजाय PermissionDenied लौटाना चाहिए।

चरण 4: एक SVID प्रोफ़ाइल चुनें और कीज़ को संभालें

X.509-SVID mTLS और कनेक्शन-स्तरीय सर्विस आइडेंटिटी के लिए उपयुक्त है। JWT-SVID HTTP या बाहरी OIDC एक्सचेंज के लिए उपयुक्त है जहाँ एक audience को असर्शन के साथ यात्रा करनी चाहिए। एक JWT-SVID वेरिफायर को सब्जेक्ट ट्रस्ट डोमेन के लिए बंडल का उपयोग करना चाहिए; एक मनमाना JWKS समान रूट ऑफ़ ट्रस्ट नहीं है।

SVIDs शॉर्ट-लिव्ड होने चाहिए और Workload API के माध्यम से स्ट्रीम किए जाने चाहिए। वर्कलोड या एक Agent की-मैनेजर प्राइवेट की जनरेट करता है और इसे प्रतिबंधित मेमोरी या फ़ाइल डिस्क्रिप्टर में रखता है। Server संबंधित पब्लिक की पर हस्ताक्षर करता है लेकिन कभी भी एक लंबी अवधि की प्राइवेट की को इमेज, एनवायरनमेंट वेरिएबल, या सामान्य कॉन्फ़िगरेशन में नहीं लिखता है। कई पहचानों वाला वर्कलोड आंतरिक और बाहरी ऑडियंस के लिए एक hint या स्पष्ट चयन का उपयोग कर सकता है ताकि डिफ़ॉल्ट का दुरुपयोग न हो सके।

चरण 5: क्रॉस-डोमेन बंडल फेडरेशन सुरक्षित रूप से स्थापित करें

फेडरेशन कंट्रोल प्लेन विदेशी डोमेन, बंडल एंडपॉइंट, एंडपॉइंट प्रोफ़ाइल, TLS प्रमाणपत्र और अनुमत SPIFFE ID उपसर्ग (prefix) की समीक्षा करता है। एक क्लाइंट को पहले से पता होता है कि URL किस ट्रस्ट डोमेन का प्रतिनिधित्व करता है। TLS ऑथेंटिकेशन ट्रांसपोर्ट एंडपॉइंट को साबित करता है; लौटाए गए बंडल को अभी भी डोमेन, वर्जन, सिग्नेचर और समाप्ति जांच की आवश्यकता होती है।

एक फॉरेन बंडल को वर्जन किए गए ट्रस्ट स्टोर में स्टोर करें। पीयर वैलिडेशन के दौरान, SVID के ट्रस्ट डोमेन द्वारा बंडल का चयन करें; मेल न खाने पर अस्वीकार करें। किसी फॉरेन बंडल को स्थानीय जारी करने वाला रूट (local issuing root) न बनाएं, और अस्थायी रीडायरेक्ट के कारण कॉन्फ़िगरेशन को स्थायी रूप से न बदलें। पोलिंग, ETags, समाप्ति और अंतिम सफल संस्करण अवलोकनीय (observable) होने चाहिए।

चरण 6: आइडेंटिटी को रिसोर्स ऑथराइजेशन से मैप करें

रिपोर्टिंग सर्विस का PEP mTLS पीयर या JWT-SVID को सत्यापित करता है, फिर पूर्ण SPIFFE ID, ट्रस्ट डोमेन, ऑडियंस, टेनेंट और एक्शन को एक PDP को भेजता है। एक उदाहरण नियम है:

allow if trust_domain == "prod.example"
   and spiffe_id == "spiffe://prod.example/ns/payments/sa/worker"
   and audience == "reports-api"
   and action == "ReportRead"
   and tenant == resource.tenant

नेटवर्क पहुंच, मान्य SVIDs, और एक फेडरेशन एज व्यावसायिक अनुमति का गठन नहीं करते हैं। रिसोर्स सर्विस अभी भी टेनेंट ओनरशिप, रो-लेवल एक्सेस, अप्रूवल्स और रेट लिमिट्स की जांच करती है। यदि किसी वर्कलोड आइडेंटिटी को क्लाउड IAM या किसी बाहरी OIDC सर्विस तक पहुँचना है, तो ऑडियंस, स्कोप, SVID TTL और उद्देश्य से बंधे एक प्रतिबंधित ब्रोकर का उपयोग करें; कभी भी प्रत्येक वर्कलोड को एक व्यापक क्लाउड रोल न सौंपें।

चरण 7: रोटेशन, रिवोकेशन और कैश निरंतरता का समन्वय करें

SVID समाप्ति को Workload API स्ट्रीम्स के माध्यम से संभाला जाता है। क्लाइंट्स परमाणु रूप से (atomically) सर्टिफिकेट्स और कीज़ को बदलते हैं और नए कनेक्शन्स को पहले नई सामग्री का उपयोग करने देते हैं। ट्रस्ट-बंडल रोटेशन पुराने और नए रूट्स के बीच बाउंडेड ओवरलैप का उपयोग करता है; पुराने रूट को तभी हटाएं जब वेरिफायर्स ने नया संस्करण लोड कर लिया हो और पुराने SVIDs और कनेक्शन्स ड्रेन हो गए हों। एक आपातकालीन स्थिति (emergency compromise) सामान्य ओवरलैप का उपयोग नहीं करती है; एक रिवोकेशन या डिनाई वर्जन प्रकाशित करें और स्वीकृति विंडो को छोटा करें।

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

चरण 8: स्केल, विफलता और माइग्रेशन की योजना बनाएं

SPIRE Server संसाधन उपयोग रजिस्ट्रेशन एंट्रीज के साथ बढ़ता है, और एक इंस्टेंस विफलता का बिंदु (failure point) है। क्षेत्र या ट्रस्ट डोमेन द्वारा शार्ड करें, HA के लिए कई Servers का उपयोग करें, प्रत्येक Agent को प्राप्त होने वाली प्रविष्टियों को सीमित करें, और जारी करने की लेटेंसी, Agent काउंट, एंट्री काउंट, Workload API रिक्वेस्ट्स और बंडल लैग की निगरानी करें। पूरी तरह से मेश्ड फेडरेशन ग्राफ से बचें; नियंत्रित किनारों या ब्रोकर्स का उपयोग करें।

जब कंट्रोल प्लेन अनुपलब्ध होता है, तो एक गैर-समाप्त (unexpired) SVID बाउंडेड कम जोखिम वाले मौजूदा कनेक्शन्स का समर्थन कर सकता है, लेकिन सिस्टम को हमेशा के लिए पहचान जारी नहीं करनी चाहिए। एक समाप्त हो चुका बंडल, विफल नोड प्रूफ, की-मैनेजर विफलता, या अज्ञात डोमेन मैपिंग को उच्च जोखिम वाले नए कनेक्शन्स के लिए फेल-क्लोज्ड होना चाहिए। स्टेटिक-सीक्रेट माइग्रेशन के दौरान, दोनों पाथ्स को चलाएं, सर्विस पूल द्वारा कैनरी करें, ऑडिट और रिवोकेशन को सत्यापित करें, और फिर पुराने सीक्रेट को हटा दें। रोलबैक एक अभी भी नियंत्रित पाथ पर वापस लौटता है, कभी भी अक्षम ऑथेंटिकेशन पर नहीं।

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

"मैं प्रोडक्शन, स्टेजिंग और पार्टनर एनवायरनमेंट्स को ट्रस्ट डोमेन्स में अलग करूंगा और वर्कलोड्स के लिए स्थिर SPIFFE IDs का उपयोग करूंगा। प्रत्येक SPIRE Server रजिस्ट्रेशन एंट्रीज और एक जारी करने वाले रूट का स्वामित्व रखता है। एक Agent अपने नोड को साबित करता है, फिर स्थानीय Workload API वर्कलोड अटेस्टेशन के लिए प्रोसेस और ऑर्केस्ट्रेटर विशेषताओं का उपयोग करता है। वर्कलोड्स mTLS के लिए शॉर्ट-लिव्ड X.509-SVIDs या एक निश्चित ऑडियंस के लिए JWT-SVIDs प्राप्त करते हैं; प्राइवेट कीज़ वर्कलोड, Agent, या नियंत्रित की-मैनेजर के पास रहती हैं।

पेमेंट्स और रिपोर्ट्स का एक समीक्षित फेडरेशन एज है। क्लाइंट एंडपॉइंट और डोमेन को पिन करता है और TLS, बंडल वर्जन और समाप्ति को मान्य करता है। पीयर वैलिडेशन SVID ट्रस्ट डोमेन द्वारा फॉरेन बंडल का चयन करता है और मेल न खाने पर अस्वीकार करता है। रिपोर्टिंग SVID, जारीकर्ता, ऑडियंस और समाप्ति को मान्य करती है, फिर पूर्ण SPIFFE ID, टेनेंट और कार्रवाई को ऑथराइज़ करती है। फेडरेशन सत्यापन सामग्री प्रदान करता है; यह व्यावसायिक अनुमति नहीं देता है।

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

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

• प्रत्येक क्लस्टर में एक ही ट्रस्ट डोमेन साझा करना। एक रूट या कॉन्फ़िगरेशन लीक हर एनवायरनमेंट तक पहुंच जाता है; गवर्नेंस और जोखिम के आधार पर डोमेन को विभाजित करें।
• एक SPIFFE ID को व्यावसायिक ऑथराइजेशन मानना। आइडेंटिटी यह बताती है कि 'कौन' है; रिसोर्स सर्विस अभी भी ऑडियंस, टेनेंट, एक्शन और ओनरशिप की जांच करती है।
• केवल नोड अटेस्टेशन करना। नोड पर एक दुर्भावनापूर्ण प्रक्रिया किसी सेवा का रूप ले सकती है; वर्कलोड सिलेक्टर्स का भी उपयोग करें।
• एक परिवर्तनीय (mutable) पॉड नाम या IP को लंबे समय तक चलने वाले प्रिंसिपल के रूप में उपयोग करना। पुनर्निर्माण (rebuilds) और गतिशीलता ऑथराइजेशन को तोड़ देती है; एक स्थिर ID और पॉलिसी सिलेक्टर्स का उपयोग करें।
• एक फेडरेशन URL को ट्रस्ट रूट मानना। डोमेन को पूर्व-कॉन्फ़िगर करें और TLS, बंडल सामग्री, वर्जन और समाप्ति को मान्य करें।
• फॉरेन बंडल से प्रत्येक बाहरी प्रिंसिपल को अनुमति देना। फेडरेशन सत्यापन सामग्री की आपूर्ति करता है; पॉलिसी को ID प्रीफिक्स, ऑडियंस, एक्शन और टेनेंट को प्रतिबंधित करना चाहिए।
• इमेजिस या एनवायरनमेंट वेरिएबल्स में लंबे समय तक चलने वाली प्राइवेट कीज़ डालना। प्रतियां उन्हें उजागर करती हैं; वर्कलोड या की-मैनेजर सीमा पर जनरेट और रोटेट करें।
• पुरानी बंडल्स या SVIDs को हमेशा के लिए स्वीकार करना। यह रिवोकेशन का उल्लंघन करता है; वर्जन्स, TTLs और कनेक्शन एज को ट्रैक करें और सीमा के बाद अस्वीकार करें।
• कंट्रोल-प्लेन आउटेज के दौरान डिफ़ॉल्ट-अनुमति (default-allowing) देना। अज्ञात पहचान को अधिकार प्राप्त नहीं होना चाहिए; बाउंडेड पुरानी सामग्री का उपयोग करें या जोखिम के आधार पर फेल-क्लोज्ड करें।
• ऑडिट और ऑथराइजेशन के बिना mTLS माइग्रेट करना। एन्क्रिप्शन व्यावसायिक अनुमति साबित नहीं करता है; पीयर ID, पॉलिसी वर्जन, टेनेंट और निर्णय रिकॉर्ड करें।

फॉलो-अप प्रश्न और उत्तर

यदि दो ट्रस्ट डोमेन्स को द्विदिश (bidirectional) संचार की आवश्यकता है, तो क्या दोनों को एक दूसरे के बंडल को इम्पोर्ट करना होगा?

जरूरी नहीं। यदि पेमेंट्स केवल रिपोर्ट्स को कॉल करता है, तो एकतरफा एज बनाएं: रिपोर्ट्स पेमेंट्स के फॉरेन बंडल पर भरोसा करती है, जबकि पेमेंट्स को रिपोर्ट्स पर भरोसा करने की आवश्यकता नहीं है। रिवर्स एज केवल तभी जोड़ें जब रिपोर्ट्स भी अलग ऑडियंस और नीतियों के साथ कॉल्स शुरू करती है। पारस्परिक विश्वास (mutual trust) पूर्ण अनुमति नहीं है।

सीधे क्लाउड प्रोवाइडर की वर्कलोड आइडेंटिटी का उपयोग क्यों न करें?

क्लाउड आइडेंटिटी एक क्लाउड कंट्रोल प्लेन के अंदर उपयोगी है, लेकिन मल्टी-क्लाउड, प्राइवेट और पार्टनर एनवायरनमेंट्स में अलग-अलग जारीकर्ता, SDKs और नीतियां होती हैं। SPIFFE पोर्टेबल नेमिंग, SVIDs और बंडल एक्सचेंज की आपूर्ति करता है। बाहरी क्लाउड IAM अभी भी एक प्रतिबंधित OIDC फेडरेशन ब्रोकर का उपयोग कर सकता है; SPIFFE व्यावसायिक ऑथराइजेशन को प्रतिस्थापित नहीं करता है।

क्या एक अनऑथेंटिकेटेड Workload API सुरक्षित है?

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

क्या होगा यदि कोई फॉरेन बंडल एंडपॉइंट अस्थायी रूप से अनुपलब्ध है?

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

लंबे समय तक चलने वाले कनेक्शन्स SVID रोटेशन और रिवोकेशन को कैसे संभालते हैं?

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

आप कैसे साबित करते हैं कि सिलेक्टर्स को जाली (forged) नहीं बनाया जा सकता है?

सिलेक्टर्स विश्वसनीय नोड या ऑर्केस्ट्रेटर APIs से आते हैं और Server या Agent द्वारा सत्यापित किए जाते हैं। यूजर-संपादन योग्य लेबल्स केवल संकेत हैं। इमेज डाइजेस्ट, सर्विस अकाउंट, नेमस्पेस, प्रोसेस प्रॉपर्टीज और नोड प्रूफ को मिलाएं, और रजिस्ट्रेशन परिवर्तनों का ऑडिट और अनुमोदन करें।

आप स्टैटिक-सीक्रेट माइग्रेशन को कैसे रोलबैक करते हैं?

पुराने सीक्रेट और SVID को समानांतर में स्वीकार करें, सर्विस पूल द्वारा SVID सक्षम करें, और दोनों पाथ्स के लिए सफलता, ऑथराइजेशन और रिवोकेशन रिकॉर्ड करें। विफलता पर नया जारी करना बंद करें और अभी भी नियंत्रित पुराने सीक्रेट पर वापस लौटें, फिर समस्या को ठीक करने के बाद कैनरी जारी रखें। रिटायरमेंट साक्ष्य और एक डिलीशन गेट परिभाषित करें; रोलबैक के रूप में प्रमाणीकरण को कभी भी अक्षम न करें।