प्रतिनिधि इंटरव्यू विषय

बैकएंड इंटरव्यू: आप W3C Baggage प्रोपेगेशन को सुरक्षित रूप से कैसे नियंत्रित (Govern) करेंगे?

बैकएंडकठिन
Offer.cc संपादकीय टीमप्रकाशित अपडेट किया गया

प्रश्न

कई माइक्रोसर्विस टेनेंट और एक्सपेरिमेंट संदर्भ (context) के लिए W3C Baggage का उपयोग करती हैं। एक प्रोपेगेशन गेटवे डिज़ाइन करें जो OpenTelemetry कोरिलेशन को खोए बिना संवेदनशील डेटा लीक को रोकता है।

प्रश्न और परिदृश्य

कई माइक्रोसर्विस टेनेंट, एक्सपेरिमेंट और रिक्वेस्ट-सोर्स संदर्भ के लिए W3C baggage हेडर का उपयोग करती हैं। कुछ सेवाएं कंपनी या डेटा-डोमेन सीमाओं को पार करती हैं, इसलिए OpenTelemetry कोरिलेशन बना रहना चाहिए, जबकि व्यक्तिगत डेटा और आंतरिक पहचानकर्ता (identifiers) अविश्वसनीय डाउनस्ट्रीम सिस्टम से बाहर रहने चाहिए।

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

  • Baggage को Trace Context से अलग करना और मनमाने की-वैल्यू (key-value) प्रोपेगेशन को पहचानना।
  • ब्लाइंड फ़ॉरवर्डिंग के बजाय ट्रस्ट-बाउंड्री अनुमति सूचियों (allowlists), साइज लिमिट्स, रेडैक्शन (redaction) और डिलीशन को लागू करना।
  • ऑब्जर्वेबिलिटी, कम्पैटिबिलिटी, ग्रेसफुल डिग्रेडेशन और ऑडिट एविडेंस को संतुलित करना।

उत्तर देने से पहले स्पष्ट करने वाले प्रश्न

स्पष्ट करें कि कौन सी सेवाएं एक ट्रस्ट डोमेन साझा करती हैं, अनुमत-फील्ड कैटलॉग, अधिकतम हेडर आकार, ब्राउज़र या कतार (queue) एंट्री पॉइंट, टेलीमेट्री रिटेंशन, और क्या डाउनस्ट्रीम सिस्टम Baggage को बनाए रखते हैं (persist करते हैं)। स्पष्ट करें कि क्या लक्ष्य संवेदनशील कुंजियों को ब्लॉक करना है, क्रॉस-डोमेन प्रोपेगेशन को प्रतिबंधित करना है, या कस्टम हेडर को माइग्रेट करना है।

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

मैं Baggage को अविश्वसनीय इनपुट के रूप में मानूँगा। इनग्रेस पर इसे पार्स और सामान्यीकृत (normalize) करें, फिर स्रोत, गंतव्य ट्रस्ट डोमेन और नीति (policy) के आधार पर फ़ील्ड को बनाए रखें, नाम बदलें, हैश करें या हटाएं। गेटवे की/वैल्यू और कुल आकार को सीमित करता है, कभी भी रॉ वैल्यू को लॉग या उपयोगकर्ता प्रतिक्रियाओं में कॉपी नहीं करता है, और क्रॉस-डोमेन इग्रेस पर एक अनुमति सूची (allowlist) प्लस पॉलिसी वर्शन का उपयोग करता है। Traceparent को स्वतंत्र रूप से संभाला जाता है। यदि फ़िल्टरिंग विफल हो जाती है, तो वैकल्पिक फ़ील्ड छोड़ दें, मुख्य अनुरोध जारी रखें, और एक ऑडिट योग्य नीति कार्रवाई रिकॉर्ड करें।

चरण-दर-चरण विस्तृत उत्तर

  1. एक वर्शनयुक्त फ़ील्ड कैटलॉग बनाए रखें: उद्देश्य, डेटा वर्ग, अनुमत स्रोत और गंतव्य डोमेन, अधिकतम लंबाई और लॉगिंग अनुमति।
  2. इनग्रेस पर मानक प्रारूप को पार्स करें और अमान्य कुंजियों, नियंत्रण वर्णों, बड़े आकार के मूल्यों और डुप्लिकेट संघर्षों को अस्वीकार करें। संवेदनशील हेडर के बजाय केवल एक रिक्वेस्ट डाइजेस्ट रखें।
  3. एक ही ट्रस्ट डोमेन के भीतर एक अनुमति सूची का प्रचार (propagate) करें। डोमेन के पार केवल न्यूनतम सार्वजनिक कुंजियां, या एक अपरिवर्तनीय टेनेंट उपनाम (alias) या अल्पकालिक हस्ताक्षरित संदर्भ (short-lived signed reference) भेजें।
  4. OpenTelemetry इंजेक्शन पॉइंट्स पर स्पष्ट फ़िल्टरिंग जोड़ें ताकि स्वचालित इंस्ट्रूमेंटेशन हर Baggage आइटम को स्पैन, लॉग या मीट्रिक विशेषताओं में कॉपी न कर सके।
  5. कुल बाइट्स, आइटम संख्या और हॉप संख्या सीमित करें। ओवरफ्लो होने पर, कम प्राथमिकता वाले फ़ील्ड हटा दें और संवेदनशील डेटा को प्रतिध्वनित (echo) किए बिना एक आंतरिक नीति इवेंट उत्सर्जित करें।
  6. प्रत्येक इग्रेस पर नीति का पुनर्मूल्यांकन करें; कतारों और अतुल्यकालिक (asynchronous) कार्यों के लिए कैटलॉग का पुन: उपयोग करें। प्राधिकरण क्रेडेंशियल (authorization credential) के रूप में कभी भी Baggage का उपयोग न करें।
  7. मूल मान के बजाय फ़ील्ड नाम, नीति संस्करण, कार्रवाई और गंतव्य का ऑडिट करें। सिंथेटिक लीकेज, आकार हमलों और मल्टी-हॉप संचय का परीक्षण करें।
