Kubernetes में Seccomp: 7 चीजें जो आपको शुरुआत से जानने की जरूरत हैं

लगभग। ट्रांस। : ब्रिटिश कंपनी ASOS.com में एक वरिष्ठ अनुप्रयोग सुरक्षा इंजीनियर द्वारा एक लेख का अनुवाद प्रस्तुत करना। उसके साथ, वह सेकंडपैक के उपयोग के माध्यम से कुबेरनेट्स में सुरक्षा में सुधार पर प्रकाशनों की एक श्रृंखला शुरू करता है। अगर पाठकों को परिचय पसंद है, तो हम लेखक का अनुसरण करेंगे और इस विषय पर अपनी भविष्य की सामग्री जारी रखेंगे।



यह लेख जादू और जादू टोना का सहारा लिए बिना SecDevOps की भावना में सेकंड प्रोफाइल बनाने के लिए प्रकाशनों की एक श्रृंखला है। पहले भाग में, मैं कुबेरनेट्स में seccomp के कार्यान्वयन की मूल बातें और आंतरिक विवरण के बारे में बात करूंगा।

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

यह महत्वपूर्ण क्यों है? एक कंटेनर एक विशिष्ट मशीन पर चलने वाली प्रक्रिया है। और यह कर्नेल का उपयोग अन्य अनुप्रयोगों के बराबर करता है। यदि कंटेनर कोई भी सिस्टम कॉल कर सकते हैं, तो बहुत जल्द मालवेयर इसका फायदा उठाकर कंटेनर के अलगाव को दरकिनार कर देगा और अन्य अनुप्रयोगों को प्रभावित करेगा: इंटरसेप्ट जानकारी, सिस्टम सेटिंग्स को बदलना आदि।

Seccomp प्रोफाइल निर्धारित करती है कि किस सिस्टम कॉल की अनुमति दी जानी चाहिए या उसे अस्वीकृत किया जाना चाहिए। कंटेनर रनटाइम लॉन्च के दौरान उन्हें सक्रिय करता है, ताकि कर्नेल उनके निष्पादन को नियंत्रित कर सके। ऐसे प्रोफाइल का उपयोग आपको हमले के वेक्टर को सीमित करने और क्षति को कम करने की अनुमति देता है यदि कंटेनर के अंदर कोई भी कार्यक्रम (यानी, आपकी निर्भरताएं, या उनकी निर्भरताएं) ऐसा करने लगती हैं जो इसे करने की अनुमति नहीं है।

मूल बातें समझना

Seccomp बेस प्रोफ़ाइल में तीन तत्व शामिल हैं: defaultAction , architectures (या archMap ) और syscalls :

 { "defaultAction": "SCMP_ACT_ERRNO", "architectures": [ "SCMP_ARCH_X86_64", "SCMP_ARCH_X86", "SCMP_ARCH_X32" ], "syscalls": [ { "names": [ "arch_prctl", "sched_yield", "futex", "write", "mmap", "exit_group", "madvise", "rt_sigprocmask", "getpid", "gettid", "tgkill", "rt_sigaction", "read", "getpgrp" ], "action": "SCMP_ACT_ALLOW" } ] } 

( मध्यम-मूल- seccomp.json )

defaultAction syscalls अनुभाग में निर्दिष्ट किसी भी सिस्टम कॉल के डिफ़ॉल्ट भाग्य को निर्धारित करता है। कार्य को सरल बनाने के लिए, हम दो मुख्य मूल्यों पर ध्यान केंद्रित करते हैं जिनका उपयोग किया जाएगा:

• SCMP_ACT_ERRNO - एक सिस्टम कॉल के निष्पादन को रोकता है,
• SCMP_ACT_ALLOW - अनुमति देता है।

