பாதுகாப்பு நிபுணர்களுக்கான குபெர்னெட்ஸ் நெட்வொர்க் கொள்கைகளுக்கு ஒரு அறிமுகம்

குறிப்பு. மொழிபெயர்: கட்டுரையின் ஆசிரியர், ருவன் ஹாரிசன், மென்பொருள் மேம்பாட்டில் 20 ஆண்டுகளுக்கும் மேலான அனுபவம் கொண்டவர், இன்று CTO மற்றும் பாதுகாப்புக் கொள்கை மேலாண்மை தீர்வுகளை உருவாக்கும் நிறுவனமான Tufin இன் இணை நிறுவனர் ஆவார். குபெர்னெட்டஸ் நெட்வொர்க் கொள்கைகளை ஒரு கிளஸ்டரில் நெட்வொர்க் பிரிப்பிற்கான மிகவும் சக்திவாய்ந்த கருவியாக அவர் கருதும் அதே வேளையில், அவற்றை நடைமுறையில் செயல்படுத்துவது அவ்வளவு எளிதானது அல்ல என்றும் அவர் நம்புகிறார். இந்த பொருள் (மிகவும் பெரியது) இந்த சிக்கலைப் பற்றிய நிபுணர்களின் விழிப்புணர்வை மேம்படுத்துவதற்கும் தேவையான கட்டமைப்புகளை உருவாக்க அவர்களுக்கு உதவுவதற்கும் நோக்கமாக உள்ளது.

இன்று, பல நிறுவனங்கள் தங்கள் பயன்பாடுகளை இயக்க குபெர்னெட்ஸை அதிகளவில் தேர்வு செய்கின்றன. இந்த மென்பொருளில் ஆர்வம் அதிகமாக இருப்பதால், சிலர் குபெர்னெட்ஸை "தரவு மையத்திற்கான புதிய இயக்க முறைமை" என்று அழைக்கின்றனர். படிப்படியாக, Kubernetes (அல்லது k8s) வணிகத்தின் ஒரு முக்கிய பகுதியாக உணரத் தொடங்குகிறது, இதற்கு நெட்வொர்க் பாதுகாப்பு உட்பட முதிர்ந்த வணிக செயல்முறைகளின் அமைப்பு தேவைப்படுகிறது.

குபெர்னெட்டஸுடன் பணிபுரிவதில் குழப்பமடைந்த பாதுகாப்பு வல்லுநர்களுக்கு, உண்மையான வெளிப்பாடானது இயங்குதளத்தின் இயல்புநிலைக் கொள்கையாக இருக்கலாம்: எல்லாவற்றையும் அனுமதியுங்கள்.

நெட்வொர்க் கொள்கைகளின் உள் கட்டமைப்பைப் புரிந்துகொள்ள இந்த வழிகாட்டி உதவும்; வழக்கமான ஃபயர்வால்களுக்கான விதிகளிலிருந்து அவை எவ்வாறு வேறுபடுகின்றன என்பதைப் புரிந்து கொள்ளுங்கள். இது சில ஆபத்துக்களையும் உள்ளடக்கும் மற்றும் குபெர்னெட்ஸில் பயன்பாடுகளைப் பாதுகாக்க உதவும் பரிந்துரைகளை வழங்கும்.

குபெர்னெட்ஸ் நெட்வொர்க் கொள்கைகள்

குபெர்னெட்ஸ் நெட்வொர்க் பாலிசி மெக்கானிசம், நெட்வொர்க் லேயரில் இயங்குதளத்தில் பயன்படுத்தப்படும் பயன்பாடுகளின் தொடர்புகளை நிர்வகிக்க உங்களை அனுமதிக்கிறது (ஓஎஸ்ஐ மாதிரியில் மூன்றாவது). நெட்வொர்க் கொள்கைகளில் OSI லேயர் 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 தவிர்க்கப்பட்டது, கொள்கை அனைத்து போக்குவரத்தையும் மறுக்கும் (கீழே உள்ள "விதியை அகற்றும்" ஐப் பார்க்கவும்).

அனுமதி என்பது இயல்புநிலை கொள்கை

கொள்கைகள் எதுவும் வரையறுக்கப்படவில்லை எனில், 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:
...

ஆதாரம் மற்றும் இலக்கு

