👩🏼‍🎨 🕯️ 🤔 कुबेरनेट्स में हैकिंग का शिकार बनने के 11 तरीके (नहीं) 💈 👵🏿 🏅

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

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

भाग 1: नियंत्रण विमान

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

1. सर्वव्यापी टीएलएस

टीएलएस का समर्थन करने वाले प्रत्येक घटक के लिए, ट्रैफ़िक सूँघने, सर्वर पहचान सत्यापन और (म्यूचुअल टीएलएस के मामले में) ग्राहक पहचान सत्यापन को रोकने के लिए इसे सक्षम किया जाना चाहिए।

"कृपया ध्यान दें कि कुछ घटक और स्थापना विधियाँ HTTP के लिए स्थानीय पोर्ट को सक्रिय कर सकती हैं, इसलिए प्रशासकों को असुरक्षित ट्रैफ़िक के लिए संभावित रास्तों की पहचान करने के लिए प्रत्येक घटक की सेटिंग्स से परिचित होना आवश्यक है।"

Kubernetes प्रलेखन से

लुकास काल्डस्ट्रम से नीचे का नेटवर्क आरेख दिखाता है कि टीएलएस आदर्श रूप से कहां आवश्यक है: विज़ार्ड के प्रत्येक घटक के बीच, और क्यूबलेट और एपीआई सर्वर के बीच। क्लासिक केल्सी हाईटॉवर कुबेरनेट्स द हार्ड वे और सिक्योरिटी डॉक्यूमेंटेशन ऑन वर्ड इन लक्ष्यों को प्राप्त करने के लिए विस्तृत निर्देश प्रदान करते हैं।

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

2. एबीबी को अक्षम करते हुए आरबीएसी में न्यूनतम विशेषाधिकार, लॉग मॉनिटरिंग

रोल बेस्ड एक्सेस कंट्रोल (RBAC) ठीक-ठाक नीति प्रबंधन प्रदान करता है जिसके द्वारा उपयोगकर्ता नामस्थान जैसे संसाधनों का उपयोग करते हैं।

कुबेरनेट्स में विशेषता आधारित अभिगम नियंत्रण (ABAC) को K8s 1.6 के बाद RBAC द्वारा प्रतिस्थापित किया गया है और इसे API के सर्वर साइड पर सक्षम नहीं किया जाना चाहिए। इसके बजाय RBAC का उपयोग करें: --authorization-mode=RBAC (या GKE के लिए यह ध्वज: --authorization-mode=RBAC --no-enable-legacy-authorization )।

एक क्लस्टर में विभिन्न सेवाओं के लिए आरबीएसी नीतियों के कई अच्छे उदाहरण हैं , साथ ही साथ प्रलेखन भी । लेकिन वहां मत रुकिए : audit लॉग से audit आरबीएसी का उपयोग करके आरबीएसी नीतियों के लिए सक्षम सेटिंग्स प्राप्त की जा सकती हैं।

अगर गलत समझौता किया जाता है, तो गलत या अत्यधिक अनुमत आरबीएसी नीतियां सुरक्षा जोखिम हैं। न्यूनतम विशेषाधिकार के साथ RBAC नियमों को बनाए रखना, उन्हें लगातार ऑडिट करना और उन्हें सुधारना "ऋण की तकनीकी स्वच्छता" का हिस्सा होना चाहिए जो कि टीमें विकास जीवन चक्र में लागू होती हैं।

ऑडिट लॉगिंग (Kubernetes 1.10 में बीटा) कार्यभार (जैसे अनुरोध और प्रतिक्रिया) और मेटाडेटा स्तर पर एक कस्टम लॉगिंग एपीआई प्रदान करता है। लॉगिंग स्तर को संगठन की सुरक्षा नीति के अनुसार कॉन्फ़िगर किया जा सकता है - GKE उन लोगों के लिए उचित डिफ़ॉल्ट मान लागू करता है जो अभी इसके साथ काम करना शुरू कर रहे हैं।

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