architectures अनुभाग लक्ष्य आर्किटेक्चर को सूचीबद्ध करता है। यह महत्वपूर्ण है, चूंकि कर्नेल स्तर पर लागू किया गया फ़िल्टर स्वयं, सिस्टम कॉल के पहचानकर्ताओं पर निर्भर करता है, न कि प्रोफ़ाइल में पंजीकृत उनके नामों पर। उपयोग करने से पहले, कंटेनर रनटाइम उन्हें पहचानकर्ताओं को मैप करता है। मुद्दा यह है कि सिस्टम आर्किटेक्चर के आधार पर सिस्टम कॉल में पूरी तरह से अलग आईडी हो सकते हैं। उदाहरण के लिए, recvfrom सिस्टम कॉल (सॉकेट से जानकारी प्राप्त करने के लिए उपयोग किया जाता है) में x64 सिस्टम पर ID = 64 और x86 पर ID = 517 है। यहां आप x86-x64 आर्किटेक्चर के लिए सभी सिस्टम कॉल की सूची पा सकते हैं।

syscalls अनुभाग सभी सिस्टम कॉल को सूचीबद्ध करता है और इंगित करता है कि उनके साथ क्या करना है। उदाहरण के लिए, आप defaultAction पर SCMP_ACT_ERRNO को सेट करके एक श्वेतसूची बना सकते हैं, और syscalls को syscalls अनुभाग पर कॉल असाइन कर SCMP_ACT_ALLOW । इस प्रकार, आप केवल syscalls अनुभाग में पंजीकृत कॉल की अनुमति देते हैं और अन्य सभी को प्रतिबंधित करते हैं। ब्लैकलिस्ट के लिए, आपको defaultAction मान और क्रियाओं को विपरीत में बदलना चाहिए।

अब कुछ शब्दों को बारीकियों के बारे में कहा जाना चाहिए जो इतने स्पष्ट नहीं हैं। कृपया ध्यान दें कि नीचे दी गई सिफारिशें इस तथ्य से आती हैं कि आप कुबेरनेट्स में व्यावसायिक अनुप्रयोगों की एक पंक्ति को तैनात कर रहे हैं और आपके लिए यह महत्वपूर्ण है कि वे कम से कम विशेषाधिकारों के साथ काम करें।

1. AllowPrivilegeEscalation = false

कंटेनर के securityContext में AllowPrivilegeEscalation पैरामीटर है। यदि इसे false सेट किया जाता false , तो कंटेनर no_new_priv बिट से ( on ) सेट हो no_new_priv । इस पैरामीटर का अर्थ नाम से स्पष्ट है: यह कंटेनर को उन विशेषाधिकारों के साथ नई प्रक्रिया शुरू करने की अनुमति नहीं देता है जो इसके पास है।

true (डिफ़ॉल्ट मान) के लिए सेट किए गए इस पैरामीटर का एक साइड इफेक्ट यह है कि कंटेनर रनटाइम स्टार्टअप प्रक्रिया की शुरुआत में seccomp प्रोफाइल पर लागू होता है। इस प्रकार, सभी सिस्टम रनटाइम की आंतरिक प्रक्रियाओं को शुरू करने के लिए आवश्यक है (उदाहरण के लिए, उपयोगकर्ता / समूह की पहचान करने वाले, कुछ क्षमताओं को छोड़ने) को प्रोफ़ाइल में अनुमति दी जानी चाहिए।

कंटेनर जो बैंको echo hi करता है उसे निम्नलिखित अनुमतियों की आवश्यकता होगी:

 { "defaultAction": "SCMP_ACT_ERRNO", "architectures": [ "SCMP_ARCH_X86_64", "SCMP_ARCH_X86", "SCMP_ARCH_X32" ], "syscalls": [ { "names": [ "arch_prctl", "brk", "capget", "capset", "chdir", "close", "execve", "exit_group", "fstat", "fstatfs", "futex", "getdents64", "getppid", "lstat", "mprotect", "nanosleep", "newfstatat", "openat", "prctl", "read", "rt_sigaction", "statfs", "setgid", "setgroups", "setuid", "stat", "uname", "write" ], "action": "SCMP_ACT_ALLOW" } ] } 

