सुरक्षा पेशेवरहरूको लागि Kubernetes नेटवर्क नीतिहरूको परिचय

नोट। अनुवाद।: लेखका लेखक, रेउभेन ह्यारिसनसँग सफ्टवेयर विकासमा २० वर्षभन्दा बढी अनुभव छ, र आज सुरक्षा नीति व्यवस्थापन समाधानहरू सिर्जना गर्ने कम्पनी टुफिनको CTO र सह-संस्थापक हुनुहुन्छ। उनले Kubernetes सञ्जाल नीतिहरूलाई क्लस्टरमा नेटवर्क विभाजनको लागि पर्याप्त शक्तिशाली उपकरणको रूपमा हेर्दा, उनी यो पनि विश्वास गर्छन् कि उनीहरूलाई व्यवहारमा लागू गर्न त्यति सजिलो छैन। यो सामग्री (धेरै मात्रामा) यस मुद्दाको विशेषज्ञहरूको जागरूकता सुधार गर्न र आवश्यक कन्फिगरेसनहरू सिर्जना गर्न मद्दत गर्नको लागि हो।

आज, धेरै कम्पनीहरूले आफ्नो अनुप्रयोगहरू चलाउनको लागि कुबेरनेटहरू बढ्दो रूपमा रोजिरहेका छन्। यस सफ्टवेयरमा रुचि यति उच्च छ कि कोहीले Kubernetes लाई "डेटा केन्द्रको लागि नयाँ अपरेटिङ सिस्टम" भनेर बोलाउँदै छन्। बिस्तारै, Kubernetes (वा k8s) लाई व्यवसायको एक महत्वपूर्ण भागको रूपमा बुझ्न थालेको छ, जसको लागि नेटवर्क सुरक्षा सहित परिपक्व व्यापार प्रक्रियाहरूको संगठन आवश्यक छ।

Kubernetes सँग काम गरेर अन्योलमा परेका सुरक्षा पेशेवरहरूको लागि, वास्तविक प्रकटीकरण प्लेटफर्मको पूर्वनिर्धारित नीति हुन सक्छ: सबै कुरालाई अनुमति दिनुहोस्।

यो गाइडले तपाईंलाई नेटवर्क नीतिहरूको आन्तरिक संरचना बुझ्न मद्दत गर्नेछ; तिनीहरू नियमित फायरवालहरूको लागि नियमहरूबाट कसरी भिन्न छन् भनेर बुझ्नुहोस्। यसले केही समस्याहरू पनि समेट्छ र Kubernetes मा सुरक्षित अनुप्रयोगहरू मद्दत गर्न सिफारिसहरू प्रदान गर्दछ।

Kubernetes नेटवर्क नीतिहरू

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

नेटवर्क नीतिहरूले पोडहरू बीचको सञ्चारलाई नियन्त्रण गर्दछ

Kubernetes मा वर्कलोडहरू पोडहरूमा वितरण गरिन्छ, जसमा एक वा धेरै कन्टेनरहरू सँगै तैनात हुन्छन्। 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

(नोट। अनुवाद।: यो स्क्रिनसट, सबै पछिल्ला समानहरू जस्तै, नेटिभ Kubernetes उपकरणहरू प्रयोग गरेर होइन, तर Tufin Orca उपकरण प्रयोग गरेर सिर्जना गरिएको हो, जुन मूल लेखको लेखकको कम्पनीद्वारा विकसित गरिएको थियो र जुन सामग्रीको अन्त्यमा उल्लेख गरिएको छ।)

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

YAML मा नीति वर्णन गरिसकेपछि, प्रयोग गर्नुहोस् kubectlयसलाई क्लस्टरमा सिर्जना गर्न:

kubectl create -f policy.yaml

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

Kubernetes नेटवर्क नीति विशिष्टताले चार तत्वहरू समावेश गर्दछ:

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 कोलाबोरेसन मेकानिजम हुन्। तिनीहरू एक-अर्काबाट तार्किक वातावरणहरू अलग गर्न डिजाइन गरिएका छन्, जबकि स्पेसहरू बीच सञ्चार पूर्वनिर्धारित रूपमा अनुमति छ।

