सुरक्षा पेशेवरों के लिए कुबेरनेट्स नेटवर्क नीतियों का परिचय

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

आज, कई कंपनियां तेजी से अपने आवेदन चलाने के लिए कुबेरनेट का चयन कर रही हैं। इस सॉफ़्टवेयर में रुचि इतनी अधिक है कि कुछ लोग कुबेरनेट्स को "नया डेटा सेंटर ऑपरेटिंग सिस्टम" कहते हैं। धीरे-धीरे, कुबेरनेट्स (या k8s) को व्यवसाय का एक महत्वपूर्ण हिस्सा माना जाता है, जिसके लिए नेटवर्क सुरक्षा सहित परिपक्व व्यावसायिक प्रक्रियाओं के संगठन की आवश्यकता होती है।

कुबेरनेट्स के साथ काम करने वाले सुरक्षा पेशेवरों के लिए, इस प्लेटफ़ॉर्म की डिफ़ॉल्ट नीति एक वास्तविक खोज हो सकती है: इसे सभी की अनुमति दें।

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

कुबेरनेट्स नेटवर्क नीतियां

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

नेटवर्क नीतियां पॉड्स के बीच संचार को नियंत्रित करती हैं

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

नेटवर्क नीतियों को परिभाषित करना

कुबेरनेट के अन्य संसाधनों की तरह, नेटवर्क नीतियाँ YAML में सेट की गई हैं। नीचे दिए गए उदाहरण में, balance postgres तक पहुंच दी गई है:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.postgres namespace: default spec: podSelector: matchLabels: app: postgres ingress: - from: - podSelector: matchLabels: app: balance policyTypes: - Ingress 

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

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

YAML में नीति का वर्णन करने के बाद, इसे क्लस्टर में बनाने के लिए kubectl का उपयोग करें:

 kubectl create -f policy.yaml 

नेटवर्क नीति विशिष्टता

कुबेरनेट नेटवर्क नीति विनिर्देश में चार तत्व शामिल हैं:

1. podSelector : इस नीति (लक्ष्यों) से प्रभावित फली को परिभाषित करता है - अनिवार्य;
2. policyTypes : इंगित करता है कि इसमें किस प्रकार की नीतियां शामिल हैं: policyTypes और / या प्रगति - वैकल्पिक, हालांकि, मेरा सुझाव है कि आप इसे स्पष्ट रूप से सभी मामलों में पंजीकृत करें;
3. ingress : लक्षित पॉड्स के लिए अनुमत आने वाले ट्रैफ़िक को परिभाषित करता है - वैकल्पिक;
4. egress : लक्षित पॉड्स से वैकल्पिक रूप से आउटगोइंग ट्रैफ़िक को परिभाषित करता है - वैकल्पिक।

कुबेरनेट्स वेबसाइट से उधार लिया गया एक उदाहरण (मैंने app साथ role को बदल दिया) दिखाता है कि सभी चार तत्वों का उपयोग कैसे किया जाता है:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-network-policy namespace: default spec: podSelector: # <<< matchLabels: app: db policyTypes: # <<< - Ingress - Egress ingress: # <<< - from: - ipBlock: cidr: 172.17.0.0/16 except: - 172.17.1.0/24 - namespaceSelector: matchLabels: project: myproject - podSelector: matchLabels: role: frontend ports: - protocol: TCP port: 6379 egress: # <<< - to: - ipBlock: cidr: 10.0.0.0/24 ports: - protocol: TCP port: 5978 

कृपया ध्यान दें कि सभी चार तत्व वैकल्पिक हैं। केवल podSelector की podSelector , अन्य मापदंडों को वांछित के रूप में इस्तेमाल किया जा सकता है।

यदि आप पॉलिसी को छोड़ policyTypes , तो पॉलिसी की व्याख्या इस प्रकार की जाएगी:

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

त्रुटियों से बचने के लिए, मैं हमेशा policyTypes स्पष्ट रूप से निर्दिष्ट करने की सलाह देता policyTypes ।

उपरोक्त तर्क के अनुसार, अगर ingress और / या egress को छोड़ दिया जाता है, तो नीति सभी ट्रैफ़िक को प्रतिबंधित कर देगी (नीचे "स्ट्रिपिंग नियम" देखें)।

डिफ़ॉल्ट नीति को अनुमति देना है

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

नामस्थान

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