मत भूलो: इन लॉग को क्लस्टर के अंदर संग्रहीत करना समझौता के मामले में एक सुरक्षा जोखिम है। इन लॉग को किसी अन्य सुरक्षा-संवेदनशील लोगों की तरह, भेद्यता के मामले में नकारात्मक परिणामों से बचने के लिए क्लस्टर के बाहर रखा जाना चाहिए।

3. एपीआई सर्वर के लिए तीसरे पक्ष के प्रमाणीकरण का उपयोग करें

संपूर्ण संगठन के लिए प्रमाणीकरण और प्राधिकरण का केंद्रीकरण (यानी, सिंगल साइन ऑन) नए कर्मचारियों को स्वीकार करने और छोड़ने की प्रक्रियाओं में मदद करता है, लगातार पहुंच अधिकारों को सुनिश्चित करता है।

तृतीय-पक्ष प्रमाणीकरण प्रदाताओं (जैसे Google या GitHub) के साथ Kubernetes एकीकरण दूरस्थ प्लेटफ़ॉर्म (दो-कारक प्रमाणीकरण जैसी सुरक्षा के साथ) से पहचान की गारंटी प्रदान करता है और उपयोगकर्ताओं को जोड़ने / निकालने के लिए Kubetetes में API सर्वर को पुन: कॉन्फ़िगर करने के लिए व्यवस्थापकों की आवश्यकता को समाप्त करता है।

डेक्स एक ओपनआईडी कनेक्ट आइडेंटिटी (OIDC) है और प्लग-इन के साथ OAuth 2.0 प्रदाता है। अनुकूलन योग्य उपकरण प्रदान करके पुशर और भी आगे बढ़ गया, इसके अलावा अन्य अनुप्रयोगों पर केंद्रित कुछ अन्य सहायक भी हैं।

4. फ़ायरवॉल के पीछे अपने क्लस्टर को अलग करें और रखें

Kdernetes स्थिति और रहस्यों के बारे में जानकारी संग्रहीत करता है, K8s का एक महत्वपूर्ण घटक है - इसे क्लस्टर के बाकी हिस्सों से अलग से संरक्षित किया जाना चाहिए।

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

कॉर्ड में कुबेरनेट्स शेड्यूलर उन पॉड परिभाषाओं की खोज करता है जिनमें नोड नहीं है। फिर वह सभी फली को योजना के लिए उपलब्ध क्यूबलेट में भेजता है। इन पॉड्स का सत्यापन एपीआई सर्वर द्वारा इनको लिखने से पहले किया जाता है, इसलिए हमलावरों को सीधे एटीआर पर लिखना कई सुरक्षा तंत्रों को बायपास कर सकता है - उदाहरण के लिए, PodSecurityPolicies ।

etcd को टीएलएस प्रमाणपत्र ( क्लाइंट और पीयर ) और समर्पित नोड्स पर तैनात दोनों के साथ कॉन्फ़िगर किया जाना चाहिए। कार्य नोड्स से निजी कुंजी की चोरी और उपयोग के जोखिम को कम करने के लिए, आप एपीआई सर्वर क्लस्टर के फ़ायरवॉल को सीमित कर सकते हैं।

5. एन्क्रिप्शन कुंजी का रोटेशन

सुरक्षा कुंजी और प्रमाणपत्रों का नियमित रोटेशन सबसे अच्छा सुरक्षा अभ्यास है जो आपको कुंजी से छेड़छाड़ करने पर "विनाश की त्रिज्या" को सीमित करने की अनुमति देता है।

कुबेरनेट्स वर्तमान में समाप्त होने के बाद नए CSR बनाकर कुछ प्रमाणपत्र (विशेष रूप से, क्यूबलेट क्लाइंट और सर्वर प्रमाणपत्र) को स्वचालित रूप से घुमाएंगे ।

हालाँकि, API सर्वर द्वारा एन्क्रिप्ट किए गए मानों को एन्क्रिप्ट करने के लिए उपयोग की गई सममित कुंजी स्वचालित रूप से घुमाई नहीं जाती है - यह मैन्युअल रूप से किया जाना चाहिए। इस ऑपरेशन के लिए मास्टर एक्सेस की आवश्यकता होती है, इसलिए प्रबंधित सेवाएं (जैसे GKE और AKS) उपयोगकर्ता से समस्या को छिपाती हैं।