धेरै 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 नीतिमा नामस्थानबाट पोडहरू चयन गर्नेछ जुन नीतिसँग सम्बन्धित छ (यसलाई अर्को नेमस्पेसबाट पोडहरूमा पहुँच अस्वीकार गरिएको छ)।

त्यस्तै, पोडसेलेक्टरहरू प्रवेश र निकास ब्लकहरूमा तिनीहरूको आफ्नै नेमस्पेसबाट पोडहरू मात्र चयन गर्न सक्नुहुन्छ, जबसम्म तपाईंले तिनीहरूलाई संयोजन गर्नुहुन्न 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 नामस्थानमा सबै पोडहरू चयन गर्दछ।

पहिलो खेल र नियम क्रम

परम्परागत फायरवालहरूमा, प्याकेटमा भएको कार्य (अनुमति दिनुहोस् वा अस्वीकार) पहिलो नियमले सन्तुष्ट हुन्छ भनेर निर्धारण गरिन्छ। Kubernetes मा, नीतिहरूको क्रम फरक पर्दैन।

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

तपाईं स्ट्रिपिङ नियम प्रयोग गरेर यो व्यवहार परिवर्तन गर्न सक्नुहुन्छ।

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

फायरवाल नीतिहरूले सामान्यतया कुनै पनि ट्राफिकलाई अस्वीकार गर्दछ जुन स्पष्ट रूपमा अनुमति छैन।

Kubernetes मा कुनै अस्वीकार कार्य छैनतथापि, स्रोत पोडहरूको खाली समूह (इनग्रेस) चयन गरेर नियमित (अनुमति दिने) नीतिको साथ समान प्रभाव प्राप्त गर्न सकिन्छ:

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

निम्न नीतिले क्लस्टर बाहिरको कुनै पनि IP मा पहुँच सहित सबै प्रवेश र निस्कने ट्राफिकलाई अनुमति दिन्छ:

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

बहु नीतिहरू संयोजन गर्दै

नीतिहरू तीन तहमा तार्किक वा प्रयोग गरेर संयुक्त छन्; प्रत्येक पोडको अनुमतिहरू यसलाई असर गर्ने सबै नीतिहरूको विच्छेद अनुसार सेट गरिएको छ:

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

यसको विपरित, Kubernetes मा विभिन्न लेबलहरू podSelector वा namespaceSelector तार्किक AND सँग जोडिएको छ। उदाहरणका लागि, निम्न नियमले दुवै लेबल भएका पोडहरू चयन गर्नेछ, role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

एउटै तर्क सबै प्रकारका अपरेटरहरूमा लागू हुन्छ: नीति लक्ष्य चयनकर्ताहरू, पोड चयनकर्ताहरू, र नेमस्पेस चयनकर्ताहरू।

सबनेट र IP ठेगानाहरू (IPBlocks)

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

तपाईं पोडहरूको आन्तरिक आईपी ठेगानाहरू बाहेक, बाह्य आईपीहरूमा मात्र पहुँच खोल्न सक्नुहुन्छ। उदाहरणका लागि, यदि तपाईंको पोडको सबनेट 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 मा पोडहरू सेवा मार्फत एक अर्कामा पहुँच गर्छन् - एक भर्चुअल लोड ब्यालेन्सर जसले ट्राफिकलाई सेवा लागू गर्ने पोडहरूमा रिडिरेक्ट गर्छ। तपाइँ सोच्न सक्नुहुन्छ कि नेटवर्क नीतिहरूले सेवाहरूमा पहुँच नियन्त्रण गर्दछ, तर यो मामला होइन। Kubernetes नेटवर्क नीतिहरूले पोड पोर्टहरूमा काम गर्दछ, सेवा पोर्टहरूमा होइन।