अधिकांश कुबेरनेट घटकों की तरह, नेटवर्क नीतियां एक विशिष्ट नाम स्थान पर रहती हैं। metadata ब्लॉक में, आप यह निर्दिष्ट कर सकते हैं कि नीति किस स्थान की है:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-network-policy namespace: my-namespace # <<< spec: ... 

यदि नामस्थान स्पष्ट रूप से मेटाडेटा में नहीं लिखा गया है, तो सिस्टम kubectl में निर्दिष्ट नामस्थान (डिफ़ॉल्ट namespace=default ) का उपयोग करेगा:

 kubectl apply -n my-namespace -f namespace.yaml 

जब तक आप एक से अधिक नामस्थानों के लिए एक नीति नहीं लिख रहे हैं, तब तक मैं स्पष्ट रूप से एक नामस्थान निर्दिष्ट करने की सलाह देता हूं।

एक नीति में मुख्य podSelector तत्व नेमस्पेस से पॉड्स का चयन करेगा, जो पॉलिसी के अंतर्गत आता है (इसे किसी अन्य नाम स्थान से पॉड्स तक पहुंच से वंचित किया जाता है)।

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

नीति नामकरण नियम

एकल नामस्थान में नीति नाम अद्वितीय हैं। एक ही स्थान में एक ही नाम के साथ दो नीतियां नहीं हो सकती हैं, लेकिन विभिन्न स्थानों में एक ही नाम के साथ नीतियां हो सकती हैं। यह उपयोगी है जब आप कई स्थानों पर एक ही नीति को फिर से लागू करना चाहते हैं।

मुझे नामकरण का एक तरीका विशेष रूप से पसंद है। इसमें टारगेट पॉड्स के साथ नेमस्पेस नाम का संयोजन होता है। उदाहरण के लिए:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.postgres # <<< namespace: default spec: podSelector: matchLabels: app: postgres ingress: - from: - podSelector: matchLabels: app: admin policyTypes: - Ingress 

लेबल

कस्टम लेबलों को कुबेरनेट्स ऑब्जेक्ट्स से जोड़ा जा सकता है, जैसे फली और नाम स्थान। क्लाउड में टैग्स के बराबर लेबल होते हैं। कुबेरनेट नेटवर्क नीतियां उन पॉड्स का चयन करने के लिए लेबल का उपयोग करती हैं, जिन पर वे लागू होते हैं:

 podSelector: matchLabels: role: db 

... या जिन नामों पर वे लागू होते हैं। इस उदाहरण में, संबंधित लेबल वाले नेमस्पेस में सभी पॉड्स चुने गए हैं:

 namespaceSelector: matchLabels: project: myproject 

एक कैविएट: namespaceSelector का उपयोग करते समय namespaceSelector सुनिश्चित करें कि आपके द्वारा चुने गए namespaceSelector में वह लेबल है जो आप चाहते हैं । ध्यान रखें कि अंतर्निहित नामस्थान जैसे default और kube-system में डिफ़ॉल्ट रूप से लेबल नहीं होते हैं।

आप निम्नानुसार अंतरिक्ष में एक लेबल जोड़ सकते हैं:

 kubectl label namespace default namespace=default 

इस मामले में, metadata अनुभाग में नाम स्थान का वास्तविक नाम, और लेबल पर नहीं होना चाहिए:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-network-policy namespace: default # <<< spec: ... 

स्रोत और गंतव्य

फ़ायरवॉल के लिए नीतियों में स्रोतों और स्थलों के साथ नियम शामिल हैं। कुबेरनेट्स नेटवर्क नीतियों को इस उद्देश्य के लिए परिभाषित किया गया है - फली का एक सेट, जिस पर उन्हें लागू किया जाता है, और फिर आने वाले (इंग्रेस) और / या आउटगोइंग (ईग्रेस) ट्रैफ़िक के लिए नियम स्थापित करते हैं। हमारे उदाहरण में, पॉलिसी लक्ष्य default नाम स्थान में सभी पॉड्स होंगे जिनमें app कुंजी और db मान के साथ एक लेबल है:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-network-policy namespace: default spec: podSelector: matchLabels: app: db # <<< policyTypes: - Ingress - Egress ingress: - from: - ipBlock: cidr: 172.17.0.0/16 except: - 172.17.1.0/24 - namespaceSelector: matchLabels: project: myproject - podSelector: matchLabels: role: frontend ports: - protocol: TCP port: 6379 egress: - to: - ipBlock: cidr: 10.0.0.0/24 ports: - protocol: TCP port: 5978 