भाग 2: कार्यभार

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

6. लिनक्स सुरक्षा सुविधाओं और पॉडसेक्विटीपॉलिटरी का उपयोग करें

लिनक्स कर्नेल में कई आंशिक रूप से अतिव्यापी सुरक्षा एक्सटेंशन (क्षमताएं, SELinux, AppArmor, seccomp-bpf) होते हैं जिन्हें अनुप्रयोगों को न्यूनतम विशेषाधिकार देने के लिए कॉन्फ़िगर किया जा सकता है।

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

PodSecurityPolatics इन सुरक्षा एक्सटेंशन, साथ ही अन्य कुबेरनेट्स सुरक्षा निर्देशों के उपयोग को नियंत्रित करते हैं। वे न्यूनतम आवश्यकताओं के लिए ज़िम्मेदार होते हैं, जिन्हें API सर्वर से प्राप्त करने के लिए मिलना चाहिए, जिसमें सुरक्षा प्रोफ़ाइल, विशेषाधिकार ध्वज, साझा होस्ट नेटवर्क, IPC के लिए प्रक्रियाएँ या नाम स्थान शामिल हैं।

ये निर्देश महत्वपूर्ण हैं क्योंकि वे कंटेनरीकृत प्रक्रियाओं को अपनी पृथक सीमाओं से बचने में मदद करते हैं। टिम ऑल्केयर की पॉडसैक्विटीपुलिस उदाहरण बहुत बहुमुखी है - आप इसे एक आधार के रूप में ले सकते हैं और इसे अपने मामले के लिए अनुकूलित कर सकते हैं।

7. YAML का स्थैतिक विश्लेषण करें

यदि PodSecurityPolurities एपीआई सर्वर तक पहुंच को प्रतिबंधित करते हैं, तो संगठन की नियामक आवश्यकताओं और जोखिम की भूख को मॉडल करने के लिए विकास प्रक्रिया में स्थैतिक विश्लेषण का भी उपयोग किया जा सकता है।

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

YAML कॉन्फ़िगरेशन के स्थैतिक विश्लेषण का उपयोग स्टार्टअप के दौरान सुरक्षा के लिए आधार के रूप में किया जा सकता है। kubesec संसाधनों के लिए जोखिम आकलन उत्पन्न करता है:

 { "score": -30, "scoring": { "critical": [{ "selector": "containers[] .securityContext .privileged == true", "reason": "Privileged containers can allow almost completely unrestricted host access" }], "advise": [{ "selector": "containers[] .securityContext .runAsNonRoot == true", "reason": "Force the running image to run as a non-root user to ensure least privilege" }, { "selector": "containers[] .securityContext .capabilities .drop", "reason": "Reducing kernel capabilities available to a container limits its attack surface", "href": "https://kubernetes.io/docs/tasks/configure-pod-container/security-context/" }] } }

और Kubetest इकाई परीक्षण Kubernetes विन्यास के लिए एक रूपरेखा है:

 #// vim: set ft=python: def test_for_team_label(): if spec["kind"] == "Deployment": labels = spec["spec"]["template"]["metadata"]["labels"] assert_contains(labels, "team", "should indicate which team owns the deployment") test_for_team_label()

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

8. कंटेनर चलाएँ रूट नहीं

कंटेनर जो रूट के रूप में चलते हैं, उनके कार्यभार की तुलना में अक्सर अधिक अधिकार होते हैं, और यदि समझौता किया जाता है, तो वे हमलावरों को महान क्षमताओं को प्राप्त करने में मदद करते हैं।

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

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

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

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

यह PodSecurityPolicy टुकड़ा कंटेनर में रूट प्रक्रियाओं और रूट को बढ़ने से रोकता है:

 # Required to prevent escalations to root. allowPrivilegeEscalation: false runAsUser: # Require the container to run without root privileges. rule: 'MustRunAsNonRoot'

