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

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

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

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

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

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

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

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

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

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

अन्य कुबेरनेट्स संसाधनों की तरह, नेटवर्क नीतियां 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: इंगित करता है कि इसमें किस प्रकार की नीतियां शामिल हैं: प्रवेश और/या निकास - वैकल्पिक, लेकिन मैं सभी मामलों में इसे स्पष्ट रूप से निर्दिष्ट करने की अनुशंसा करता हूं;
3. ingress: अनुमति परिभाषित करता है आने वाली लक्ष्य पॉड्स पर ट्रैफ़िक - वैकल्पिक;
4. egress: अनुमति परिभाषित करता है जावक लक्ष्य पॉड्स से ट्रैफ़िक वैकल्पिक है।

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

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, अन्य मापदंडों का उपयोग इच्छानुसार किया जा सकता है।

यदि आप छोड़ दें 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 पॉलिसी में उस नेमस्पेस से पॉड्स का चयन किया जाएगा जिससे पॉलिसी संबंधित है (इसे किसी अन्य नेमस्पेस से पॉड्स तक पहुंच से वंचित किया गया है)।

इसी प्रकार, podSelectors प्रवेश और निकास ब्लॉकों में केवल अपने स्वयं के नामस्थान से पॉड्स का चयन कर सकते हैं, जब तक कि आप निश्चित रूप से उन्हें संयोजित न करें 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 सुनिश्चित करें कि आपके द्वारा चुने गए नामस्थानों में सही लेबल है. ध्यान रखें कि अंतर्निहित नामस्थान जैसे 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 पर विशेष ध्यान दें - कुबेरनेट्स इस सेवा का उपयोग सेवाओं को आईपी पते पर मैप करने के लिए करता है। उदाहरण के लिए, निम्न नीति काम नहीं करेगी क्योंकि आपने एप्लिकेशन को अनुमति नहीं दी है 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

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

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

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

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

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. DNS क्वेरीज़ को केवल नेमस्पेस में ही अनुमति दें kube-system.

ऐसा करने के लिए आपको नेमस्पेस में एक लेबल जोड़ना होगा kube-system: kubectl label namespace kube-system namespace=kube-system - और इसे पॉलिसी में लिख लें namespaceSelector:

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. पागल लोग इससे भी आगे जा सकते हैं और DNS प्रश्नों को एक विशिष्ट DNS सेवा तक सीमित कर सकते हैं kube-system. अनुभाग "नेमस्पेस और पॉड्स द्वारा फ़िल्टर करें" आपको बताएगा कि इसे कैसे प्राप्त किया जाए।

एक अन्य विकल्प नेमस्पेस स्तर पर 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 नेमस्पेस में सभी पॉड्स का चयन करता है।

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

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

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

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

स्ट्रिपिंग नियम ("अस्वीकार करें")

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

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

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) नेमस्पेस में default:

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

निम्नलिखित नीति क्लस्टर के बाहर किसी भी आईपी तक पहुंच सहित सभी प्रवेश और निकास ट्रैफ़िक की अनुमति देती है:

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

अनेक नीतियों का संयोजन

नीतियों को तार्किक OR का उपयोग करके तीन स्तरों पर संयोजित किया जाता है; प्रत्येक पॉड की अनुमतियाँ उसे प्रभावित करने वाली सभी नीतियों के विच्छेदन के अनुसार निर्धारित की जाती हैं:

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

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

इसके अलावा, उपखंडों में तत्वों की संख्या (समान वाले भी)। from/to सीमित नहीं। उन सभी को तार्किक OR द्वारा संयोजित किया जाएगा।

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 कई तत्व हो सकते हैं from (तार्किक OR द्वारा संयुक्त)। इसी प्रकार, अनुभाग egress कई तत्व शामिल हो सकते हैं to (विच्छेद द्वारा भी संयुक्त):

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 (Ingress या Egress). प्रवेश (या निकास) को परिभाषित करने वाली नीतियां एक-दूसरे को अधिलेखित कर देंगी।

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

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

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

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 पॉड्स तक पहुंच होगी postgres नेमस्पेस में database. लेकिन क्या होगा यदि आप पहुंच खोलना चाहते हैं postgres नेमस्पेस में केवल विशिष्ट पॉड्स default?

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

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

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

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

ध्यान दें कि podSelector हाइफ़न से प्रारंभ नहीं होता. YAML में इसका मतलब यह है podSelector और उसके सामने खड़ा है namespaceSelector उसी सूची तत्व को देखें। इसलिए, वे तार्किक AND के साथ संयुक्त हैं।

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

एक विशिष्ट लेबल के साथ पॉड्स का चयन करना सभी नामस्थानों में, रिक्त दर्ज करें 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

एकाधिक लेबल I के साथ मिलकर काम करते हैं

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

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

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

podSelector:
  matchLabels:
    role: db
    version: v2

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

सबनेट और आईपी पते (आईपीब्लॉक)

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

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