इस नीति में ingress सबस्क्राइब आने वाले ट्रैफ़िक को लक्ष्य पॉड्स में खोलता है। दूसरे शब्दों में, प्रवेश स्रोत है, और लक्ष्य उपयुक्त प्राप्तकर्ता है। इसी तरह, इग्‍शन टारगेट है और टारगेट उसका स्रोत है।



यह फ़ायरवॉल के लिए दो नियमों के बराबर है: इनग्रेड → टारगेट; लक्ष्य → अदर्शन।

प्रगति और डीएनएस (महत्वपूर्ण!)

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

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.balance namespace: default spec: podSelector: matchLabels: app: balance egress: - to: - podSelector: matchLabels: app: postgres policyTypes: - Egress 

आप DNS सेवा तक पहुंच खोलकर इसे ठीक कर सकते हैं:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.balance namespace: default spec: podSelector: matchLabels: app: balance egress: - to: - podSelector: matchLabels: app: postgres - to: # <<< ports: # <<< - protocol: UDP # <<< port: 53 # <<< policyTypes: - Egress 

तत्व के लिए अंतिम खाली है, और इसलिए यह अप्रत्यक्ष रूप से सभी नामस्थानों में सभी पॉड्स का चयन करता है, जिससे DNS प्रश्नों को संबंधित कुबेरनेट्स सेवा balance भेजने की अनुमति मिलती है (यह आमतौर पर kube-system स्पेस में काम करता है)।

यह दृष्टिकोण काम करता है, लेकिन यह अत्यधिक अनुमत और असुरक्षित है , क्योंकि यह आपको क्लस्टर के बाहर DNS प्रश्नों को निर्देशित करने की अनुमति देता है।

आप इसे लगातार तीन चरणों में सुधार सकते हैं।

1. DNS में केवल namespaceSelector जोड़कर DNS क्वेरीज़ की अनुमति दें।

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.balance namespace: default spec: podSelector: matchLabels: app: balance egress: - to: - podSelector: matchLabels: app: postgres - to: - namespaceSelector: {} # <<< ports: - protocol: UDP port: 53 policyTypes: - Egress 

2. डीएनएस प्रश्नों को केवल kube-system नेमस्पेस में अनुमति दें।

ऐसा करने के लिए, kube-system kubectl label namespace kube-system namespace=kube-system एक लेबल जोड़ें: kubectl label namespace kube-system namespace=kube-system - और इसे kubectl label namespace kube-system namespace=kube-system का उपयोग करके पॉलिसी में पंजीकृत करें:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.balance namespace: default spec: podSelector: matchLabels: app: balance egress: - to: - podSelector: matchLabels: app: postgres - to: - namespaceSelector: # <<< matchLabels: # <<< namespace: kube-system # <<< ports: - protocol: UDP port: 53 policyTypes: - Egress 

3. Paranoids आगे भी जा सकते हैं और DNS प्रश्नों को kube-system में एक विशिष्ट DNS सेवा तक सीमित कर सकते हैं। "नेमस्पेस और पॉड्स द्वारा फ़िल्टर" खंड में, हम यह बताएंगे कि इसे कैसे प्राप्त किया जाए।

एक अन्य विकल्प DNS को नेमस्पेस स्तर पर हल करना है। इस स्थिति में, इसे प्रत्येक सेवा के लिए खोलने की आवश्यकता नहीं होगी:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.dns namespace: default spec: podSelector: {} # <<< egress: - to: - namespaceSelector: {} ports: - protocol: UDP port: 53 policyTypes: - Egress 

एक खाली podSelector ने नेमस्पेस में सभी पॉड्स का चयन किया।

पहला मैच और नियम क्रम

साधारण फायरवॉल में, पैकेट के लिए कार्रवाई ("अनुमति" या "इनकार") पहले नियम द्वारा निर्धारित किया जाता है कि यह संतुष्ट करता है। कुबेरनेट्स में, नीतियों का क्रम अप्रासंगिक है।

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

आप स्ट्रिपिंग नियम का उपयोग करके इस व्यवहार को बदल सकते हैं।

स्ट्रिपिंग नियम (इनकार)

फ़ायरवॉल नीतियां आम तौर पर किसी भी स्पष्ट रूप से अनधिकृत यातायात को रोकती हैं।

कुबेरनेट्स के पास इनकार करने वाली कार्रवाई नहीं है , हालांकि, स्रोत पॉड्स (इंग्रेस) के एक खाली समूह का चयन करके एक नियमित (अनुमति) नीति के साथ एक समान प्रभाव प्राप्त किया जा सकता है:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all namespace: default spec: podSelector: {} policyTypes: - Ingress 

