सिस्टम डिज़ाइन इंटरव्यू: आप Kubernetes ऑडिट पॉलिसी और एक विश्वसनीय लॉग पाइपलाइन को कैसे डिज़ाइन करेंगे?

प्रांप्ट और कार्यक्षेत्र (Scope)

एक मल्टी-टेनेंट क्लस्टर को API-सर्वर मेमोरी, लॉगिंग लागत, और Secret लीकेज को नियंत्रित करते हुए यह जवाब देना चाहिए कि किसने, क्या, कब और कहाँ से बदलाव किया। ऑडिट पॉलिसी, फ़ाइल या वेबहुक बैकएंड, सैंपलिंग और अलर्ट, विफलता प्रबंधन (failure handling), और फोरेंसिक सत्यापन को डिज़ाइन करें।

इंटरव्यूअर क्या परीक्षण कर रहा है

• क्रमित नियमों (ordered rules) और None, Metadata, Request, और RequestResponse के बीच के अंतर को समझना।
• RequestReceived, ResponseStarted, और ResponseComplete चरणों में अंतर करना।
• लंबे समय तक चलने वाले अनुरोधों (long-lived requests), संवेदनशील बॉडीज़, बैकएंड ब्लॉकिंग, और लॉग अखंडता (integrity) को संभालना।
• ऑडिट लक्ष्यों को अलर्ट, अवधारण (retention), एक्सेस नियंत्रण और ड्रिल्स से जोड़ना।

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

1. किन उच्च-जोखिम वाले संसाधनों, क्रियाओं (verbs), टेनेंट्स और प्रिंसिपल्स का ऑडिट किया जाना चाहिए?
2. किन बॉडीज़ में Secrets, टोकन या व्यक्तिगत डेटा शामिल हैं, और उन्हें कितने समय तक बनाए रखा जाना चाहिए?
3. क्या बैकएंड एक फ़ाइल, वेबहुक, या दोनों होना चाहिए, और डेटा हानि और विलंबता (latency) की कौन सी विंडो स्वीकार्य है?
4. क्या छेड़छाड़ का प्रमाण (tamper evidence), क्रॉस-रीजन प्रतिकृति (cross-region replication), और अप्रसंस्कृत लॉग (raw-log) तक सीमित पहुंच आवश्यक है?

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

जांच से जुड़े प्रश्नों को फ़ील्ड्स और उच्च-जोखिम वाले APIs से मैप करें, फिर नियमों को विशिष्ट से सामान्य (catch-all) के क्रम में रखें। अधिकांश ट्रैफ़िक के लिए Metadata, चयनित परिवर्तनों के लिए Request, और RequestResponse का संयम से उपयोग करें ताकि Secret मान सामान्य लॉग में न जाएं। शुरुआती चरणों को केवल तभी छोड़ें जब इसका कारण स्पष्ट हो। बफरिंग, दर सीमा (rate limits), एन्क्रिप्शन, अखंडता जांच, एक्सेस ऑडिट और हानि अलर्ट के साथ फ़ाइल या TLS वेबहुक बैकएंड को सुरक्षित करें। चुने गए सेमेंटिक्स को साबित करने के लिए बैकएंड विफलताओं की ड्रिल करें।

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

1. फोरेंसिक प्रश्न को परिभाषित करें

किसने, कब, कहाँ, और क्या को फ़ील्ड्स और प्रश्नों में बदलें। उच्च-जोखिम वाली वस्तुओं में Secrets, RoleBindings, वेबहुक, नोड्स और टेनेंट कोटा शामिल हैं; नियमित स्वास्थ्य जांचों (health checks) को शायद ही कभी पूरी बॉडी की आवश्यकता होती है। पॉलिसी को जांच के प्रश्नों का उत्तर देना चाहिए, न कि हर संभव फ़ील्ड को एकत्र करना चाहिए।

2. क्रमित नियम लिखें

नियमों को विशिष्ट से सामान्य (catch-all) के क्रम में रखें; पहला मिलान स्तर निर्धारित करता है। उच्च-जोखिम वाले परिवर्तनों के लिए Request या आवश्यक RequestResponse का उपयोग करें, नियमित रीड्स के लिए Metadata, स्पष्ट शोर के लिए None, और छिपे हुए अंतराल से बचने के लिए एक निम्न-स्तरीय फ़ॉलबैक का उपयोग करें।

apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
  - RequestReceived
rules:
  - level: Request
    resources:
      - group: ""
        resources: ["secrets"]
  - level: Metadata
    omitStages: ["RequestReceived"]
    resources:
      - group: ""
        resources: ["pods"]
  - level: None
    users: ["system:kube-probe"]

3. चरणों और संवेदनशील फ़ील्ड्स को नियंत्रित करें

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