( हाय-पॉड- seccomp.json )

... इनके बजाय:

 { "defaultAction": "SCMP_ACT_ERRNO", "architectures": [ "SCMP_ARCH_X86_64", "SCMP_ARCH_X86", "SCMP_ARCH_X32" ], "syscalls": [ { "names": [ "arch_prctl", "brk", "close", "execve", "exit_group", "futex", "mprotect", "nanosleep", "stat", "write" ], "action": "SCMP_ACT_ALLOW" } ] } 

( हाय-कंटेनर- seccomp.json )

लेकिन फिर, यह एक समस्या क्यों है? व्यक्तिगत रूप से, मैं निम्नलिखित सिस्टम कॉल को capset (यदि उन्हें वास्तव में ज़रूरत नहीं है): capset , set_tid_address , setgid , setgroups और setuid । हालांकि, वास्तविक कठिनाई यह है कि ऐसी प्रक्रियाओं की अनुमति देने से जिनका आप पर कोई नियंत्रण नहीं है, आप कंटेनर रनटाइम के कार्यान्वयन के लिए प्रोफाइल को बांधते हैं। दूसरे शब्दों में, एक दिन आप पा सकते हैं कि कंटेनर के रनटाइम वातावरण (आपके द्वारा या अधिक संभावना, क्लाउड सेवा प्रदाता द्वारा) को अपडेट करने के बाद, कंटेनर अचानक बंद करना शुरू कर देते हैं।

टिप # 1 : AllowPrivilegeEscaltion=false साथ कंटेनर चलाएँ। यह seccomp प्रोफाइल के आकार को कम करेगा और कंटेनर रनटाइम में बदलाव के लिए उन्हें कम संवेदनशील बना देगा।

2. कंटेनर-स्तर सेकंड प्रोफाइल स्थापित करना

Seccomp प्रोफ़ाइल को पॉड स्तर पर सेट किया जा सकता है:

 annotations: seccomp.security.alpha.kubernetes.io/pod: "localhost/profile.json" 

... या कंटेनर स्तर पर:

 annotations: container.security.alpha.kubernetes.io/<container-name>: "localhost/profile.json" 

कृपया ध्यान दें कि कुबेरनेट्स सेकैम GA हो जाने पर उपरोक्त सिंटैक्स बदल जाएगा (अगले कुबेरनेट्स रिलीज़ में यह घटना अपेक्षित है - 1.18 - लगभग। अनुवाद।)।

कुछ लोगों को पता है कि कुबेरनेट्स के पास हमेशा एक बग होता था, जिससे पॉज कंटेनर में सेक्युलर प्रोफाइल को लगाया जाता था। रनटाइम आंशिक रूप से इस खामी की भरपाई करता है, लेकिन यह कंटेनर फली से गायब नहीं होता है, क्योंकि इसका उपयोग उनके बुनियादी ढांचे को कॉन्फ़िगर करने के लिए किया जाता है।

समस्या यह है कि यह कंटेनर हमेशा AllowPrivilegeEscalation=true साथ शुरू होता AllowPrivilegeEscalation=true , जिससे पैराग्राफ 1 में AllowPrivilegeEscalation=true समस्याओं का कारण AllowPrivilegeEscalation=true , और इसे बदला नहीं जा सकता।

कंटेनर स्तर पर seccomp प्रोफाइल लागू करने से आप इस जाल से बच सकते हैं और एक ऐसा प्रोफ़ाइल बना सकते हैं जो विशिष्ट कंटेनर के लिए "शार्प" होगा। यह तब तक करना होगा जब तक कि डेवलपर्स बग को ठीक न करें और नया संस्करण (शायद 1.18?) सभी के लिए उपलब्ध हो जाए।