यह नीति नेमस्पेस में सभी पॉड्स का चयन करती है और आने वाली सभी ट्रैफ़िक को अवरुद्ध करते हुए, अखंड को छोड़ देती है।

इसी तरह, आप नाम स्थान से सभी आउटगोइंग ट्रैफ़िक को सीमित कर सकते हैं:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all-egress namespace: default spec: podSelector: {} policyTypes: - Egress 

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

सभी को अनुमति दें (कोई भी-कोई भी-अनुमति दें)

सभी अनुमति नीति बनाने के लिए, आपको उपरोक्त निषेध नीति को एक खाली ingress तत्व के साथ जोड़ना होगा:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all namespace: default spec: podSelector: {} ingress: # <<< - {} # <<< policyTypes: - Ingress 

यह सभी नेमस्पेस में सभी पॉड्स (और सभी आईपी) से default नेमस्पेस में किसी भी पॉड तक पहुंच की अनुमति देता है। यह व्यवहार डिफ़ॉल्ट रूप से सक्षम है, इसलिए आमतौर पर इसे अतिरिक्त रूप से परिभाषित करने की आवश्यकता नहीं है। हालांकि, कभी-कभी समस्या के निदान के लिए कुछ विशिष्ट अनुमतियों को अस्थायी रूप से अक्षम करना आवश्यक हो सकता है।

नियम को केवल एक विशिष्ट समूह के पॉड्स ( app:balance ) तक तय किया जा सकता है।

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all-to-balance namespace: default spec: podSelector: matchLabels: app: balance ingress: - {} policyTypes: - Ingress 

निम्न नीति सभी प्रवेश और निकास ट्रैफ़िक को अनुमति देती है, जिसमें क्लस्टर के बाहर किसी भी IP तक पहुँच शामिल है:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all spec: podSelector: {} ingress: - {} egress: - {} policyTypes: - Ingress - Egress 

कई नीतियों का मेल

नीतियां तार्किक या तीन स्तरों पर संयुक्त हैं; प्रत्येक पॉड की अनुमतियाँ इसे प्रभावित करने वाली सभी नीतियों के निपटान के अनुसार निर्धारित की जाती हैं:

1. में और खेतों से आप तीन प्रकार के तत्वों को परिभाषित कर सकते हैं (उन सभी को OR का उपयोग करके जोड़ा जाता है):

• namespaceSelector - पूरे नामस्थान का चयन करता है;
• podSelector - फली का चयन करता है;
• ipBlock - एक सबनेट का चयन करता है।

एक ही समय में, तत्वों की संख्या (यहां तक ​​कि) / से to उप-वर्गों तक सीमित नहीं है। उन सभी को तार्किक या द्वारा संयुक्त किया जाएगा।

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.postgres namespace: default spec: ingress: - from: - podSelector: matchLabels: app: indexer - podSelector: matchLabels: app: admin podSelector: matchLabels: app: postgres policyTypes: - Ingress 

2. पॉलिसी के अंदर, ingress सेक्शन में कई तत्व हो सकते हैं (तार्किक या संयुक्त द्वारा)। इसी तरह, egress सेक्शन में कई तत्व शामिल हो सकते हैं (एक क्लॉज से भी जुड़े):

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.postgres namespace: default spec: ingress: - from: - podSelector: matchLabels: app: indexer - from: - podSelector: matchLabels: app: admin podSelector: matchLabels: app: postgres policyTypes: - Ingress 

3. विभिन्न नीतियां भी तार्किक OR द्वारा संयुक्त हैं

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

नामस्थानों के बीच का संबंध

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

नेमस्पेस तक पहुँच को अवरुद्ध करके (ऊपर "स्ट्रिपिंग रूल देखें"), आप नेमस्पेस के उपयोग से एक विशिष्ट नेमस्पेस से कनेक्शन की अनुमति देकर प्रतिबंधात्मक नीति को अपवाद बना सकते हैं:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: database.postgres namespace: database spec: podSelector: matchLabels: app: postgres ingress: - from: - namespaceSelector: # <<< matchLabels: namespace: default policyTypes: - Ingress 

नतीजतन, default नेमस्पेस में सभी पॉड्स database नेमस्पेस में postgres पॉड्स तक पहुंच होगी। लेकिन क्या होगा यदि आप default नाम स्थान में केवल विशिष्ट पॉड्स के लिए postgres को खोलना चाहते हैं?

