सुरक्षा व्यावसायिकांसाठी कुबर्नेट्स नेटवर्क धोरणांचा परिचय

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

आज, बऱ्याच कंपन्या त्यांचे अनुप्रयोग चालविण्यासाठी कुबर्नेट्सची निवड करत आहेत. या सॉफ्टवेअरमध्ये स्वारस्य इतके जास्त आहे की काही जण Kubernetes "डेटा सेंटरसाठी नवीन ऑपरेटिंग सिस्टम" म्हणत आहेत. हळूहळू, Kubernetes (किंवा k8s) हा व्यवसायाचा एक महत्त्वाचा भाग म्हणून ओळखला जाऊ लागला आहे, ज्यासाठी नेटवर्क सुरक्षेसह परिपक्व व्यावसायिक प्रक्रियांचे आयोजन आवश्यक आहे.

सुरक्षा व्यावसायिकांसाठी जे कुबरनेटसह काम करून गोंधळलेले आहेत, वास्तविक प्रकटीकरण हे प्लॅटफॉर्मचे डीफॉल्ट धोरण असू शकते: सर्वकाही परवानगी द्या.

हे मार्गदर्शक तुम्हाला नेटवर्क धोरणांची अंतर्गत रचना समजण्यास मदत करेल; ते नियमित फायरवॉलच्या नियमांपेक्षा कसे वेगळे आहेत ते समजून घ्या. हे काही तोटे देखील कव्हर करेल आणि Kubernetes वर सुरक्षित अनुप्रयोगांना मदत करण्यासाठी शिफारसी प्रदान करेल.

Kubernetes नेटवर्क धोरणे

Kubernetes नेटवर्क पॉलिसी मेकॅनिझम तुम्हाला नेटवर्क स्तरावर (OSI मॉडेलमधील तिसरे) प्लॅटफॉर्मवर उपयोजित अनुप्रयोगांचे परस्परसंवाद व्यवस्थापित करण्यास अनुमती देते. नेटवर्क धोरणांमध्ये आधुनिक फायरवॉलच्या काही प्रगत वैशिष्ट्यांचा अभाव आहे, जसे की OSI स्तर 7 अंमलबजावणी आणि धोका शोधणे, परंतु ते नेटवर्क सुरक्षिततेचे मूलभूत स्तर प्रदान करतात जे एक चांगला प्रारंभ बिंदू आहे.

नेटवर्क धोरणे पॉड्समधील संप्रेषण नियंत्रित करतात

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

