సెక్యూరిటీ ప్రొఫెషనల్స్ కోసం కుబెర్నెట్స్ నెట్‌వర్క్ పాలసీలకు ఒక పరిచయం

గమనిక. అనువాదం.: ఆర్టికల్ రచయిత, రూవెన్ హారిసన్, సాఫ్ట్‌వేర్ డెవలప్‌మెంట్‌లో 20 సంవత్సరాలకు పైగా అనుభవం కలిగి ఉన్నారు మరియు ఈ రోజు CTO మరియు భద్రతా విధాన నిర్వహణ పరిష్కారాలను రూపొందించే సంస్థ అయిన Tufin యొక్క సహ వ్యవస్థాపకుడు. అతను కుబెర్నెట్స్ నెట్‌వర్క్ విధానాలను క్లస్టర్‌లో నెట్‌వర్క్ సెగ్మెంటేషన్ కోసం చాలా శక్తివంతమైన సాధనంగా చూస్తుండగా, వాటిని ఆచరణలో అమలు చేయడం అంత సులభం కాదని కూడా అతను నమ్ముతాడు. ఈ విషయం (చాలా పెద్దది) ఈ సమస్యపై నిపుణుల అవగాహనను మెరుగుపరచడానికి మరియు అవసరమైన కాన్ఫిగరేషన్‌లను రూపొందించడంలో వారికి సహాయపడటానికి ఉద్దేశించబడింది.

నేడు, చాలా కంపెనీలు తమ అప్లికేషన్లను అమలు చేయడానికి కుబెర్నెట్‌లను ఎక్కువగా ఎంచుకుంటున్నాయి. ఈ సాఫ్ట్‌వేర్‌పై ఆసక్తి చాలా ఎక్కువగా ఉంది, కొందరు కుబెర్నెట్స్‌ను "డేటా సెంటర్ కోసం కొత్త ఆపరేటింగ్ సిస్టమ్" అని పిలుస్తున్నారు. క్రమంగా, కుబెర్నెటెస్ (లేదా k8s) అనేది వ్యాపారంలో కీలకమైన భాగంగా భావించబడటం ప్రారంభించింది, దీనికి నెట్‌వర్క్ భద్రతతో సహా పరిణతి చెందిన వ్యాపార ప్రక్రియలను నిర్వహించడం అవసరం.

కుబెర్నెటెస్‌తో కలిసి పని చేయడం ద్వారా అయోమయంలో ఉన్న భద్రతా నిపుణుల కోసం, ప్లాట్‌ఫారమ్ యొక్క డిఫాల్ట్ విధానంలో నిజమైన వెల్లడి కావచ్చు: ప్రతిదానిని అనుమతించండి.

నెట్‌వర్క్ విధానాల అంతర్గత నిర్మాణాన్ని అర్థం చేసుకోవడానికి ఈ గైడ్ మీకు సహాయం చేస్తుంది; సాధారణ ఫైర్‌వాల్‌ల నియమాల నుండి అవి ఎలా విభిన్నంగా ఉన్నాయో అర్థం చేసుకోండి. ఇది కొన్ని ఆపదలను కూడా కవర్ చేస్తుంది మరియు కుబెర్నెట్స్‌లో అప్లికేషన్‌లను సురక్షితంగా ఉంచడంలో సహాయపడటానికి సిఫార్సులను అందిస్తుంది.

కుబెర్నెట్స్ నెట్‌వర్క్ విధానాలు

కుబెర్నెట్స్ నెట్‌వర్క్ పాలసీ మెకానిజం నెట్‌వర్క్ లేయర్‌లో ప్లాట్‌ఫారమ్‌పై అమర్చబడిన అప్లికేషన్‌ల పరస్పర చర్యను నిర్వహించడానికి మిమ్మల్ని అనుమతిస్తుంది (OSI మోడల్‌లో మూడవది). నెట్‌వర్క్ విధానాలలో OSI లేయర్ 7 ఎన్‌ఫోర్స్‌మెంట్ మరియు థ్రెట్ డిటెక్షన్ వంటి ఆధునిక ఫైర్‌వాల్‌ల యొక్క కొన్ని అధునాతన ఫీచర్‌లు లేవు, అయితే అవి ప్రాథమిక స్థాయి నెట్‌వర్క్ భద్రతను అందిస్తాయి, ఇది మంచి ప్రారంభ స్థానం.