नेमस्पेस और पॉड्स द्वारा फ़िल्टर करें

Kubernetes संस्करण 1.11 और उच्चतर आपको podSelector का podSelector करने की अनुमति देता है। podSelector और podSelector ऑपरेटर तार्किक I का उपयोग करते हुए। यह इस तरह दिखता है:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: database.postgres namespace: database spec: podSelector: matchLabels: app: postgres ingress: - from: - namespaceSelector: matchLabels: namespace: default podSelector: # <<< matchLabels: app: admin policyTypes: - Ingress 

इसकी व्याख्या सामान्य के बजाय और के रूप में क्यों की जाती है?

ध्यान दें कि podSelector एक हाइफ़न से शुरू नहीं होता है। podSelector , इसका मतलब है कि podSelector और इसके सामने खड़े namespaceSelector podSelector समान सूची आइटम को संदर्भित करते हैं। इसलिए, वे तार्किक I द्वारा संयुक्त हैं।

podSelector सामने एक हाइफ़न जोड़ने से एक नई सूची आइटम का परिणाम होगा जो एक तार्किक OR का उपयोग करके पिछले namespaceSelector के साथ जोड़ा जाएगा।

सभी नामस्थानों में एक विशिष्ट लेबल के साथ पॉड्स का चयन करने के लिए, एक खाली namespaceSelector दर्ज करें।

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: database.postgres namespace: database spec: podSelector: matchLabels: app: postgres ingress: - from: - namespaceSelector: {} podSelector: matchLabels: app: admin policyTypes: - Ingress 

एकाधिक लेबल AND के साथ संयोजित होते हैं

कई ऑब्जेक्ट्स (होस्ट, नेटवर्क, समूह) के साथ एक फ़ायरवॉल के लिए नियम एक तार्किक OR का उपयोग करके संयुक्त हैं। यदि पैकेट का स्रोत Host_1 या Host_2 मेल खाता है तो निम्न नियम काम करेगा:

 | Source | Destination | Service | Action | | ----------------------------------------| | Host_1 | Subnet_A | HTTPS | Allow | | Host_2 | | | | | ----------------------------------------| 

इसके विपरीत, कुबेरनेट्स में, podSelector या namespaceSelector podSelector में विभिन्न लेबल तार्किक I द्वारा संयुक्त होते हैं। उदाहरण के लिए, निम्नलिखित नियम उन पॉड्स का चयन करेंगे जिनमें लेबल, role=db और version=v2 :

 podSelector: matchLabels: role: db version: v2 

सभी प्रकार के ऑपरेटरों पर एक ही तर्क लागू होता है: पॉलिसी लक्ष्य चयनकर्ता, पॉड चयनकर्ता और नेमस्पेस चयनकर्ता।

सबनेट और आईपी पते (IPBlocks)

फ़ायरवॉल एक नेटवर्क को विभाजित करने के लिए वीएलएएन, आईपी पते और सबनेट का उपयोग करते हैं।

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

ipBlocks ( ipBlocks ) का उपयोग इनबाउंड ( ipBlocks ) या आउटबाउंड (इग्रेशन) एक्सटर्नल (नॉर्थ-साउथ) कनेक्शन को नियंत्रित करने के लिए किया जाता है। उदाहरण के लिए, यह नीति default नाम स्थान से Google DNS सेवा तक सभी पॉड्स देती है:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: egress-dns namespace: default spec: podSelector: {} policyTypes: - Egress egress: - to: - ipBlock: cidr: 8.8.8.8/32 ports: - protocol: UDP port: 53 

इस उदाहरण में खाली पॉड चयनकर्ता का अर्थ है "नाम स्थान में सभी पॉड का चयन करें।"

यह नीति केवल 8.8.8.8 तक पहुंच प्रदान करती है; किसी भी अन्य आईपी तक पहुंच से वंचित है। इस प्रकार, संक्षेप में, आपने कुबेरनेट्स आंतरिक DNS सेवा तक पहुंच को अवरुद्ध कर दिया है। यदि आप अभी भी इसे खोलना चाहते हैं, तो इसे स्पष्ट रूप से निर्दिष्ट करें।

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

एक काउंटर-उदाहरण के रूप में, निम्नलिखित नीति में सभी आईपी शामिल हैं और इसलिए, अन्य सभी पॉड्स तक पहुंच की अनुमति देता है:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: egress-any namespace: default spec: podSelector: {} policyTypes: - Egress egress: - to: - ipBlock: cidr: 0.0.0.0/0 