text
incoming baggage: tenant=acme,experiment=A,pii_email=alice@example.org
same-trust output: tenant=acme,experiment=A
cross-trust output: tenant_ref=hash:v3:...,experiment=A

उच्च-गुणवत्ता वाला नमूना उत्तर

मैं पहले यह कहूँगा कि Baggage कोई प्रमाणीकरण (authentication) या प्राधिकरण वाहक नहीं है; प्रत्येक मान अविश्वसनीय है। एक वर्शनयुक्त फ़ील्ड कैटलॉग इनग्रेस पर पार्सिंग और सीमाओं को संचालित करता है, और अनुमति सूचियां समान-डोमेन प्रोपेगेशन को नियंत्रित करती हैं। ट्रस्ट सीमाओं के पार केवल एक न्यूनतम उपनाम या अल्पकालिक संदर्भ भेजें। OpenTelemetry ट्रेस संदर्भ को अलग से संभालें, स्वचालित इंजेक्शन को फ़िल्टर करें, और कभी भी रॉ मान लॉग न करें। ओवरफ्लो या अज्ञात नीति पर, वैकल्पिक फ़ील्ड छोड़ दें, मुख्य अनुरोध जारी रखें, और फ़ील्ड नाम, कार्रवाई और नीति संस्करण रिकॉर्ड करें। मल्टी-हॉप सिंथेटिक परीक्षण, कतार-सीमा परीक्षण और ऑडिट क्वेरी यह सत्यापित करते हैं कि गोपनीयता जोखिम को एक स्वस्थ ट्रेस के पीछे छिपाए बिना कम किया गया है।

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

  • Baggage को विश्वसनीय पहचान, प्राधिकरण या टेनेंट अलगाव (isolation) के रूप में मानना।
  • ट्रस्ट सीमाओं के पार मनमानी कुंजियों की अनुमति देना या केवल एक स्ट्रिंग ब्लैकलिस्ट पर निर्भर रहना।
  • पूरे हेडर को लॉग, ट्रेस या एरर रिस्पॉन्स में लिखना।
  • HTTP को नियंत्रित करना लेकिन कतारों, पुनः प्रयासों (retries) और अतुल्यकालिक कार्यों को भूल जाना।
  • वैकल्पिक ओवरफ्लो के लिए 4xx वापस करना, या ऑडिट इवेंट के बिना चुपचाप डेटा छोड़ना।

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

Baggage और Trace Context में क्या अंतर है?

Trace Context डिस्ट्रीब्यूटेड ट्रेसिंग के लिए आवश्यक मानक मेटाडेटा वहन करता है। Baggage एक एप्लिकेशन-परिभाषित की-वैल्यू सेट है जो स्वतंत्र रूप से काम कर सकता है, इसलिए इसके सिमेंटिक्स और गोपनीयता जोखिम एप्लिकेशन के अंतर्गत आते हैं।

ब्लैकलिस्ट की तुलना में अनुमति सूची (allowlist) को प्राथमिकता क्यों दें?

Baggage कुंजियों का कोई निश्चित व्यावसायिक सिमेंटिक्स नहीं होता है और समय के साथ नए फ़ील्ड दिखाई देते हैं। एक अनुमति सूची डिफ़ॉल्ट रूप से अज्ञात डेटा को अस्वीकार करती है, जिससे किसी नई सेवा या विक्रेता द्वारा गलती से संवेदनशील मान फैलाने से रोका जा सकता है।

क्या फ़िल्टरिंग विफलता से अनुरोध अवरुद्ध (block) होना चाहिए?

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

आप कैसे साबित करते हैं कि रॉ मान टेलीमेट्री में प्रवेश नहीं करते हैं?

Collector और SDK दोनों पर रेडैक्शन परीक्षण चलाएं, लॉग, स्पैन विशेषताओं और मीट्रिक लेबल को स्कैन करें, मानों के बजाय नाम और नीति संस्करण रिकॉर्ड करें, और सिंथेटिक कैनरी पर अलर्ट सेट करें।

सार्वजनिक स्रोत

संबंधित प्रश्न