टिप # 2 : कंटेनर स्तर पर seccomp प्रोफाइल सेट करें।

व्यावहारिक अर्थ में, यह नियम आम तौर पर इस सवाल का एक सार्वभौमिक उत्तर के रूप में कार्य करता है: "मेरी सेकंड प्रोफ़ाइल प्रोफ़ाइल डॉक docker run साथ क्यों काम करती है, लेकिन यह कुबेरनेट क्लस्टर में तैनाती के बाद काम नहीं करती है?"

3. एक अंतिम उपाय के रूप में रनटाइम / डिफॉल्ट का उपयोग करें

कुबेरनेट्स में अंतर्निहित प्रोफाइल के लिए दो विकल्प हैं: runtime/default और docker/default । दोनों कंटेनर रनटाइम द्वारा कार्यान्वित किए जाते हैं, न कि कुबेरनेट्स। इसलिए, वे उपयोग किए गए रनटाइम और इसके संस्करण के आधार पर भिन्न हो सकते हैं।

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

कुबेरनेट्स 1.11 के बाद से डॉकटर docker/default प्रोफाइल को हटा दिया गया है, इसलिए इसका उपयोग करने से बचें।

मेरी राय में, runtime/default प्रोफाइल उस उद्देश्य के लिए एकदम सही है जिसके लिए इसे बनाया गया था: उपयोगकर्ताओं को अपनी मशीनों पर docker run जुड़े जोखिमों से बचाने के लिए। हालांकि, अगर हम कुबेरनेट समूहों में चल रहे व्यावसायिक अनुप्रयोगों के बारे में बात करते हैं, तो मैं यह दावा करने की हिम्मत करूंगा कि ऐसी प्रोफ़ाइल बहुत खुली है और डेवलपर्स को अपने अनुप्रयोगों (या एप्लिकेशन प्रकारों) के लिए प्रोफ़ाइल बनाने पर ध्यान केंद्रित करना चाहिए।

टिप # 3 : विशिष्ट अनुप्रयोगों के लिए सेकंड प्रोफ़ाइल बनाएं। यदि यह संभव नहीं है, तो अनुप्रयोगों के प्रकारों के लिए प्रोफाइल से निपटें, उदाहरण के लिए, एक उन्नत प्रोफ़ाइल बनाएं जिसमें सभी गोलांग वेब एप्लिकेशन एपीआई शामिल हैं। केवल अंतिम उपाय के रूप में रनटाइम / डिफ़ॉल्ट का उपयोग करें।

भविष्य के प्रकाशनों में, मैं आपको बताऊंगा कि कैसे SecDevOps की भावना में secccomp प्रोफाइल तैयार करें, उन्हें स्वचालित करें और उन्हें पाइपलाइनों में परीक्षण करें। दूसरे शब्दों में, आपके पास विशिष्ट अनुप्रयोगों के लिए प्रोफाइल पर स्विच नहीं करने का कोई बहाना नहीं होगा।

4. अपुष्ट एक विकल्प नहीं है

पहले कुबेरनेट सुरक्षा ऑडिट से, यह पता चला कि सेक्युलक डिफ़ॉल्ट रूप से अक्षम था । इसका मतलब यह है कि यदि आप एक PodSecurityPolicy निर्दिष्ट नहीं करते हैं जो इसे क्लस्टर में सक्षम करेगा, तो सभी पॉड्स जिसके लिए seccomp प्रोफाइल परिभाषित नहीं है, seccomp=unconfined में काम करेगा।

इस मोड में काम करने का मतलब है कि अलगाव की एक पूरी परत खो जाती है, जो क्लस्टर सुरक्षा प्रदान करती है। यह दृष्टिकोण सुरक्षा पेशेवरों द्वारा अनुशंसित नहीं है।

टिप # 4 : क्लस्टर में कोई भी कंटेनर seccomp=unconfined में काम नहीं करना चाहिए, विशेष रूप से उत्पादन वातावरण में।