आप केवल बाहरी IP पोड्स के आंतरिक IP पतों को छोड़कर एक्सेस खोल सकते हैं। उदाहरण के लिए, यदि आपके पॉड का सबनेट 10.16.0.0/14 है:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: egress-any namespace: default spec: podSelector: {} policyTypes: - Egress egress: - to: - ipBlock: cidr: 0.0.0.0/0 except: - 10.16.0.0/14 

पोर्ट और प्रोटोकॉल

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

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.postgres namespace: default spec: ingress: - from: - podSelector: matchLabels: app: indexer - podSelector: matchLabels: app: admin ports: # <<< - port: 443 # <<< protocol: TCP # <<< - port: 80 # <<< protocol: TCP # <<< podSelector: matchLabels: app: postgres policyTypes: - Ingress 

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

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.postgres namespace: default spec: ingress: - from: - podSelector: matchLabels: app: indexer ports: # <<< - port: 443 # <<< protocol: TCP # <<< - from: - podSelector: matchLabels: app: admin ports: # <<< - port: 80 # <<< protocol: TCP # <<< podSelector: matchLabels: app: postgres policyTypes: - Ingress 

डिफ़ॉल्ट पोर्ट काम करते हैं:

• यदि आप पोर्ट की परिभाषा को पूरी तरह से छोड़ देते हैं, तो इसका मतलब है कि सभी प्रोटोकॉल और सभी पोर्ट;
• यदि आप प्रोटोकॉल परिभाषा छोड़ते हैं, तो इसका मतलब है कि टीसीपी;
• यदि आप किसी पोर्ट की परिभाषा को छोड़ देते हैं, तो इसका मतलब सभी पोर्ट हैं।

सर्वोत्तम अभ्यास: डिफ़ॉल्ट मानों पर भरोसा न करें, निर्दिष्ट करें कि आपको स्पष्ट रूप से क्या चाहिए।

कृपया ध्यान दें कि पॉड पोर्ट का उपयोग करना आवश्यक है, न कि सेवाओं (अगले पैराग्राफ में इस पर अधिक)।

क्या पॉड्स या सेवाओं के लिए नीतियों को परिभाषित किया गया है?

आमतौर पर कुबेरनेट्स में फली एक सेवा के माध्यम से एक दूसरे से संपर्क करती हैं - एक आभासी लोड बैलेंसर जो पॉड्स पर यातायात को पुनर्निर्देशित करता है जो सेवा को लागू करता है। आप सोच सकते हैं कि नेटवर्क नीतियां सेवाओं तक पहुंच को नियंत्रित करती हैं, लेकिन ऐसा नहीं है। कुबेरनेट नेटवर्क नीतियां पॉड पोर्ट के साथ काम करती हैं, न कि सेवाओं के लिए।

, 80- , 8080 pod', 8080.

: ( pod') .

Service Mesh (, . Istio — . .) .

Ingress, Egress?

— , pod pod' , ( egress-), pod ( , , ingress-).

, .

pod- egress -, . pod'- . pod - , (egress) .

pod'- , ingress -, . pod'-. pod - , (ingress) .

. «Stateful Stateless» .

Kubernetes . , , .

Kubernetes (DNS) egress. , IP- ( aws.com).

. Kubernetes . kubectl Kubernetes , , . Kubernetes . :

 kubernetes get networkpolicy <policy-name> -o yaml 

, Kubernetes .

Kubernetes , API-, , Container Networking Interface (CNI). Kubernetes CNI . CNI , Kubernetes, ( — . .) , , CNI .

, Kubernetes , CNI.

Stateful Stateless?

CNI Kubernetes, , (, Calico Linux conntrack). pod' TCP- . Kubernetes, (statefulness).

Kubernetes:

1. Service Mesh sidecar- . Istio .
2. CNI , Kubernetes.
3. Tufin Orca Kubernetes.

Tufin Orca Kubernetes ( , ).

• , Ahmet Alp Balkan' GKE ;
• Kubernetes ;
• Kubernetes ;
• .

निष्कर्ष

Kubernetes , . , - . .

, , .

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

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

• « Istio»: 1 ( ) , 2 (, ) , 3 () ;
• « Kubernetes»: 1 2 ( , ) , 3 ( ) ;
• « Docker Kubernetes »;
• « 9 Kubernetes »;
• « 11 () Kubernetes ».