उदाहरणका लागि, यदि सेवाले पोर्ट 80 सुन्छ, तर ट्राफिकलाई यसको पोडको पोर्ट 8080 मा रिडिरेक्ट गर्छ भने, तपाईंले नेटवर्क नीतिमा ठ्याक्कै 8080 निर्दिष्ट गर्नुपर्छ।

यस्तो संयन्त्रलाई suboptimal मान्नुपर्दछ: यदि सेवाको आन्तरिक संरचना (जसका पोडहरू सुन्छन्) परिवर्तन भएमा, नेटवर्क नीतिहरू अद्यावधिक गर्नुपर्नेछ।

सेवा जाल प्रयोग गरेर नयाँ वास्तुकला दृष्टिकोण (उदाहरणका लागि, तल Istio बारे हेर्नुहोस् - लगभग। अनुवाद।) यो समस्या संग सामना गर्न अनुमति दिन्छ।

के यो प्रवेश र निकासी दुवै दर्ता गर्न आवश्यक छ?

छोटो जवाफ हो हो, पोड A लाई पोड बीसँग सञ्चार गर्नको लागि, यसलाई बहिर्गमन जडान सिर्जना गर्न अनुमति दिनुपर्छ (यसका लागि तपाईले इग्रेस नीति कन्फिगर गर्न आवश्यक छ), र पोड बीले आगमन जडान स्वीकार गर्न सक्षम हुनुपर्दछ ( यसका लागि, तदनुसार, तपाईंलाई प्रवेश नीति चाहिन्छ। नीति)।

यद्यपि, व्यवहारमा, तपाइँ एक वा दुबै दिशाहरूमा जडानहरू अनुमति दिन पूर्वनिर्धारित नीतिमा भर पर्न सक्नुहुन्छ।

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

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

स्टेटफुल वा स्टेटलेस तल हेर्नुहोस्।

लगहरू

Kubernetes नेटवर्क नीतिहरूले ट्राफिक लग गर्न सक्दैन। यसले नीतिले उद्देश्य अनुसार काम गरिरहेको छ कि छैन भनेर निर्धारण गर्न गाह्रो बनाउँछ र सुरक्षा विश्लेषणलाई धेरै जटिल बनाउँछ।

बाह्य सेवाहरूमा ट्राफिक नियन्त्रण

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

नीति जाँच

फायरवालहरूले तपाईंलाई चेतावनी दिनेछ वा गलत नीति स्वीकार गर्न अस्वीकार गर्नेछ। Kubernetes ले केहि प्रमाणीकरण पनि गर्दछ। kubectl मार्फत नेटवर्क नीति सेट गर्दा, Kubernetes ले यो गलत छ भनेर घोषणा गर्न सक्छ र यसलाई स्वीकार गर्न अस्वीकार गर्न सक्छ। अन्य अवस्थामा, Kubernetes ले नीति लिनेछ र छुटेको विवरणहरू भर्नेछ। तिनीहरू आदेश प्रयोग गरेर देख्न सकिन्छ:

kubernetes get networkpolicy <policy-name> -o yaml

कुबेरनेट प्रमाणीकरण प्रणाली त्रुटिपूर्ण छैन र केही प्रकारका त्रुटिहरू छुटाउन सक्छ भन्ने कुरा ध्यानमा राख्नुहोस्।

कार्यान्वयन

Kubernetes ले सञ्जाल नीतिहरू आफैं लागू गर्दैन, तर केवल एक API गेटवे हो जसले कन्टेनर नेटवर्किङ इन्टरफेस (CNI) भनिने अन्तर्निहित प्रणालीलाई नियन्त्रणको भार प्रत्यायोजन गर्दछ। उपयुक्त CNI तोके बिना Kubernetes क्लस्टरमा नीतिहरू सेट गर्नु भनेको फायरवालहरूमा स्थापना नगरी फायरवाल व्यवस्थापन सर्भरमा नीतिहरू सिर्जना गर्नु जस्तै हो। यो तपाईंसँग एक सभ्य CNI छ वा, क्लाउडमा होस्ट गरिएको Kubernetes प्लेटफर्महरूको मामलामा सुनिश्चित गर्न तपाईंमा निर्भर छ। (तपाईं प्रदायकहरूको सूची हेर्न सक्नुहुन्छ यहाँ - लगभग। ट्रान्स।), नेटवर्क नीतिहरू सक्षम गर्नुहोस् जसले तपाईंको लागि CNI सेट गर्नेछ।