నెట్‌వర్క్ విధానాలు పాడ్‌ల మధ్య కమ్యూనికేషన్‌లను నియంత్రిస్తాయి

కుబెర్నెటీస్‌లోని పనిభారం పాడ్‌లలో పంపిణీ చేయబడుతుంది, వీటిలో ఒకటి లేదా అంతకంటే ఎక్కువ కంటైనర్‌లు కలిసి అమర్చబడి ఉంటాయి. Kubernetes ప్రతి పాడ్‌కు ఇతర పాడ్‌ల నుండి యాక్సెస్ చేయగల IP చిరునామాను కేటాయిస్తుంది. వర్చువల్ మెషీన్ ఇన్‌స్టాన్స్‌లకు యాక్సెస్‌ని నియంత్రించడానికి క్లౌడ్‌లోని భద్రతా సమూహాలను ఉపయోగించే విధంగానే 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: అనుమతిని నిర్వచిస్తుంది అవుట్గోయింగ్ టార్గెట్ పాడ్‌ల నుండి ట్రాఫిక్ ఐచ్ఛికం.

కుబెర్నెట్స్ వెబ్‌సైట్ నుండి తీసుకోబడిన ఉదాహరణ (నేను భర్తీ చేసాను 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 డిఫాల్ట్‌గా అన్ని ట్రాఫిక్‌లను అనుమతిస్తుంది. అన్ని పాడ్‌లు తమలో తాము సమాచారాన్ని స్వేచ్ఛగా మార్పిడి చేసుకోగలవు. ఇది భద్రతా దృక్కోణం నుండి ప్రతికూలంగా అనిపించవచ్చు, అయితే అప్లికేషన్ ఇంటర్‌పెరాబిలిటీని ఎనేబుల్ చేయడానికి కుబెర్నెటీస్ డెవలపర్‌లచే రూపొందించబడిందని గుర్తుంచుకోండి. నెట్‌వర్క్ విధానాలు తర్వాత జోడించబడ్డాయి.

నేమ్‌స్పేస్‌లు

నేమ్‌స్పేస్‌లు కుబెర్నెట్స్ సహకార యంత్రాంగం. అవి ఒకదానికొకటి తార్కిక వాతావరణాలను వేరుచేయడానికి రూపొందించబడ్డాయి, అయితే ఖాళీల మధ్య కమ్యూనికేషన్ డిఫాల్ట్‌గా అనుమతించబడుతుంది.

చాలా కుబెర్నెటీస్ భాగాల వలె, నెట్‌వర్క్ విధానాలు నిర్దిష్ట నేమ్‌స్పేస్‌లో ఉంటాయి. బ్లాక్ లో 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 ఈ విధానంలో, లక్ష్య పాడ్‌లకు ఇన్‌కమింగ్ ట్రాఫిక్‌ను తెరుస్తుంది. మరో మాటలో చెప్పాలంటే, ప్రవేశం మూలం మరియు లక్ష్యం సంబంధిత గమ్యం. అలాగే, ఎగ్రెస్ గమ్యం మరియు లక్ష్యం దాని మూలం.

ఇది రెండు ఫైర్‌వాల్ నియమాలకు సమానం: ప్రవేశం → టార్గెట్; లక్ష్యం → ఎగ్రెస్.

ఎగ్రెస్ మరియు DNS (ముఖ్యమైనది!)

అవుట్‌గోయింగ్ ట్రాఫిక్‌ను పరిమితం చేయడం ద్వారా, DNS పై ప్రత్యేక శ్రద్ధ వహించండి - IP చిరునామాలకు సేవలను మ్యాప్ చేయడానికి Kubernetes ఈ సేవను ఉపయోగిస్తుంది. ఉదాహరణకు, మీరు అప్లికేషన్‌ను అనుమతించనందున కింది విధానం పని చేయదు 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 తగిన Kubernetes సేవకు 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 నేమ్‌స్పేస్‌లోని అన్ని పాడ్‌లను ఎంచుకుంటుంది.

మొదటి మ్యాచ్ మరియు రూల్ ఆర్డర్

సాంప్రదాయ ఫైర్‌వాల్‌లలో, ప్యాకెట్‌పై చర్య (అనుమతించు లేదా తిరస్కరించు) అది సంతృప్తిపరిచే మొదటి నియమం ద్వారా నిర్ణయించబడుతుంది. కుబెర్నెట్స్‌లో, విధానాల క్రమం పట్టింపు లేదు.

డిఫాల్ట్‌గా, ఎటువంటి విధానాలు సెట్ చేయనప్పుడు, పాడ్‌ల మధ్య కమ్యూనికేషన్‌లు అనుమతించబడతాయి మరియు అవి స్వేచ్ఛగా సమాచారాన్ని మార్పిడి చేసుకోవచ్చు. మీరు పాలసీలను రూపొందించడం ప్రారంభించిన తర్వాత, వాటిలో కనీసం ఒకదాని ద్వారా ప్రభావితమైన ప్రతి పాడ్ దానిని ఎంచుకున్న అన్ని పాలసీల డిస్జంక్షన్ (లాజికల్ 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

నుండి యాక్సెస్ అనుమతిస్తుంది అన్ని నేమ్‌స్పేస్‌లలోని అన్ని పాడ్‌లు (మరియు అన్ని IP) నేమ్‌స్పేస్‌లోని ఏదైనా పాడ్‌కి 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

బహుళ విధానాలను కలపడం

మూడు స్థాయిలలో లాజికల్ 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?

నేమ్‌స్పేస్‌లు మరియు పాడ్‌ల ద్వారా ఫిల్టర్ చేయండి

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 OR 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 చిరునామాలు మరియు సబ్‌నెట్‌లను ఉపయోగిస్తాయి.

కుబెర్నెట్స్‌లో, 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కి యాక్సెస్ నిషేధించబడింది. కాబట్టి, సారాంశంలో, మీరు అంతర్గత కుబెర్నెట్స్ DNS సేవకు యాక్సెస్‌ను బ్లాక్ చేసారు. మీరు ఇప్పటికీ దీన్ని తెరవాలనుకుంటే, దీన్ని స్పష్టంగా సూచించండి.

సాధారణంగా ipBlocks и podSelectors పాడ్‌ల అంతర్గత IP చిరునామాలు ఉపయోగించబడనందున, పరస్పరం ప్రత్యేకమైనవి ipBlocks. సూచించడం ద్వారా అంతర్గత IP పాడ్‌లు, మీరు వాస్తవానికి ఈ చిరునామాలతో పాడ్‌లకు/నుండి కనెక్షన్‌లను అనుమతిస్తారు. ఆచరణలో, ఏ 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), దీని అర్థం అన్ని పోర్టులు.

ఉత్తమ అభ్యాసం: డిఫాల్ట్ విలువలపై ఆధారపడకండి, మీకు ఏది అవసరమో స్పష్టంగా పేర్కొనండి.

దయచేసి మీరు తప్పనిసరిగా సేవ పోర్ట్‌లను కాకుండా పాడ్ పోర్ట్‌లను ఉపయోగించాలని గుర్తుంచుకోండి (దీనిపై తదుపరి పేరాలో మరిన్ని).

పాడ్‌లు లేదా సేవల కోసం పాలసీలు నిర్వచించబడ్డాయా?

సాధారణంగా, కుబెర్నెట్స్‌లోని పాడ్‌లు ఒక సర్వీస్ ద్వారా ఒకదానికొకటి యాక్సెస్ చేస్తాయి - సర్వీస్‌ను అమలు చేసే పాడ్‌లకు ట్రాఫిక్‌ను దారి మళ్లించే వర్చువల్ లోడ్ బ్యాలెన్సర్. నెట్‌వర్క్ విధానాలు సేవలకు యాక్సెస్‌ను నియంత్రిస్తాయని మీరు అనుకోవచ్చు, కానీ ఇది అలా కాదు. కుబెర్నెటీస్ నెట్‌వర్క్ విధానాలు పాడ్ పోర్ట్‌లలో పని చేస్తాయి, సర్వీస్ పోర్ట్‌లలో కాదు.

ఉదాహరణకు, ఒక సేవ పోర్ట్ 80ని వింటూ, దాని పాడ్‌లలోని పోర్ట్ 8080కి ట్రాఫిక్‌ను దారి మళ్లిస్తే, మీరు నెట్‌వర్క్ విధానంలో ఖచ్చితంగా 8080ని పేర్కొనాలి.

అటువంటి మెకానిజం సబ్‌ప్టిమల్‌గా పరిగణించబడాలి: సేవ యొక్క అంతర్గత నిర్మాణం (పాడ్‌లు వినే పోర్ట్‌లు) మారితే, నెట్‌వర్క్ విధానాలను నవీకరించవలసి ఉంటుంది.

సర్వీస్ మెష్ ఉపయోగించి కొత్త నిర్మాణ విధానం (ఉదాహరణకు, దిగువ ఇస్టియో గురించి చూడండి - సుమారుగా. అనువాదం.) ఈ సమస్యను ఎదుర్కోవటానికి మిమ్మల్ని అనుమతిస్తుంది.

ప్రవేశం మరియు ఎగ్రెస్ రెండింటినీ నమోదు చేయడం అవసరమా?

చిన్న సమాధానం అవును, పాడ్ A పాడ్ Bతో కమ్యూనికేట్ చేయడానికి, అది తప్పనిసరిగా అవుట్‌గోయింగ్ కనెక్షన్‌ని సృష్టించడానికి అనుమతించబడాలి (దీని కోసం మీరు ఎగ్రెస్ విధానాన్ని కాన్ఫిగర్ చేయాలి), మరియు పాడ్ B తప్పనిసరిగా ఇన్‌కమింగ్ కనెక్షన్‌ని అంగీకరించగలగాలి ( దీని కోసం, తదనుగుణంగా, మీకు ప్రవేశ విధానం అవసరం).

అయితే, ఆచరణలో, మీరు ఒకటి లేదా రెండు దిశలలో కనెక్షన్‌లను అనుమతించడానికి డిఫాల్ట్ విధానంపై ఆధారపడవచ్చు.

కొంత పాడ్ ఉంటే-మూలం ఒకటి లేదా అంతకంటే ఎక్కువ మంది ఎంపిక చేస్తారు లోపలికి-రాజకీయ నాయకులు, దానిపై విధించిన ఆంక్షలు వారి విభజన ద్వారా నిర్ణయించబడతాయి. ఈ సందర్భంలో, మీరు పాడ్‌కి కనెక్షన్‌ని స్పష్టంగా అనుమతించాలి -చిరునామాదారునికి. ఏదైనా పాలసీ ద్వారా పాడ్ ఎంచుకోబడకపోతే, దాని అవుట్‌గోయింగ్ (ఎగ్రెస్) ట్రాఫిక్ డిఫాల్ట్‌గా అనుమతించబడుతుంది.

అదేవిధంగా, పాడ్ యొక్క విధిచిరునామాదారుడు, ఒకటి లేదా అంతకంటే ఎక్కువ మంది ఎంపిక చేసారు ప్రవేశం-రాజకీయ నాయకులు, వారి విభజన ద్వారా నిర్ణయించబడుతుంది. ఈ సందర్భంలో, సోర్స్ పాడ్ నుండి ట్రాఫిక్‌ను స్వీకరించడానికి మీరు దానిని స్పష్టంగా అనుమతించాలి. ఏదైనా విధానం ద్వారా పాడ్ ఎంచుకోబడకపోతే, దాని కోసం అన్ని ఇన్‌గ్రెస్ ట్రాఫిక్ డిఫాల్ట్‌గా అనుమతించబడుతుంది.

దిగువ స్టేట్‌ఫుల్ లేదా స్టేట్‌లెస్‌ని చూడండి.

లాగ్‌లు

కుబెర్నెట్స్ నెట్‌వర్క్ విధానాలు ట్రాఫిక్‌ను లాగ్ చేయలేవు. ఇది ఒక విధానం ఉద్దేశించిన విధంగా పని చేస్తుందో లేదో నిర్ధారించడం కష్టతరం చేస్తుంది మరియు భద్రతా విశ్లేషణను చాలా క్లిష్టతరం చేస్తుంది.

బాహ్య సేవలకు ట్రాఫిక్ నియంత్రణ

Kubernetes నెట్‌వర్క్ విధానాలు ఎగ్రెస్ విభాగాలలో పూర్తి అర్హత కలిగిన డొమైన్ పేరు (DNS)ని పేర్కొనడానికి మిమ్మల్ని అనుమతించవు. స్థిరమైన IP చిరునామా (aws.com వంటివి) లేని బాహ్య గమ్యస్థానాలకు ట్రాఫిక్‌ను పరిమితం చేయడానికి ప్రయత్నిస్తున్నప్పుడు ఈ వాస్తవం గణనీయమైన అసౌకర్యానికి దారి తీస్తుంది.

విధాన తనిఖీ

ఫైర్‌వాల్‌లు మిమ్మల్ని హెచ్చరిస్తాయి లేదా తప్పు విధానాన్ని అంగీకరించడానికి నిరాకరిస్తాయి. కుబెర్నెటెస్ కొంత ధృవీకరణ కూడా చేస్తాడు. kubectl ద్వారా నెట్‌వర్క్ విధానాన్ని సెట్ చేస్తున్నప్పుడు, కుబెర్నెట్స్ అది సరికాదని ప్రకటించి, దానిని అంగీకరించడానికి నిరాకరించవచ్చు. ఇతర సందర్భాల్లో, కుబెర్నెట్స్ పాలసీని తీసుకుని, తప్పిపోయిన వివరాలతో నింపుతారు. కమాండ్ ఉపయోగించి వాటిని చూడవచ్చు:

kubernetes get networkpolicy <policy-name> -o yaml

కుబెర్నెట్స్ ధ్రువీకరణ సిస్టమ్ తప్పుపట్టలేనిది కాదని మరియు కొన్ని రకాల ఎర్రర్‌లను కోల్పోవచ్చని గుర్తుంచుకోండి.

అమలు

కుబెర్నెటెస్ నెట్‌వర్క్ విధానాలను స్వయంగా అమలు చేయదు, కానీ ఇది కేవలం API గేట్‌వే, ఇది కంటైనర్ నెట్‌వర్కింగ్ ఇంటర్‌ఫేస్ (CNI) అనే అంతర్లీన సిస్టమ్‌కు నియంత్రణ భారాన్ని అప్పగించింది. తగిన CNIని కేటాయించకుండా Kubernetes క్లస్టర్‌లో విధానాలను సెట్ చేయడం అంటే వాటిని ఫైర్‌వాల్‌లలో ఇన్‌స్టాల్ చేయకుండా ఫైర్‌వాల్ మేనేజ్‌మెంట్ సర్వర్‌లో విధానాలను రూపొందించడం లాంటిదే. మీకు మంచి CNI ఉందని నిర్ధారించుకోవడం లేదా, కుబెర్నెటెస్ ప్లాట్‌ఫారమ్‌ల విషయంలో, క్లౌడ్‌లో హోస్ట్ చేయడం మీ ఇష్టం (మీరు ప్రొవైడర్ల జాబితాను చూడవచ్చు ఇక్కడ - సుమారు ట్రాన్స్.), మీ కోసం CNIని సెట్ చేసే నెట్‌వర్క్ విధానాలను ప్రారంభించండి.

మీరు తగిన సహాయకుడు CNI లేకుండా నెట్‌వర్క్ విధానాన్ని సెట్ చేస్తే, Kubernetes మిమ్మల్ని హెచ్చరించదని గుర్తుంచుకోండి.

స్టేట్‌ఫుల్ లేదా స్టేట్‌లెస్?

నేను ఎదుర్కొన్న అన్ని Kubernetes CNIలు స్టేట్‌ఫుల్‌గా ఉన్నాయి (ఉదాహరణకు, కాలికో Linux contrackని ఉపయోగిస్తుంది). ఇది పాడ్ ప్రారంభించిన TCP కనెక్షన్‌పై ప్రతిస్పందనలను తిరిగి స్థాపించకుండానే స్వీకరించడానికి అనుమతిస్తుంది. అయినప్పటికీ, స్థితప్రజ్ఞతకు హామీ ఇచ్చే కుబెర్నెట్స్ ప్రమాణం గురించి నాకు తెలియదు.

అధునాతన భద్రతా విధాన నిర్వహణ

కుబెర్నెట్స్‌లో భద్రతా విధాన అమలును మెరుగుపరచడానికి ఇక్కడ కొన్ని మార్గాలు ఉన్నాయి:

1. సర్వీస్ స్థాయిలో వివరణాత్మక టెలిమెట్రీ మరియు ట్రాఫిక్ నియంత్రణను అందించడానికి సర్వీస్ మెష్ ఆర్కిటెక్చరల్ నమూనా సైడ్‌కార్ కంటైనర్‌లను ఉపయోగిస్తుంది. ఉదాహరణగా మనం తీసుకోవచ్చు ఇస్టియో.
2. కొంతమంది CNI విక్రేతలు కుబెర్నెట్స్ నెట్‌వర్క్ విధానాలను దాటి తమ సాధనాలను విస్తరించారు.
3. తుఫిన్ ఓర్కా Kubernetes నెట్‌వర్క్ విధానాల దృశ్యమానత మరియు ఆటోమేషన్‌ను అందిస్తుంది.

Tufin Orca ప్యాకేజీ Kubernetes నెట్‌వర్క్ విధానాలను నిర్వహిస్తుంది (మరియు పై స్క్రీన్‌షాట్‌ల మూలం).

అదనపు సమాచారం

• GKE నుండి అహ్మెట్ ఆల్ప్ బాల్కన్ రూపొందించిన నెట్‌వర్క్ విధానాల ఉదాహరణలు;
• అధికారిక Kubernetes వెబ్‌సైట్ నుండి డాక్యుమెంటేషన్;
• కుబెర్నెటెస్ నెట్‌వర్కింగ్ మోడల్‌కు ఒక గైడ్;
• నెట్‌వర్క్ విధానాలను తనిఖీ చేయడానికి స్క్రిప్ట్.

తీర్మానం

కుబెర్నెటెస్ నెట్‌వర్క్ విధానాలు క్లస్టర్‌లను విభజించడానికి మంచి సాధనాలను అందిస్తాయి, అయితే అవి స్పష్టమైనవి కావు మరియు అనేక సూక్ష్మ నైపుణ్యాలను కలిగి ఉంటాయి. ఈ సంక్లిష్టత కారణంగా, ఇప్పటికే ఉన్న అనేక క్లస్టర్ విధానాలు బగ్గీగా ఉన్నాయని నేను నమ్ముతున్నాను. ఈ సమస్యకు సాధ్యమయ్యే పరిష్కారాలలో విధాన నిర్వచనాలను ఆటోమేట్ చేయడం లేదా ఇతర విభజన సాధనాలను ఉపయోగించడం వంటివి ఉన్నాయి.

ఈ గైడ్ కొన్ని ప్రశ్నలను క్లియర్ చేయడానికి మరియు మీరు ఎదుర్కొనే సమస్యలను పరిష్కరించడానికి సహాయపడుతుందని నేను ఆశిస్తున్నాను.

అనువాదకుని నుండి PS

మా బ్లాగులో కూడా చదవండి:

• "ఇస్టియోతో మైక్రోసర్వీసెస్‌కి తిరిగి వెళ్ళు": పార్ట్ 1 (ప్రధాన లక్షణాల పరిచయం), పార్ట్ 2 (రూటింగ్, ట్రాఫిక్ నియంత్రణ), భాగం 3 (భద్రత);
• "కుబెర్నెట్స్‌లో నెట్‌వర్కింగ్‌కు ఇలస్ట్రేటెడ్ గైడ్": భాగాలు 1 మరియు 2 (నెట్‌వర్క్ మోడల్, ఓవర్‌లే నెట్‌వర్క్‌లు), పార్ట్ 3 (సేవలు మరియు ట్రాఫిక్ ప్రాసెసింగ్);
• «భద్రతను కోరుకునే వాతావరణంలో డాకర్ మరియు కుబెర్నెట్స్";
• «కుబెర్నెట్స్ భద్రత కోసం 9 ఉత్తమ పద్ధతులు";
• «కుబెర్నెటెస్ హ్యాక్‌కు బాధితులుగా మారడానికి (కాదు) 11 మార్గాలు".

మూలం: www.habr.com