ஃபயர்வால் கொள்கைகள் ஆதாரங்கள் மற்றும் இலக்குகளுடன் கூடிய விதிகளைக் கொண்டிருக்கும். குபெர்னெட்ஸ் நெட்வொர்க் கொள்கைகள் ஒரு இலக்குக்காக வரையறுக்கப்படுகின்றன - அவை பொருந்தும் காய்களின் தொகுப்பு - பின்னர் நுழைவு மற்றும்/அல்லது வெளியேறும் போக்குவரத்திற்கான விதிகளை அமைக்கிறது. எங்கள் எடுத்துக்காட்டில், பாலிசியின் இலக்கு பெயர்வெளியில் உள்ள அனைத்து காய்களாக இருக்கும் 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 இந்தக் கொள்கையில், இலக்கு காய்களுக்கு உள்வரும் போக்குவரத்தைத் திறக்கிறது. வேறு வார்த்தைகளில் கூறுவதானால், உட்செலுத்துதல் ஆதாரம் மற்றும் இலக்கு என்பது தொடர்புடைய இலக்கு. அதேபோல், வெளியேறுதல் இலக்கு மற்றும் இலக்கு அதன் மூலமாகும்.

இது இரண்டு ஃபயர்வால் விதிகளுக்குச் சமம்: Ingress → Target; இலக்கு → வெளியேறுதல்.

வெளியேற்றம் மற்றும் DNS (முக்கியமானது!)

வெளிச்செல்லும் போக்குவரத்தை கட்டுப்படுத்துவதன் மூலம், DNS இல் சிறப்பு கவனம் செலுத்துங்கள் - ஐபி முகவரிகளுக்கு சேவைகளை வரைபடமாக்க குபெர்னெட்ஸ் இந்த சேவையைப் பயன்படுத்துகிறார். எடுத்துக்காட்டாக, நீங்கள் பயன்பாட்டை அனுமதிக்காததால் பின்வரும் கொள்கை செயல்படாது 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 பெயர்வெளியில் உள்ள அனைத்து காய்களையும் தேர்ந்தெடுக்கிறது.

முதல் போட்டி மற்றும் விதி வரிசை

வழக்கமான ஃபயர்வால்களில், ஒரு பாக்கெட்டின் செயல் (அனுமதி அல்லது மறுப்பு) அது திருப்திப்படுத்தும் முதல் விதியால் தீர்மானிக்கப்படுகிறது. குபெர்னெட்டஸில், கொள்கைகளின் வரிசை ஒரு பொருட்டல்ல.

இயல்பாக, கொள்கைகள் எதுவும் அமைக்கப்படாதபோது, ​​காய்களுக்கிடையேயான தகவல்தொடர்புகள் அனுமதிக்கப்படும், மேலும் அவை சுதந்திரமாக தகவல்களைப் பரிமாறிக்கொள்ளலாம். நீங்கள் கொள்கைகளை உருவாக்கத் தொடங்கியவுடன், அதில் குறைந்தபட்சம் ஒன்றால் பாதிக்கப்படும் ஒவ்வொரு பாட்டும் அதைத் தேர்ந்தெடுத்த அனைத்துக் கொள்கைகளின் டிஸ்ஜங்க்ஷன் (தர்க்கரீதியான அல்லது) படி தனிமைப்படுத்தப்படும். எந்தக் கொள்கையாலும் பாதிக்கப்படாத காய்கள் திறந்தே இருக்கும்.

அகற்றும் விதியைப் பயன்படுத்தி இந்த நடத்தையை நீங்கள் மாற்றலாம்.

அகற்றும் விதி ("மறுக்கவும்")

ஃபயர்வால் கொள்கைகள் பொதுவாக வெளிப்படையாக அனுமதிக்கப்படாத எந்தவொரு போக்குவரத்தையும் மறுக்கின்றன.

குபெர்னெட்டஸில் எந்த மறுப்பு நடவடிக்கையும் இல்லை, இருப்பினும், இதேபோன்ற விளைவை வழக்கமான (அனுமதி) கொள்கையுடன், மூல காய்களின் வெற்றுக் குழுவைத் தேர்ந்தெடுப்பதன் மூலம் அடையலாம் (உள்ளீடு):

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

பல கொள்கைகளை இணைத்தல்

தர்க்கரீதியான அல்லது மூன்று நிலைகளில் கொள்கைகள் இணைக்கப்படுகின்றன; ஒவ்வொரு பாட்டின் அனுமதிகளும் அதைப் பாதிக்கும் அனைத்துக் கொள்கைகளின் விலகலுக்கு ஏற்ப அமைக்கப்பட்டுள்ளன:

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 லாஜிக்கல் 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