Kubernetes वेबसाइटवरून घेतलेले उदाहरण (मी बदलले 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 वगळले, धोरण सर्व रहदारी नाकारेल (खाली "स्ट्रिपिंग नियम" पहा).

डीफॉल्ट धोरण परवानगी आहे

कोणतीही धोरणे परिभाषित नसल्यास, Kubernetes सर्व रहदारीला डीफॉल्टनुसार अनुमती देते. सर्व शेंगा आपापसात माहितीची मुक्तपणे देवाणघेवाण करू शकतात. हे सुरक्षेच्या दृष्टीकोनातून विरोधाभासी वाटू शकते, परंतु लक्षात ठेवा की Kubernetes ची रचना मूळत: ऍप्लिकेशन इंटरऑपरेबिलिटी सक्षम करण्यासाठी विकसकांनी केली होती. नेटवर्क धोरणे नंतर जोडली गेली.

नेमस्पेसेस

नेमस्पेस ही कुबर्नेट्स सहयोग यंत्रणा आहे. ते एकमेकांपासून तार्किक वातावरण वेगळे करण्यासाठी डिझाइन केलेले आहेत, तर स्पेसमधील संवादास डीफॉल्टनुसार परवानगी आहे.

बहुतेक Kubernetes घटकांप्रमाणे, नेटवर्क धोरणे विशिष्ट नेमस्पेसमध्ये राहतात. ब्लॉक मध्ये 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

लेबल्स

तुम्ही पॉड्स आणि नेमस्पेस यांसारख्या कुबर्नेट्स ऑब्जेक्ट्सना सानुकूल लेबल संलग्न करू शकता. लेबल्स (लेबल - टॅग) हे मेघमधील टॅगचे समतुल्य आहेत. Kubernetes नेटवर्क धोरणे निवडण्यासाठी लेबले वापरतात शेंगाज्यावर ते लागू होतात:

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:
...

स्रोत आणि गंतव्यस्थान

फायरवॉल धोरणांमध्ये स्त्रोत आणि गंतव्यस्थानांसह नियम असतात. Kubernetes नेटवर्क धोरणे लक्ष्यासाठी परिभाषित केली जातात - पॉड्सचा एक संच ज्यावर ते लागू करतात - आणि नंतर प्रवेश आणि/किंवा बाहेर जाण्यासाठी नियम सेट करतात. आमच्या उदाहरणात, पॉलिसीचे लक्ष्य नेमस्पेसमधील सर्व पॉड्स असतील 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 या धोरणामध्ये, लक्ष्य पॉड्सवर येणारी रहदारी उघडते. दुसऱ्या शब्दांत, प्रवेश हा स्त्रोत आहे आणि लक्ष्य हे संबंधित गंतव्यस्थान आहे. त्याचप्रमाणे, निर्गमन हे गंतव्यस्थान आहे आणि लक्ष्य हे त्याचे स्त्रोत आहे.

हे दोन फायरवॉल नियमांच्या समतुल्य आहे: प्रवेश → लक्ष्य; ध्येय → उत्सर्जन.

Egress आणि DNS (महत्त्वाचे!)

बाहेर जाणारी रहदारी मर्यादित करून, DNS वर विशेष लक्ष द्या - Kubernetes ही सेवा IP पत्त्यांवर सेवांचा नकाशा तयार करण्यासाठी वापरते. उदाहरणार्थ, खालील धोरण कार्य करणार नाही कारण तुम्ही अर्जाला परवानगी दिली नाही balance 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
  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 क्वेरी योग्य Kubernetes सेवेकडे पाठवा (सामान्यतः स्पेसमध्ये चालू 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 नेमस्पेसमधील सर्व पॉड्स निवडते.

पहिला सामना आणि नियम क्रम

पारंपारिक फायरवॉलमध्ये, पॅकेटवरील क्रिया (अनुमती द्या किंवा नकार द्या) पहिल्या नियमाद्वारे निर्धारित केली जाते ज्याचे समाधान होते. कुबर्नेट्समध्ये, धोरणांचा क्रम काही फरक पडत नाही.

डीफॉल्टनुसार, जेव्हा कोणतीही धोरणे सेट केलेली नसतात, तेव्हा पॉडमधील संप्रेषणांना परवानगी असते आणि ते माहितीची मुक्तपणे देवाणघेवाण करू शकतात. एकदा तुम्ही पॉलिसी बनवायला सुरुवात केली की, त्यापैकी किमान एकाने प्रभावित प्रत्येक पॉड निवडलेल्या सर्व पॉलिसींच्या विघटन (तार्किक 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) नेमस्पेसमध्ये 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 सह भिन्न धोरणे देखील एकत्र केली जातात

पण ते एकत्र करताना, त्यावर एक मर्यादा आहे निदर्शनास आणून दिले ख्रिस कुनी: Kubernetes फक्त भिन्न धोरणे एकत्र करू शकतात 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?

नेमस्पेसेस आणि पॉड्सनुसार फिल्टर करा

Kubernetes आवृत्ती 1.11 आणि उच्च तुम्हाला ऑपरेटर एकत्र करण्यास अनुमती देते namespaceSelector и podSelector तार्किक आणि वापरणे. हे असे दिसते:

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

हेच तर्क सर्व प्रकारच्या ऑपरेटरना लागू होते: धोरण लक्ष्य निवडक, पॉड निवडक आणि नेमस्पेस निवडक.

सबनेट आणि IP पत्ते (IPBlocks)

फायरवॉल नेटवर्कचे विभाजन करण्यासाठी VLAN, IP पत्ते आणि सबनेट वापरतात.

Kubernetes मध्ये, IP पत्ते पॉड्सना आपोआप नियुक्त केले जातात आणि ते वारंवार बदलू शकतात, म्हणून लेबले नेटवर्क धोरणांमध्ये पॉड्स आणि नेमस्पेस निवडण्यासाठी वापरली जातात.

सबनेट (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 मध्ये प्रवेशास अनुमती देते; इतर कोणत्याही IP वर प्रवेश प्रतिबंधित आहे. तर, थोडक्यात, तुम्ही अंतर्गत Kubernetes DNS सेवेचा प्रवेश अवरोधित केला आहे. तुम्हाला अजूनही ते उघडायचे असल्यास, हे स्पष्टपणे सूचित करा.

सहसा ipBlocks и podSelectors परस्पर अनन्य आहेत, कारण पॉड्सचे अंतर्गत IP पत्ते यामध्ये वापरले जात नाहीत ipBlocks. सूचित करून अंतर्गत आयपी पॉड्स, तुम्ही या पत्त्यांसह पॉड्सशी/वरून कनेक्शनला अनुमती द्याल. सराव मध्ये, कोणता IP पत्ता वापरायचा हे तुम्हाला कळणार नाही, म्हणूनच ते पॉड्स निवडण्यासाठी वापरले जाऊ नयेत.

प्रति-उदाहरण म्हणून, खालील धोरणामध्ये सर्व IP समाविष्ट आहेत आणि त्यामुळे इतर सर्व पॉड्समध्ये प्रवेश करण्याची परवानगी देते:

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 ब्लॉकमधील सर्व घटकांना लागू होते 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), याचा अर्थ TCP;
• आपण पोर्ट व्याख्या वगळल्यास (port), याचा अर्थ सर्व पोर्ट.

सर्वोत्तम सराव: डीफॉल्ट मूल्यांवर अवलंबून राहू नका, तुम्हाला काय हवे आहे ते स्पष्टपणे निर्दिष्ट करा.

कृपया लक्षात घ्या की तुम्ही पॉड पोर्ट वापरणे आवश्यक आहे, सर्व्हिस पोर्ट नाही (याविषयी पुढील परिच्छेदात अधिक).

पॉड्स किंवा सेवांसाठी धोरणे परिभाषित आहेत का?

सामान्यतः, कुबर्नेट्समधील पॉड्स सेवेद्वारे एकमेकांना प्रवेश देतात - एक आभासी लोड बॅलन्सर जो सेवा लागू करणाऱ्या पॉड्सवर रहदारी पुनर्निर्देशित करतो. तुम्हाला वाटेल की नेटवर्क धोरणे सेवांमध्ये प्रवेश नियंत्रित करतात, परंतु असे नाही. Kubernetes नेटवर्क पॉलिसी पॉड पोर्टवर काम करतात, सर्व्हिस पोर्टवर नाही.

उदाहरणार्थ, जर एखादी सेवा पोर्ट 80 ऐकत असेल, परंतु त्याच्या पॉड्सच्या पोर्ट 8080 वर रहदारी पुनर्निर्देशित करत असेल, तर तुम्ही नेटवर्क पॉलिसीमध्ये नक्की 8080 निर्दिष्ट करणे आवश्यक आहे.

अशी यंत्रणा सबऑप्टिमल मानली पाहिजे: जर सेवेची अंतर्गत रचना (ज्या पोर्टचे पॉड ऐकतात) बदलल्यास, नेटवर्क धोरणे अद्यतनित करावी लागतील.

सेवा जाळी वापरून नवीन आर्किटेक्चरल दृष्टीकोन (उदाहरणार्थ, खाली Istio बद्दल पहा - अंदाजे भाषांतर.) आपल्याला या समस्येचा सामना करण्यास अनुमती देते.

प्रवेश आणि निर्गमन या दोन्हींची नोंदणी करणे आवश्यक आहे का?

लहान उत्तर होय आहे, पॉड ए ला पॉड बी शी संवाद साधण्यासाठी, त्याला आउटगोइंग कनेक्शन तयार करण्याची परवानगी असणे आवश्यक आहे (यासाठी तुम्हाला एग्रेस पॉलिसी कॉन्फिगर करणे आवश्यक आहे), आणि पॉड बी इनकमिंग कनेक्शन स्वीकारण्यास सक्षम असणे आवश्यक आहे ( यासाठी, त्यानुसार, तुम्हाला प्रवेश धोरण आवश्यक आहे. धोरण).

तथापि, व्यवहारात, आपण एक किंवा दोन्ही दिशानिर्देशांमध्ये कनेक्शनला अनुमती देण्यासाठी डीफॉल्ट धोरणावर अवलंबून राहू शकता.

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

तसंच पॉडचं नशीब असतंपत्ता, एक किंवा अधिक द्वारे निवडले प्रवेश करणे-राजकारणी, त्यांच्या वियोगाने ठरवले जातील. या प्रकरणात, आपण त्यास स्त्रोत पॉडमधून रहदारी प्राप्त करण्यास स्पष्टपणे अनुमती दिली पाहिजे. जर पॉड कोणत्याही पॉलिसीद्वारे निवडला नसेल, तर त्याच्यासाठी सर्व प्रवेश ट्रॅफिक डीफॉल्टनुसार अनुमत आहे.

खाली स्टेटफुल किंवा स्टेटलेस पहा.

नोंदी

Kubernetes नेटवर्क धोरणे रहदारी लॉग करू शकत नाहीत. हे धोरण उद्दिष्टानुसार कार्य करत आहे की नाही हे निर्धारित करणे कठीण करते आणि सुरक्षा विश्लेषणास मोठ्या प्रमाणात गुंतागुंत करते.

बाह्य सेवांवरील रहदारीचे नियंत्रण

Kubernetes नेटवर्क धोरणे तुम्हाला एग्रेस विभागांमध्ये पूर्ण पात्र डोमेन नाव (DNS) निर्दिष्ट करण्याची परवानगी देत ​​नाहीत. निश्चित IP पत्ता नसलेल्या बाह्य गंतव्यस्थानांवर रहदारी मर्यादित करण्याचा प्रयत्न करताना या वस्तुस्थितीमुळे लक्षणीय गैरसोय होते (जसे की aws.com).

पॉलिसी चेक

फायरवॉल तुम्हाला चेतावणी देतील किंवा चुकीचे धोरण स्वीकारण्यास नकारही देतील. कुबर्नेट्स काही पडताळणी देखील करतात. kubectl द्वारे नेटवर्क धोरण सेट करताना, Kubernetes ते चुकीचे असल्याचे घोषित करू शकतात आणि ते स्वीकारण्यास नकार देऊ शकतात. इतर प्रकरणांमध्ये, Kubernetes पॉलिसी घेतील आणि गहाळ तपशीलांसह ते भरतील. ते कमांड वापरून पाहिले जाऊ शकतात:

kubernetes get networkpolicy <policy-name> -o yaml

लक्षात ठेवा की कुबर्नेट्स प्रमाणीकरण प्रणाली अचूक नाही आणि काही प्रकारच्या त्रुटी चुकवू शकतात.

अंमलबजावणी

Kubernetes स्वतः नेटवर्क धोरणांची अंमलबजावणी करत नाही, परंतु केवळ एक API गेटवे आहे जो कंटेनर नेटवर्किंग इंटरफेस (CNI) नावाच्या अंतर्निहित प्रणालीवर नियंत्रणाचा भार सोपवतो. कुबर्नेट्स क्लस्टरवर योग्य CNI नियुक्त न करता धोरणे सेट करणे हे फायरवॉल व्यवस्थापन सर्व्हरवर फायरवॉलवर स्थापित न करता पॉलिसी तयार करण्यासारखेच आहे. तुमच्याकडे सभ्य CNI असल्याची खात्री करणे किंवा, कुबर्नेट्स प्लॅटफॉर्मच्या बाबतीत, क्लाउडमध्ये होस्ट केलेले आहे. (आपण प्रदात्यांची यादी पाहू शकता येथे - अंदाजे ट्रान्स.), नेटवर्क धोरणे सक्षम करा जी तुमच्यासाठी CNI सेट करेल.

लक्षात घ्या की तुम्ही योग्य मदतनीस CNI शिवाय नेटवर्क धोरण सेट केल्यास कुबर्नेट्स तुम्हाला चेतावणी देणार नाहीत.

स्टेटफुल की स्टेटलेस?

मला आढळलेले सर्व कुबर्नेट्स सीएनआय स्टेटफुल आहेत (उदाहरणार्थ, कॅलिको लिनक्स कॉन्ट्रॅक वापरते). हे पॉडला ते पुन्हा स्थापित न करता सुरू केलेल्या TCP कनेक्शनवर प्रतिसाद प्राप्त करण्यास अनुमती देते. तथापि, मला कुबर्नेट्स मानकांबद्दल माहिती नाही जे स्टेटफुलनेसची हमी देईल.

प्रगत सुरक्षा धोरण व्यवस्थापन

कुबर्नेट्समध्ये सुरक्षा धोरणाची अंमलबजावणी सुधारण्याचे काही मार्ग येथे आहेत:

1. सर्व्हिस मेश आर्किटेक्चरल पॅटर्न सेवा स्तरावर तपशीलवार टेलीमेट्री आणि रहदारी नियंत्रण प्रदान करण्यासाठी साइडकार कंटेनरचा वापर करते. उदाहरण म्हणून आपण घेऊ शकतो इस्टिओ.
2. काही CNI विक्रेत्यांनी Kubernetes नेटवर्क धोरणांच्या पलीकडे जाण्यासाठी त्यांची साधने वाढवली आहेत.
3. तुफिन ओरका Kubernetes नेटवर्क धोरणांची दृश्यमानता आणि ऑटोमेशन प्रदान करते.

Tufin Orca पॅकेज Kubernetes नेटवर्क धोरणे व्यवस्थापित करते (आणि वरील स्क्रीनशॉटचा स्रोत आहे).

अतिरिक्त माहिती

• GKE कडून अहमद अल्प बाल्कन यांनी तयार केलेल्या नेटवर्क धोरणांची उदाहरणे;
• अधिकृत Kubernetes वेबसाइटवरून दस्तऐवज;
• कुबर्नेट्स नेटवर्किंग मॉडेलसाठी मार्गदर्शक;
• नेटवर्क धोरणे तपासण्यासाठी स्क्रिप्ट.

निष्कर्ष

Kubernetes नेटवर्क धोरणे क्लस्टर्सचे विभाजन करण्यासाठी साधनांचा चांगला संच देतात, परंतु ते अंतर्ज्ञानी नसतात आणि त्यात अनेक सूक्ष्मता असतात. या गुंतागुंतीमुळे, मला विश्वास आहे की अनेक विद्यमान क्लस्टर धोरणे बग्गी आहेत. या समस्येच्या संभाव्य उपायांमध्ये स्वयंचलित धोरण व्याख्या किंवा इतर विभाजन साधने वापरणे समाविष्ट आहे.

मला आशा आहे की हे मार्गदर्शक काही प्रश्नांचे निराकरण करण्यात आणि तुम्हाला भेडसावणाऱ्या समस्यांचे निराकरण करण्यात मदत करेल.

अनुवादकाकडून पुनश्च

आमच्या ब्लॉगवर देखील वाचा:

• "इस्टिओसह मायक्रो सर्व्हिसेसकडे परत जा": भाग १ (मुख्य वैशिष्ट्यांचा परिचय), भाग २ (मार्ग, वाहतूक नियंत्रण), भाग 3 (सुरक्षा);
• "कुबर्नेट्समधील नेटवर्किंगसाठी सचित्र मार्गदर्शक": भाग १ आणि २ (नेटवर्क मॉडेल, आच्छादन नेटवर्क), भाग 3 (सेवा आणि वाहतूक प्रक्रिया);
• «सुरक्षा-मागणी वातावरणात डॉकर आणि कुबर्नेट्स";
• «कुबर्नेट्स सुरक्षिततेसाठी 9 सर्वोत्तम पद्धती";
• «कुबर्नेट्स हॅकचा बळी बनण्याचे (नाही) 11 मार्ग».

स्त्रोत: www.habr.com