5. "ऑडिट मोड"

यह बिंदु कुबेरनेट्स के लिए अद्वितीय नहीं है, लेकिन यह अभी भी "शुरू होने से पहले आपके बारे में क्या जानना चाहिए" की श्रेणी में आता है।

यह ऐसा हुआ कि seccomp प्रोफाइल बनाना हमेशा एक मुश्किल काम था और यह काफी हद तक परीक्षण और त्रुटि पर आधारित था। तथ्य यह है कि उपयोगकर्ताओं के पास आवेदन छोड़ने के बिना उत्पादन वातावरण में उन्हें परीक्षण करने का अवसर नहीं है।

लिनक्स 4.14 कर्नेल के आगमन के बाद, ऑडिट मोड में प्रोफाइल के कुछ हिस्सों को चलाना संभव हो गया, सिसलॉग में सभी सिस्टम कॉल के बारे में जानकारी दर्ज की, लेकिन उन्हें अवरुद्ध नहीं किया। आप SCMT_ACT_LOG पैरामीटर का उपयोग करके इस मोड को सक्रिय कर सकते हैं:

SCMP_ACT_LOG : seccomp सिस्टम कॉल करने वाले थ्रेड के संचालन को प्रभावित नहीं करेगा यदि यह फ़िल्टर से किसी नियम के अंतर्गत नहीं आता है, लेकिन सिस्टम कॉल के बारे में जानकारी लॉग की जाएगी।

यहाँ इस सुविधा का उपयोग करने के लिए एक नमूना रणनीति है:

1. सिस्टम कॉल की आवश्यकता है कि अनुमति दें।
2. ब्लॉक कॉल सिस्टम जिन्हें उपयोगी नहीं जाना जाता है।
3. लॉग में अन्य सभी कॉल के बारे में जानकारी रिकॉर्ड करें।

एक सरल उदाहरण इस प्रकार है:

 { "defaultAction": "SCMP_ACT_LOG", "architectures": [ "SCMP_ARCH_X86_64", "SCMP_ARCH_X86", "SCMP_ARCH_X32" ], "syscalls": [ { "names": [ "arch_prctl", "sched_yield", "futex", "write", "mmap", "exit_group", "madvise", "rt_sigprocmask", "getpid", "gettid", "tgkill", "rt_sigaction", "read", "getpgrp" ], "action": "SCMP_ACT_ALLOW" }, { "names": [ "add_key", "keyctl", "ptrace" ], "action": "SCMP_ACT_ERRNO" } ] } 

( मध्यम-मिश्रित- seccomp.json )

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

हालांकि, एक कैच है। हालांकि SCMT_ACT_LOG 2017 के अंत से लिनक्स कर्नेल द्वारा समर्थित SCMT_ACT_LOG , यह केवल हाल ही में कुबेरनेट्स पारिस्थितिकी तंत्र में प्रवेश किया है। इसलिए, इस विधि का उपयोग करने के लिए, आपको लिनक्स 4.14 कर्नेल और रनक संस्करण की आवश्यकता होगी जो v1.0.0-आरसी 9 से कम नहीं है।

टिप # 5 : आप ब्लैक एंड व्हाइट सूचियों के संयोजन द्वारा उत्पादन में परीक्षण के लिए एक ऑडिट मोड प्रोफाइल बना सकते हैं, और सभी अपवादों को लॉग इन कर सकते हैं।

6. श्वेतसूची का प्रयोग करें

श्वेतसूची बनाने के लिए अतिरिक्त प्रयासों की आवश्यकता होती है, क्योंकि आपको हर उस कॉल की पहचान करनी होती है, जिसके लिए एप्लिकेशन की आवश्यकता हो सकती है, लेकिन इस दृष्टिकोण से सुरक्षा में काफी सुधार होता है:

यह दृढ़ता से अनुशंसा की जाती है कि आप श्वेतसूची दृष्टिकोण का उपयोग करें क्योंकि यह सरल और अधिक विश्वसनीय है। जब भी संभावित खतरनाक सिस्टम कॉल (या खतरनाक ध्वज / विकल्प यदि वे ब्लैकलिस्ट में हैं) को जोड़ा जाता है तो ब्लैकलिस्ट को अपडेट करना होगा। इसके अलावा, आप अक्सर इसके सार को बदले बिना एक पैरामीटर की प्रस्तुति को बदल सकते हैं और इस तरह ब्लैकलिस्ट की सीमाओं को दरकिनार कर सकते हैं।

गो एप्लिकेशन के लिए, मैंने एक विशेष टूल विकसित किया जो एप्लिकेशन के साथ चलता है और रनटाइम पर किए गए सभी कॉल को इकट्ठा करता है। उदाहरण के लिए, निम्नलिखित आवेदन के लिए:

 package main import "fmt" func main() { fmt.Println("test") } 

... इस तरह से चलाएं:

 go install https://github.com/pjbgf/gosystract gosystract --template='{{- range . }}{{printf "\"%s\",\n" .Name}}{{- end}}' application-path 

... और निम्न परिणाम प्राप्त करें:

 "sched_yield", "futex", "write", "mmap", "exit_group", "madvise", "rt_sigprocmask", "getpid", "gettid", "tgkill", "rt_sigaction", "read", "getpgrp", "arch_prctl", 

अब तक यह सिर्फ एक उदाहरण है - उपकरण के बारे में विवरण आगे होगा।

टिप # 6 : केवल उन कॉल की अनुमति दें जिनकी आपको वास्तव में आवश्यकता है और बाकी सभी को ब्लॉक करें।

7. नींव रखना (या अप्रत्याशित व्यवहार के लिए तैयार करना)

कर्नेल प्रोफ़ाइल के अनुपालन की निगरानी करेगा, चाहे आपने उसमें जो भी दर्ज किया हो। भले ही यह वह नहीं है जो मैं चाहता था। उदाहरण के लिए, यदि आप exit या exit_group जैसी कॉल्स तक पहुंच को exit_group , तो कंटेनर सही तरीके से काम पूरा नहीं कर पाएगा और echo hi जैसी एक साधारण कमांड भी इसे अनिश्चित अवधि के लिए निलंबित कर echo hi । परिणामस्वरूप, आपको क्लस्टर में उच्च CPU उपयोग मिलेगा:



ऐसे मामलों में, strace यूटिलिटी बचाव में आ सकती है - यह दिखाएगा कि समस्या क्या हो सकती है:


sudo strace -c -p 9331

सुनिश्चित करें कि प्रोफाइल में सभी सिस्टम कॉल शामिल हैं जो एप्लिकेशन को चलने के दौरान चाहिए।

टिप # 7 : छोटी चीज़ों पर ध्यान दें और सुनिश्चित करें कि सभी आवश्यक सिस्टम कॉल सफेद सूची में शामिल हैं।

इसके साथ, SecDevOps की भावना में कुबेरनेट्स में seccomp का उपयोग करने के बारे में लेखों की एक श्रृंखला का पहला भाग समाप्त हो जाता है। निम्नलिखित भागों में हम इस बारे में बात करेंगे कि यह क्यों महत्वपूर्ण है और प्रक्रिया को स्वचालित कैसे किया जाए।

अनुवादक से पी.एस.

हमारे ब्लॉग में भी पढ़ें:

• " डॉकटर कंटेनरों की सुरक्षा ";
• " 33+ कुबेरनेट सुरक्षा उपकरण ";
• " सुरक्षा-मांग वाले वातावरण में डोकर और कुबेरनेट्स ";
• " 9 कुबेरनेट्स सुरक्षा सर्वोत्तम अभ्यास ।"