அனைத்து வகையான ஆபரேட்டர்களுக்கும் இதே தர்க்கம் பொருந்தும்: கொள்கை இலக்கு தேர்வாளர்கள், பாட் தேர்வாளர்கள் மற்றும் பெயர்வெளி தேர்வாளர்கள்.

சப்நெட்கள் மற்றும் 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ஐ மட்டுமே அணுக அனுமதிக்கிறது; வேறு எந்த ஐபியையும் அணுகுவது தடைசெய்யப்பட்டுள்ளது. எனவே, சாராம்சத்தில், உள் குபெர்னெட்ஸ் டிஎன்எஸ் சேவைக்கான அணுகலைத் தடுத்துள்ளீர்கள். நீங்கள் இன்னும் அதைத் திறக்க விரும்பினால், இதை வெளிப்படையாகக் குறிப்பிடவும்.

வழக்கமாக ipBlocks и podSelectors காய்களின் உள் ஐபி முகவரிகள் பயன்படுத்தப்படாததால், பரஸ்பரம் பிரத்தியேகமானவை ipBlocks. குறிப்பதன் மூலம் உள் 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

பாட்களின் உள் ஐபி முகவரிகளைத் தவிர்த்து, வெளிப்புற ஐபிகளுக்கு மட்டுமே நீங்கள் அணுகலைத் திறக்க முடியும். எடுத்துக்காட்டாக, உங்கள் பாட்டின் சப்நெட் 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ஐக் குறிப்பிட வேண்டும்.

அத்தகைய பொறிமுறையானது துணை உகந்ததாகக் கருதப்பட வேண்டும்: சேவையின் உள் அமைப்பு (பாட்கள் கேட்கும் துறைமுகங்கள்) மாறினால், நெட்வொர்க் கொள்கைகள் புதுப்பிக்கப்பட வேண்டும்.

சர்வீஸ் மெஷைப் பயன்படுத்தி புதிய கட்டடக்கலை அணுகுமுறை (உதாரணமாக, இஸ்டியோ பற்றி கீழே பார்க்கவும் - தோராயமாக. மொழிபெயர்ப்பு.) இந்த சிக்கலைச் சமாளிக்க உங்களை அனுமதிக்கிறது.

நுழைவு மற்றும் வெளியேறுதல் இரண்டையும் பதிவு செய்வது அவசியமா?

சுருக்கமான பதில் ஆம், Pod A ஆனது Pod B உடன் தொடர்புகொள்வதற்கு, அது வெளிச்செல்லும் இணைப்பை உருவாக்க அனுமதிக்கப்பட வேண்டும் (இதற்காக நீங்கள் வெளியேறும் கொள்கையை உள்ளமைக்க வேண்டும்), மேலும் Pod B உள்வரும் இணைப்பை ஏற்க முடியும் ( இதற்கு, அதன்படி, உங்களுக்கு ஒரு நுழைவுக் கொள்கை தேவை).

இருப்பினும், நடைமுறையில், ஒன்று அல்லது இரண்டு திசைகளிலும் இணைப்புகளை அனுமதிக்க, இயல்புநிலை கொள்கையை நீங்கள் நம்பலாம்.

சில போட் என்றால்-மூல ஒன்று அல்லது பலரால் தேர்ந்தெடுக்கப்படும் சாலைகளை-அரசியல்வாதிகள், அதற்கு விதிக்கப்படும் கட்டுப்பாடுகள் அவர்களின் விலகல் மூலம் தீர்மானிக்கப்படும். இந்த வழக்கில், நீங்கள் பாட் உடன் இணைப்பை வெளிப்படையாக அனுமதிக்க வேண்டும் -முகவரிக்கு. எந்தவொரு கொள்கையாலும் ஒரு பாட் தேர்ந்தெடுக்கப்படவில்லை என்றால், அதன் வெளிச்செல்லும் (வெளியேறும்) போக்குவரத்து இயல்பாகவே அனுமதிக்கப்படும்.

அதுபோலவே நெற்றும் விதிமுகவரியாளர், ஒன்று அல்லது பலரால் தேர்ந்தெடுக்கப்பட்டது உட்செல்வதை-அரசியல்வாதிகள், அவர்களின் விலகல் மூலம் தீர்மானிக்கப்படும். இந்தச் சந்தர்ப்பத்தில், சோர்ஸ் பாடில் இருந்து ட்ராஃபிக்கைப் பெற நீங்கள் வெளிப்படையாக அனுமதிக்க வேண்டும். எந்தவொரு கொள்கையாலும் ஒரு பாட் தேர்ந்தெடுக்கப்படவில்லை எனில், அதற்கான அனைத்து நுழைவு போக்குவரத்தும் இயல்பாகவே அனுமதிக்கப்படும்.