4. बैकएंड का चयन और सुरक्षा करें

फ़ाइल लॉग को विश्वसनीय रूप से घुमाएँ (rotate), संपीड़ित करें (compress), एन्क्रिप्ट करें और अग्रेषित करें। एक वेबहुक को TLS, प्रमाणीकरण, कतारों (queues) और बैकप्रेशर की आवश्यकता होती है। पाइपलाइन को टेनेंट और जोखिम के आधार पर विभाजित करें, केवल-जोड़ने योग्य (append-only) स्टोरेज का उपयोग करें, और ऑडिट आईडी, पॉलिसी संस्करण, और प्राप्त होने का समय संलग्न करें। डाउनस्ट्रीम उपभोक्ताओं को API सर्वर को सिंक्रोनस रूप से ब्लॉक नहीं करना चाहिए।

5. विफलता सेमेंटिक्स को परिभाषित करें

निर्दिष्ट करें कि जब बैकएंड अनुपलब्ध हो, डिस्क भर गई हो, कतार ओवरफ्लो हो जाए, या नेटवर्क विभाजन हो जाए तो क्या होगा: ड्रॉप करें, ब्लॉक करें, या डिग्रेड करें। उच्च-जोखिम वाले राइट्स कंट्रोल-प्लेन प्रभाव को मापने के बाद ही fail-closed का उपयोग कर सकते हैं; साधारण ट्रैफ़िक सीमित बफरिंग और अलर्ट का उपयोग कर सकता है। हानि काउंटरों और रिकवरी स्कैन रेंज को रिकॉर्ड करें।

6. निरंतर सत्यापित और सुधार करें

ज्ञात उपयोगकर्ताओं, ServiceAccounts, प्रॉक्सी और लंबे समय तक चलने वाले अनुरोधों से इवेंट्स उत्पन्न करें। नियम मिलान, चरणों, टेनेंट एट्रिब्यूशन और रिडक्शन (redaction) की जांच करें। वेबहुक विलंब, फुल डिस्क और पॉलिसी अपडेट इंजेक्ट करें, फिर अलर्ट, रिकवरी और फोरेंसिक प्रश्नों को सत्यापित करें। इवेंट वॉल्यूम, हानि, विलंबता, लागत और जांच कवरेज को ट्रैक करें।

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

मैं जांच के प्रश्नों को फ़ील्ड्स और उच्च-जोखिम वाले संसाधनों से मैप करूँगा, फिर नियमों को विशिष्ट से सामान्य के क्रम में व्यवस्थित करूँगा। नियमित ट्रैफ़िक को Metadata मिलता है, Secrets को नियंत्रित मेटाडेटा मिलता है, और चयनित परिवर्तनों को Request मिलता है; लंबे समय तक चलने वाले चरण स्पष्ट होते हैं। बैकएंड एन्क्रिप्टेड फ़ाइलों या बफरिंग, बैकप्रेशर, अपेंड-ओनली अखंडता और एक्सेस ऑडिटिंग के साथ एक TLS वेबहुक का उपयोग करता है, जिससे उपभोक्ता API सर्वर को ब्लॉक नहीं कर पाते हैं। विफलता व्यवहार में सीमित बफरिंग, हानि काउंटर और अलर्ट शामिल हैं, जिसमें fail-closed केवल परिमाणित उच्च-जोखिम वाले राइट्स के लिए आरक्षित है। सिंथेटिक इवेंट्स, लंबे समय तक चलने वाले अनुरोध और विफलता ड्रिल्स पॉलिसी और रिकवरी पथ को साबित करते हैं।

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

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

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

RequestResponse पर प्रत्येक Secret अनुरोध को रिकॉर्ड क्यों नहीं किया जाता?

बॉडी में प्लेनटेक्स्ट Secrets हो सकते हैं। अधिकांश जांचों में प्रिंसिपल, ऑब्जेक्ट, वर्ब और परिणाम की आवश्यकता होती है; गहन पहुंच के लिए रिडक्शन, अलग की गई अनुमतियाँ और कम समय के लिए नियंत्रित अवधारण की आवश्यकता होती है।

जब वेबहुक अनुपलब्ध हो तो क्या API अनुरोध को ब्लॉक किया जाना चाहिए?

यह जोखिम और उपलब्धता लक्ष्यों पर निर्भर करता है। प्रभाव को मापने के बाद, उच्च-जोखिम वाले राइट्स fail-closed हो सकते हैं जबकि साधारण ट्रैफ़िक सीमित बफरिंग और अलर्ट का उपयोग करता है। दोनों में से किसी भी विकल्प को हानि और रिकवरी के दायरे को उजागर करना चाहिए।

आप कैसे साबित करते हैं कि अज्ञात संसाधनों को चुपचाप छोड़ा नहीं गया है?

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