यदि तपाईंले उपयुक्त सहयोगी CNI बिना नेटवर्क नीति सेट गर्नुभयो भने Kubernetes ले तपाईंलाई चेतावनी दिने छैन।

राज्यरहित वा राज्यविहीन?

मैले सामना गरेका सबै Kubernetes CNI हरू स्टेटफुल छन् (उदाहरणका लागि, क्यालिकोले लिनक्स कन्ट्र्याक प्रयोग गर्दछ)। यसले पोडलाई पुन: स्थापना नगरी सुरु गरेको TCP जडानमा प्रतिक्रियाहरू प्राप्त गर्न अनुमति दिन्छ। जे होस्, म एक Kubernetes मापदण्ड बारे सचेत छैन जसले स्टेटफुलनेसको ग्यारेन्टी गर्छ।

उन्नत सुरक्षा नीति व्यवस्थापन

यहाँ Kubernetes मा सुरक्षा नीति प्रवर्तन सुधार गर्न केही तरिकाहरू छन्:

1. सेवा मेष आर्किटेक्चरल ढाँचाले सेवा स्तरमा विस्तृत टेलिमेट्री र ट्राफिक नियन्त्रण प्रदान गर्न साइडकार कन्टेनरहरू प्रयोग गर्दछ। उदाहरणको रूपमा हामीले लिन सक्छौं इस्तिओ.
2. केही CNI विक्रेताहरूले Kubernetes नेटवर्क नीतिहरू भन्दा बाहिर जान आफ्नो उपकरणहरू विस्तार गरेका छन्।
3. टुफिन ओर्का Kubernetes नेटवर्क नीतिहरूको दृश्यता र स्वचालन प्रदान गर्दछ।

Tufin Orca प्याकेजले Kubernetes नेटवर्क नीतिहरू प्रबन्ध गर्दछ (र माथिको स्क्रिनसटहरूको स्रोत हो)।

थप जानकारी

• GKE बाट Ahmet Alp Balkan द्वारा तैयार नेटवर्क नीतिहरूको उदाहरणहरू;
• आधिकारिक Kubernetes वेबसाइटबाट दस्तावेज;
• Kubernetes नेटवर्किङ मोडेल को लागी एक गाइड;
• नेटवर्क नीतिहरू जाँचको लागि लिपि.

निष्कर्षमा

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

मलाई आशा छ कि यो गाइडले केहि प्रश्नहरू स्पष्ट गर्न र तपाईंले सामना गर्न सक्ने समस्याहरू समाधान गर्न मद्दत गर्दछ।

अनुवादकबाट PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• "इस्टिओको साथ माइक्रोसर्भिसेसहरूमा फर्कनुहोस्": भाग १ (मुख्य विशेषताहरूको परिचय), भाग २ (मार्ग, ट्राफिक नियन्त्रण), भाग ३ (सुरक्षा);
• "कुबर्नेट्समा नेटवर्किङको लागि एउटा इलस्ट्रेटेड गाइड": भाग १ र २ (नेटवर्क मोडेल, ओभरले नेटवर्क), भाग ३ (सेवा र यातायात प्रशोधन);
• «सुरक्षा-संवेदनशील वातावरणमा डकर र Kubernetes»;
• «9 Kubernetes सुरक्षा उत्तम अभ्यासहरू»;
• «11 तरिकाहरू (होइन) कुबेरनेट ह्याकको शिकार बन्ने"।

स्रोत: www.habr.com