கீழே உள்ள நிலை அல்லது நிலையற்றதைப் பார்க்கவும்.

பதிவுகள்

குபெர்னெட்ஸ் நெட்வொர்க் கொள்கைகளால் ட்ராஃபிக்கை பதிவு செய்ய முடியாது. இது ஒரு கொள்கையின் நோக்கம் போல் செயல்படுகிறதா என்பதைக் கண்டறிவதை கடினமாக்குகிறது மற்றும் பாதுகாப்பு பகுப்பாய்வை பெரிதும் சிக்கலாக்குகிறது.

வெளிப்புற சேவைகளுக்கான போக்குவரத்தின் கட்டுப்பாடு

குபெர்னெட்ஸ் நெட்வொர்க் கொள்கைகள், வெளியேறும் பிரிவுகளில் முழுத் தகுதியான டொமைன் பெயரை (DNS) குறிப்பிட உங்களை அனுமதிக்காது. நிலையான IP முகவரி (aws.com போன்றவை) இல்லாத வெளிப்புற இடங்களுக்கு போக்குவரத்தை மட்டுப்படுத்த முயற்சிக்கும்போது இந்த உண்மை குறிப்பிடத்தக்க சிரமத்திற்கு வழிவகுக்கிறது.

கொள்கை சரிபார்ப்பு

ஃபயர்வால்கள் உங்களை எச்சரிக்கும் அல்லது தவறான கொள்கையை ஏற்க மறுக்கும். குபெர்னெட்டஸ் சில சரிபார்ப்புகளையும் செய்கிறார். kubectl மூலம் பிணையக் கொள்கையை அமைக்கும் போது, ​​Kubernetes அது தவறானது என்று அறிவித்து அதை ஏற்க மறுக்கலாம். மற்ற சந்தர்ப்பங்களில், குபெர்னெட்ஸ் பாலிசியை எடுத்து அதில் விடுபட்ட விவரங்களுடன் நிரப்புவார். கட்டளையைப் பயன்படுத்தி அவற்றைக் காணலாம்:

kubernetes get networkpolicy <policy-name> -o yaml

குபெர்னெட்டஸ் சரிபார்ப்பு முறை தவறாது மற்றும் சில வகையான பிழைகளைத் தவறவிடக்கூடும் என்பதை நினைவில் கொள்ளவும்.

மரணதண்டனை

குபெர்னெட்ஸ் நெட்வொர்க் கொள்கைகளை செயல்படுத்தவில்லை, ஆனால் இது ஒரு API நுழைவாயில் ஆகும், இது கட்டுப்பாட்டு சுமையை கொள்கலன் நெட்வொர்க்கிங் இன்டர்ஃபேஸ் (CNI) எனப்படும் அடிப்படை அமைப்பிற்கு வழங்குகிறது. பொருத்தமான CNI ஐ ஒதுக்காமல் Kubernetes கிளஸ்டரில் கொள்கைகளை அமைப்பது, ஃபயர்வால்களில் நிறுவாமல் ஃபயர்வால் மேலாண்மை சேவையகத்தில் கொள்கைகளை உருவாக்குவது போன்றதாகும். உங்களிடம் கண்ணியமான CNI இருப்பதை உறுதிசெய்வது உங்களுடையது அல்லது குபெர்னெட்டஸ் இயங்குதளங்களில் கிளவுட்டில் ஹோஸ்ட் செய்யப்பட்டுள்ளது (வழங்குபவர்களின் பட்டியலை நீங்கள் பார்க்கலாம் இங்கே - தோராயமாக டிரான்ஸ்.), உங்களுக்காக CNIயை அமைக்கும் பிணையக் கொள்கைகளை இயக்கவும்.

பொருத்தமான உதவியாளர் CNI இல்லாமல் பிணையக் கொள்கையை அமைத்தால் குபெர்னெட்டஸ் உங்களை எச்சரிக்காது என்பதை நினைவில் கொள்ளவும்.

மாநில அல்லது நிலையற்றதா?

நான் சந்தித்த அனைத்து குபெர்னெட்ஸ் CNI களும் நிலையானவை (உதாரணமாக, காலிகோ Linux conntrack ஐப் பயன்படுத்துகிறது). இது தொடங்கும் TCP இணைப்புக்கான பதில்களை மீண்டும் நிறுவாமலேயே பாட் பெற அனுமதிக்கிறது. இருப்பினும், நிலைத்தன்மைக்கு உத்தரவாதம் அளிக்கும் குபெர்னெட்ஸ் தரநிலை பற்றி எனக்குத் தெரியாது.