कंटेनर जो रूट का उपयोग नहीं करते हैं वे विशेषाधिकार प्राप्त बंदरगाहों पर कब्जा नहीं कर सकते हैं, अर्थात्। 1024 तक (लिनक्स कर्नेल में संबंधित क्षमता - CAP_NET_BIND_SERVICE इसके लिए ज़िम्मेदार है), हालाँकि, सेवाओं के उपयोग से इस सीमा को कम करने में मदद मिलती है। यहां MyApp एप्लिकेशन के लिए एक उदाहरण है, जो कंटेनर में पोर्ट 8443 पर कब्जा कर लेता है, लेकिन सेवा इसे पोर्ट 443 पर उपलब्ध targetPort , targetPort लिए प्रॉक्सिमिंग अनुरोध:

 kind: Service apiVersion: v1 metadata: name: my-service spec: selector: app: MyApp ports: - protocol: TCP port: 443 targetPort: 8443

रूट का उपयोग किए बिना वर्कलोड चलाने की आवश्यकता तब तक रहेगी जब तक उपयोगकर्ता नेमस्पेस या रूट के बिना कंटेनर लॉन्च करने का संचालन समय कंटेनर रनटाइम में शामिल नहीं हो जाता।

9. नेटवर्क नीतियों का उपयोग करें

डिफ़ॉल्ट रूप से, कुबेरनेट्स नेटवर्क फली के बीच सभी यातायात की अनुमति देता है। यह सेटिंग नेटवर्क नीति - NetworkPolicy द्वारा सीमित की जा सकती है।

पारंपरिक सेवाएं स्थिर आईपी पते और प्रत्येक सेवा के लिए पोर्ट रेंज का उपयोग करके फायरवॉल तक सीमित हैं। क्योंकि ये IP पते बहुत ही कम बदलते हैं, इन्हें ऐतिहासिक रूप से प्रमाणीकरण के रूप में उपयोग किया जाता है। कंटेनरों में शायद ही कभी स्थिर आईपी होते हैं - उनकी प्रकृति का तात्पर्य एक त्वरित ड्रॉप और फिर से निर्माण की संभावना है, क्योंकि उनके लिए स्थिर आईपी पते के बजाय सेवा खोज का उपयोग किया जाता है। ये सुविधाएँ फ़ायरवॉल के कॉन्फ़िगरेशन और सत्यापन को बहुत जटिल करती हैं।

चूंकि कुबर्नेटेस सिस्टम के सभी डेटा को etcd में सिस्टम की स्थिति के बारे में बताता है, इसलिए डायनेमिक फ़ायरवॉल को कॉन्फ़िगर करना संभव है - यदि CNI नेटवर्क प्लगइन में आवश्यक समर्थन है। कैलिको, सिलियम, क्यूब-राउटर, रोमाना और वीव नेट - ये सभी प्लगइन्स नेटवर्क नीतियों का समर्थन करते हैं।

यह ध्यान रखना महत्वपूर्ण है कि नीतियां विफल-बंद सिद्धांत पर काम करती हैं, अर्थात, डिफ़ॉल्ट रूप से यहां podSelector की अनुपस्थिति सभी संभावित मूल्यों (वाइल्डकार्ड) के बराबर है:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny spec: podSelector:

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

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: myapp-deny-external-egress spec: podSelector: matchLabels: app: myapp policyTypes: - Egress egress: - ports: - port: 53 protocol: UDP - to: - namespaceSelector: {}

Kubernetes नेटवर्क नीतियों को DNS नामों पर लागू नहीं किया जा सकता है। इसका कारण यह है कि DNS कई IP पतों पर राउंड-रॉबिन का समर्थन करता है और podSelector IP पर निर्भर डायनेमिक प्रतिक्रियाएँ, इसलिए नेटवर्क नीतियाँ केवल निश्चित IP पतों या podSelector (Kubernetes डायनामिक IP पतों के लिए) पर लागू होती हैं।

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

 k8s: # used for Kubernetes pods deployment: # only deployments currently supported test-frontend: # pod name, defaults to `default` namespace test-microservice: 80 # `test-microservice` is the DNS name of the target service test-database: -80 # `test-frontend` should not be able to access test-database's port 80 169.254.169.254: -80, -443 # AWS metadata API metadata.google.internal: -80, -443 # GCP metadata API new-namespace:test-microservice: # `new-namespace` is the namespace name test-database.new-namespace: 80 # longer DNS names can be used for other namespaces test-frontend.default: 80 169.254.169.254: -80, -443 # AWS metadata API metadata.google.internal: -80, -443 # GCP metadata API

