SPIFFE/SPIRE के अल्पकालिक SVIDs भी नोड की अखंडता पर क्यों निर्भर हैं, प्रयोगशाला में cgroup स्पूफ़िंग परीक्षण से क्या पता चला और Kubernetes के कौन-से सुरक्षा नियंत्रण असर सीमित कर सकते हैं—इसकी व्याख्या।
SPIFFE सेवाओं को कम अवधि तक वैध रहने वाले क्रिप्टोग्राफ़िक पहचान दस्तावेज़ देता है, जिन्हें SVIDs कहा जाता है। वर्कलोड इनका उपयोग TLS कनेक्शन स्थापित करने या JWTs पर हस्ताक्षर करने और उनका सत्यापन करने के लिए कर सकते हैं। SPIFFE का आधिकारिक परिचय इस मॉडल को परिभाषित करता है।
पहचान का निर्णय कहाँ लिया जाता है
SPIRE, SVIDs जारी करने से पहले नोड और वर्कलोड का अटेस्टेशन करता है। वर्कलोड अटेस्टेशन के दौरान SPIRE एजेंट, ऑपरेटिंग सिस्टम के कर्नेल या उसी नोड पर मौजूद kubelet जैसे स्थानीय स्रोतों से किसी प्रोसेस की विशेषताओं का पता लगाता है। फिर वह उन विशेषताओं का मिलान किसी रजिस्ट्रेशन एंट्री की सेलेक्टर शर्तों से करता है; सफल मिलान से तय होता है कि प्रोसेस को कौन-सी SPIFFE ID मिलेगी। SPIRE की अवधारणाओं से जुड़े दस्तावेज़ इस प्रक्रिया का वर्णन करते हैं।
प्रयोगशाला में मिले निष्कर्ष का दायरा
इस मॉडल में दो अलग सवाल हैं: क्या कोई SVID क्रिप्टोग्राफ़िक रूप से वैध है, और क्या उसे उसी प्रोसेस को जारी किया गया है जिसके लिए वह निर्धारित था। Unit 42 के प्रयोगशाला शोध से पता चला कि Kubernetes नोड पर पहले से root एक्सेस रखने वाला हमलावर Linux cgroup की जानकारी को फ़र्ज़ी बनाकर SPIRE एजेंट को धोखा दे सकता था और उसी नोड पर मौजूद किसी दूसरे वर्कलोड का वैध SVID प्राप्त कर सकता था। इस तकनीकी प्रक्रिया का विवरण Unit 42 के शोध में दिया गया है।
Unit 42 ने स्पष्ट रूप से कहा है कि उसने वास्तविक हमलों में इस तकनीक का इस्तेमाल नहीं देखा है। इसलिए यह निष्कर्ष सक्रिय दुरुपयोग का प्रमाण नहीं है; यह सुरक्षा का उल्लंघन होने के बाद उत्पन्न होने वाले उस जोखिम का वर्णन करता है जो root एक्सेस के कारण नोड पर भरोसे का आधार टूटने से पैदा होता है।
नोड से जुड़े जोखिम के लिए सुरक्षा मॉडल
सुरक्षा की योजना बनाते समय, किसी नोड की सुरक्षा भंग होने को उस नोड के दायरे में आने वाली हर वर्कलोड पहचान की सुरक्षा भंग होने के बराबर मानना चाहिए। Unit 42 के मार्गदर्शन में विशेषाधिकार प्राप्त कंटेनरों और होस्ट तक सीधे एक्सेस पर पाबंदी लगाना शामिल है। साथ ही, कमज़ोर या आसानी से फ़र्ज़ी बनाए जा सकने वाले सेलेक्टरों पर निर्भरता घटाने की सलाह दी गई है। इसका दायरा वह नोड है जिसकी सुरक्षा भंग हुई है, अपने आप पूरा क्लस्टर नहीं।
पॉड और नोड के विशेषाधिकार घटाएँ
Kubernetes Pod Security Standards की Restricted प्रोफ़ाइल के अनुसार, विशेषाधिकार प्राप्त पॉड की अनुमति नहीं होनी चाहिए, विशेषाधिकार बढ़ाने पर रोक होनी चाहिए और कंटेनर गैर-root उपयोगकर्ताओं के रूप में चलने चाहिए। आधिकारिक सुरक्षा जाँच-सूची यह भी कहती है कि seccomp कंटेनरों के भीतर उपलब्ध Linux कर्नेल के syscall का दायरा घटा सकता है। विवरण Pod Security Standards और Kubernetes की सुरक्षा जाँच-सूची में दिए गए हैं।
सेलेक्टरों को भरोसे की सीमा का हिस्सा मानें
सेलेक्टर केवल मिलान का विवरण नहीं हैं: वे तय करते हैं कि अटेस्टेशन के निर्णय में किन स्थानीय विशेषताओं को आधार बनाया जाएगा। इसलिए समीक्षा में यह देखना चाहिए कि हर शर्त के लिए ऑपरेटिंग सिस्टम या kubelet का कौन-सा डेटा इस्तेमाल होता है और क्या root एक्सेस से उस डेटा को आसानी से फ़र्ज़ी बनाया जा सकता है। लक्ष्य व्यापक या कमज़ोर शर्तों के बजाय ऐसे सेलेक्टरों पर निर्भर रहना है जो सीमित और सटीक आधार पर वर्कलोड के बीच अंतर करें।
संवेदनशीलता के स्तरों का अलगाव और अतिरिक्त क्रेडेंशियल
Kubernetes यह भी सलाह देता है कि अलग-अलग संवेदनशीलता वाले वर्कलोड अलग नोड पर रखे जाएँ और जिन पॉड को सर्विस अकाउंट टोकन की ज़रूरत नहीं है, उनमें ये टोकन माउंट न किए जाएँ। दोनों नियंत्रणों का वर्णन आधिकारिक सुरक्षा जाँच-सूची में किया गया है।
नोड अलग रखने का उद्देश्य यह है कि कंटेनर की सीमाओं से बाहर निकलने के बाद अधिक संवेदनशील ऐप्लिकेशन तक सीधे पहुँच बनाना कठिन हो। अनावश्यक सर्विस अकाउंट टोकन माउंट न करने से पॉड के भीतर SVID से अलग एक अतिरिक्त क्रेडेंशियल भी मौजूद नहीं रहता।
समीक्षा का व्यावहारिक क्रम
भरोसे की इस सीमा के आधार पर समीक्षा का एक छोटा क्रम बनाया जा सकता है, जिसमें कॉन्फ़िगरेशन और वर्कलोड को किस नोड पर रखा गया है, दोनों को साथ देखा जाए:
पहचान का दायरा: हर नोड के दायरे में कौन-सी SPIFFE IDs आती हैं, और संवेदनशीलता के किन स्तरों के वर्कलोड उस नोड पर साथ मौजूद हैं?
अटेस्टेशन के इनपुट: सेलेक्टर ऑपरेटिंग सिस्टम या kubelet के किस डेटा का उपयोग करते हैं, और क्या root एक्सेस से उस डेटा को फ़र्ज़ी बनाया जा सकता है?
नोड के विशेषाधिकार: कौन-से पॉड विशेषाधिकार प्राप्त हैं, होस्ट तक एक्सेस कर सकते हैं, विशेषाधिकार बढ़ाने की अनुमति देते हैं या root के रूप में चलते हैं?
अतिरिक्त क्रेडेंशियल: किन पॉड को सर्विस अकाउंट टोकन मिलते हैं, जबकि उन्हें इनकी ज़रूरत नहीं है?
निष्कर्ष यह नहीं है कि SVIDs का कोई महत्व नहीं है। उनकी क्रिप्टोग्राफ़िक पहचान की गारंटियों का मूल्यांकन उस नोड की अखंडता के साथ करना ज़रूरी है जहाँ अटेस्टेशन होता है। एक मज़बूत मॉडल अल्पकालिक वर्कलोड पहचान के साथ पॉड की सुरक्षा मज़बूत करने, सीमित और सटीक सेलेक्टर शर्तें रखने, संवेदनशीलता के आधार पर नोड अलग करने और अनावश्यक क्रेडेंशियल हटाने को जोड़ता है।