सबनेट (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 तक पहुंच की अनुमति देती है; किसी अन्य आईपी तक पहुंच निषिद्ध है। तो, संक्षेप में, आपने आंतरिक कुबेरनेट्स डीएनएस सेवा तक पहुंच को अवरुद्ध कर दिया है। यदि आप अभी भी इसे खोलना चाहते हैं, तो इसे स्पष्ट रूप से इंगित करें।

आमतौर पर 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

आप पॉड्स के आंतरिक आईपी पते को छोड़कर, केवल बाहरी आईपी तक पहुंच खोल सकते हैं। उदाहरण के लिए, यदि आपके पॉड का सबनेट 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 ब्लॉक के सभी तत्वों पर लागू होता है to या from, जिसमें है। तत्वों के विभिन्न सेटों के लिए अलग-अलग पोर्ट निर्दिष्ट करने के लिए, स्प्लिट करें ingress या egress के साथ कई उपधाराओं में to या from और प्रत्येक में अपने पोर्ट पंजीकृत करें:

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

डिफ़ॉल्ट पोर्ट ऑपरेशन:

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

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

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

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

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

उदाहरण के लिए, यदि कोई सेवा पोर्ट 80 को सुनती है, लेकिन ट्रैफ़िक को उसके पॉड के पोर्ट 8080 पर पुनर्निर्देशित करती है, तो आपको नेटवर्क नीति में बिल्कुल 8080 निर्दिष्ट करना होगा।

इस तरह के तंत्र को उप-इष्टतम माना जाना चाहिए: यदि सेवा की आंतरिक संरचना (जिन पोर्ट के पॉड सुनते हैं) में परिवर्तन होता है, तो नेटवर्क नीतियों को अद्यतन करना होगा।

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

क्या प्रवेश और निकास दोनों को पंजीकृत करना आवश्यक है?

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

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

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

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

नीचे स्टेटफुल या स्टेटलेस देखें।

लॉग

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

बाहरी सेवाओं के लिए यातायात का नियंत्रण

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

नीति जांच

फ़ायरवॉल आपको चेतावनी देगा या गलत नीति को स्वीकार करने से इंकार भी करेगा। कुबेरनेट्स कुछ सत्यापन भी करता है। Kubectl के माध्यम से नेटवर्क नीति सेट करते समय, Kubernetes यह घोषणा कर सकता है कि यह गलत है और इसे स्वीकार करने से इंकार कर सकता है। अन्य मामलों में, कुबेरनेट्स पॉलिसी लेगा और इसे लापता विवरण के साथ भर देगा। उन्हें कमांड का उपयोग करके देखा जा सकता है:

kubernetes get networkpolicy <policy-name> -o yaml

ध्यान रखें कि कुबेरनेट्स सत्यापन प्रणाली अचूक नहीं है और कुछ प्रकार की त्रुटियाँ छूट सकती हैं।

निष्पादन

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

ध्यान दें कि यदि आप उपयुक्त सहायक सीएनआई के बिना नेटवर्क नीति सेट करते हैं तो कुबेरनेट्स आपको चेतावनी नहीं देगा।

स्टेटफुल या स्टेटलेस?

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

उन्नत सुरक्षा नीति प्रबंधन

कुबेरनेट्स में सुरक्षा नीति प्रवर्तन को बेहतर बनाने के कुछ तरीके यहां दिए गए हैं:

1. सर्विस मेश वास्तुशिल्प पैटर्न सेवा स्तर पर विस्तृत टेलीमेट्री और यातायात नियंत्रण प्रदान करने के लिए साइडकार कंटेनरों का उपयोग करता है। उदाहरण के तौर पर हम ले सकते हैं Istio.
2. कुछ सीएनआई विक्रेताओं ने कुबेरनेट्स नेटवर्क नीतियों से आगे जाने के लिए अपने टूल का विस्तार किया है।
3. टुफ़िन ओर्का कुबेरनेट्स नेटवर्क नीतियों की दृश्यता और स्वचालन प्रदान करता है।

टफिन ओर्का पैकेज कुबेरनेट्स नेटवर्क नीतियों का प्रबंधन करता है (और उपरोक्त स्क्रीनशॉट का स्रोत है)।

अतिरिक्त जानकारी

• जीकेई से अहमत अल्प बाल्कन द्वारा तैयार की गई नेटवर्क नीतियों के उदाहरण;
• आधिकारिक कुबेरनेट्स वेबसाइट से दस्तावेज़ीकरण;
• कुबेरनेट्स नेटवर्किंग मॉडल के लिए एक गाइड;
• नेटवर्क नीतियों की जाँच के लिए स्क्रिप्ट.

निष्कर्ष

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

मुझे आशा है कि यह मार्गदर्शिका कुछ प्रश्नों को स्पष्ट करने और आपके सामने आने वाली समस्याओं को हल करने में मदद करेगी।

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

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

• "इस्टियो के साथ माइक्रोसर्विसेज पर वापस": भाग 1 (मुख्य विशेषताओं का परिचय), भाग 2 (रूटिंग, यातायात नियंत्रण), भाग 3 (सुरक्षा);
• "कुबेरनेट्स में नेटवर्किंग के लिए एक सचित्र मार्गदर्शिका": भाग 1 और 2 (नेटवर्क मॉडल, ओवरले नेटवर्क), भाग 3 (सेवाएँ और यातायात प्रसंस्करण);
• «सुरक्षा-मांग वाले वातावरण में डॉकर और कुबेरनेट्स";
• «कुबेरनेट्स सुरक्षा के लिए 9 सर्वोत्तम अभ्यास";
• «कुबेरनेट्स हैक का शिकार बनने (नहीं) के 11 तरीके'.

स्रोत: www.habr.com