क्लाउड प्रदाता से मेटाडेटा API संभावित वृद्धि का एक निरंतर स्रोत है ( Shopify के हाल के बग बाउंटी द्वारा प्रदर्शित), इसलिए विशेष परीक्षण यह पुष्टि करते हैं कि कंटेनर नेटवर्क पर एपीआई अवरुद्ध है, कॉन्फ़िगरेशन त्रुटियों से बचाने में मदद करेगा।

10. स्कैन छवियों और आईडीएस चलाते हैं

वेब सर्वर उन नेटवर्क पर हमला करने के लिए एक स्प्रिंगबोर्ड हैं जिनसे वे जुड़े हुए हैं। छवियों में स्थापित फ़ाइलों को स्कैन करने से आप यह सत्यापित कर सकते हैं कि कोई ज्ञात भेद्यता नहीं है जो एक हमलावर कंटेनर में दूरस्थ पहुंच प्राप्त करने के लिए उपयोग कर सकता है। घुसपैठ डिटेक्शन सिस्टम (आईडीएस) इन घटनाओं को रिकॉर्ड करते हैं यदि वे होते हैं।

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

इन वेबहूक को कंटेनर छवि स्कैनिंग उपकरण द्वारा छवियों को सत्यापित करने के लिए उपयोग किया जा सकता है इससे पहले कि वे क्लस्टर पर तैनात हों। सत्यापन विफल होने वाली छवियों को नियंत्रक अनुमोदन प्राप्त नहीं होगा।

ज्ञात कमजोरियों के लिए कंटेनर छवियों को स्कैन करने से उस समय को कम करने में मदद मिलती है जो एक हमलावर खुले सीवीई का लाभ उठा सकता है। तैनाती पाइपलाइन में महत्वपूर्ण भेद्यताओं के साथ छवियों को बाहर निकालने से रोकने के लिए, आप कोर से क्लेयर और एक्वा से माइक्रो स्कैनर जैसी मुफ्त उपयोगिताओं का उपयोग कर सकते हैं।

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

अज्ञात 0day भेद्यताएं हमेशा मौजूद रहेंगी, इसलिए कुबेरनेट्स को एक घुसपैठ का पता लगाने वाली प्रणाली जैसे ट्विस्टलॉक , एक्वा या सिस्डिग सिक्योर को तैनात करना चाहिए। आईडीएस कंटेनर में असामान्य व्यवहार का पता लगाता है और इसे रोकता या मारता है। Sysdig का Falco एक ओपन सोर्स रूल इंजन है और इस इकोसिस्टम के लिए शुरुआती बिंदु है।

भाग 3: भविष्य

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

11. सर्विस मेष लॉन्च करें

सेवा जाल "साइड-कनेक्टेड" ("साइडकार" के समान) , एनवॉय और लिंकरड जैसे उच्च-प्रदर्शन प्रॉक्सी सर्वर के बीच बने लगातार एन्क्रिप्टेड कनेक्शन का एक नेटवर्क है। यह ट्रैफ़िक प्रबंधन, निगरानी और नीतियां लाता है - सभी बिना माइक्रोसॉफ़्ट के परिवर्तन के।

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

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

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

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

निष्कर्ष

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

सुरक्षा के लिए उपयोगिताएं पहले से कहीं अधिक सुलभ हैं, हालांकि, हमले की क्षमता और गलत कॉन्फ़िगरेशन की क्षमता को कम करने के लिए, आपको सावधानी के साथ उनका उपयोग करना चाहिए।

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

व्यापक परीक्षण सूट के साथ तेज, वृद्धिशील सुरक्षा सुधार सबसे आसान तरीका है। Continuous Security — pipeline', , , .

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

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

कुबेरनेट्स में हैकिंग का शिकार बनने के 11 तरीके (नहीं)