மேம்பட்ட பாதுகாப்பு கொள்கை மேலாண்மை

குபெர்னெட்ஸில் பாதுகாப்புக் கொள்கை அமலாக்கத்தை மேம்படுத்துவதற்கான சில வழிகள்:

1. சர்வீஸ் மெஷ் கட்டிடக்கலை முறையானது, சேவை மட்டத்தில் விரிவான டெலிமெட்ரி மற்றும் ட்ராஃபிக் கட்டுப்பாட்டை வழங்க சைட்கார் கொள்கலன்களைப் பயன்படுத்துகிறது. உதாரணமாக நாம் எடுத்துக் கொள்ளலாம் இஸ்டியோ.
2. சில CNI விற்பனையாளர்கள் Kubernetes நெட்வொர்க் கொள்கைகளுக்கு அப்பால் செல்ல தங்கள் கருவிகளை நீட்டித்துள்ளனர்.
3. துஃபின் ஓர்கா குபெர்னெட்ஸ் நெட்வொர்க் கொள்கைகளின் தெரிவுநிலை மற்றும் ஆட்டோமேஷனை வழங்குகிறது.

Tufin Orca தொகுப்பு Kubernetes நெட்வொர்க் கொள்கைகளை நிர்வகிக்கிறது (மேலே உள்ள ஸ்கிரீன்ஷாட்களின் மூலமாகும்).

கூடுதல் தகவல்

• GKE இலிருந்து Ahmet Alp Balkan தயாரித்த நெட்வொர்க் கொள்கைகளின் எடுத்துக்காட்டுகள்;
• அதிகாரப்பூர்வ Kubernetes இணையதளத்தில் இருந்து ஆவணம்;
• குபெர்னெட்ஸ் நெட்வொர்க்கிங் மாதிரிக்கான வழிகாட்டி;
• நெட்வொர்க் கொள்கைகளை சரிபார்ப்பதற்கான ஸ்கிரிப்ட்.

முடிவுக்கு

குபெர்னெட்ஸ் நெட்வொர்க் கொள்கைகள் கிளஸ்டர்களைப் பிரிப்பதற்கான ஒரு நல்ல கருவிகளை வழங்குகின்றன, ஆனால் அவை உள்ளுணர்வு இல்லை மற்றும் பல நுணுக்கங்களைக் கொண்டுள்ளன. இந்த சிக்கலின் காரணமாக, தற்போதுள்ள பல கிளஸ்டர் கொள்கைகள் தரமற்றதாக இருப்பதாக நான் நம்புகிறேன். இந்த சிக்கலுக்கான சாத்தியமான தீர்வுகளில் கொள்கை வரையறைகளை தானியங்குபடுத்துவது அல்லது பிற பிரிவு கருவிகளைப் பயன்படுத்துவது ஆகியவை அடங்கும்.

இந்த வழிகாட்டி சில கேள்விகளைத் தீர்க்கவும், நீங்கள் சந்திக்கும் சிக்கல்களைத் தீர்க்கவும் உதவும் என்று நம்புகிறேன்.

மொழிபெயர்ப்பாளரிடமிருந்து பி.எஸ்

எங்கள் வலைப்பதிவிலும் படிக்கவும்:

• "இஸ்டியோவுடன் மைக்ரோ சர்வீஸுக்குத் திரும்பு": பகுதி 1 (முக்கிய அம்சங்களுக்கான அறிமுகம்), பகுதி 2 (ரூட்டிங், போக்குவரத்து கட்டுப்பாடு), பகுதி 3 (பாதுகாப்பு);
• "குபெர்னெட்ஸில் நெட்வொர்க்கிங் செய்ய ஒரு விளக்கப்பட வழிகாட்டி": பாகங்கள் 1 மற்றும் 2 (நெட்வொர்க் மாடல், மேலடுக்கு நெட்வொர்க்குகள்), பகுதி 3 (சேவைகள் மற்றும் போக்குவரத்து செயலாக்கம்);
• «பாதுகாப்பு கோரும் சூழலில் டோக்கர் மற்றும் குபெர்னெட்ஸ்";
• «குபெர்னெட்ஸ் பாதுகாப்பிற்கான 9 சிறந்த நடைமுறைகள்";
• «குபெர்னெட்ஸ் ஹேக்கின் பலியாக (இல்லை) 11 வழிகள்".

ஆதாரம்: www.habr.com