സെക്യൂരിറ്റി പ്രൊഫഷണലുകൾക്കായുള്ള കുബർനെറ്റസ് നെറ്റ്‌വർക്ക് നയങ്ങൾക്ക് ഒരു ആമുഖം

കുറിപ്പ്. വിവർത്തനം.: ലേഖനത്തിന്റെ രചയിതാവ്, റൂവൻ ഹാരിസൺ, സോഫ്‌റ്റ്‌വെയർ വികസനത്തിൽ 20 വർഷത്തിലേറെ പരിചയമുള്ളയാളാണ്, ഇന്ന് സുരക്ഷാ നയ മാനേജ്‌മെന്റ് സൊല്യൂഷനുകൾ സൃഷ്‌ടിക്കുന്ന കമ്പനിയായ ടുഫിനിന്റെ സിടിഒയും സഹസ്ഥാപകനുമാണ്. ഒരു ക്ലസ്റ്ററിലെ നെറ്റ്‌വർക്ക് വിഭജനത്തിനുള്ള ശക്തമായ ഉപകരണമായി കുബർനെറ്റസ് നെറ്റ്‌വർക്ക് നയങ്ങളെ അദ്ദേഹം വീക്ഷിക്കുമ്പോൾ, അവ പ്രായോഗികമായി ഉപയോഗിക്കാൻ അത്ര എളുപ്പമല്ലെന്നും അദ്ദേഹം വിശ്വസിക്കുന്നു. ഈ മെറ്റീരിയൽ (വളരെ വലുതാണ്) ഈ പ്രശ്നത്തെക്കുറിച്ചുള്ള സ്പെഷ്യലിസ്റ്റുകളുടെ അവബോധം മെച്ചപ്പെടുത്തുന്നതിനും ആവശ്യമായ കോൺഫിഗറേഷനുകൾ സൃഷ്ടിക്കാൻ അവരെ സഹായിക്കുന്നതിനും ഉദ്ദേശിച്ചുള്ളതാണ്.

ഇന്ന്, പല കമ്പനികളും അവരുടെ ആപ്ലിക്കേഷനുകൾ പ്രവർത്തിപ്പിക്കുന്നതിന് കുബർനെറ്റുകളെ കൂടുതലായി തിരഞ്ഞെടുക്കുന്നു. ഈ സോഫ്‌റ്റ്‌വെയറിലുള്ള താൽപ്പര്യം വളരെ ഉയർന്നതാണ്, ചിലർ കുബെർനെറ്റിനെ "ഡാറ്റാ സെന്ററിനായുള്ള പുതിയ ഓപ്പറേറ്റിംഗ് സിസ്റ്റം" എന്ന് വിളിക്കുന്നു. ക്രമേണ, കുബെർനെറ്റസ് (അല്ലെങ്കിൽ k8s) ബിസിനസ്സിന്റെ ഒരു നിർണായക ഭാഗമായി മനസ്സിലാക്കാൻ തുടങ്ങിയിരിക്കുന്നു, ഇതിന് നെറ്റ്‌വർക്ക് സുരക്ഷ ഉൾപ്പെടെയുള്ള മുതിർന്ന ബിസിനസ്സ് പ്രക്രിയകളുടെ ഓർഗനൈസേഷൻ ആവശ്യമാണ്.

Kubernetes-നൊപ്പം പ്രവർത്തിക്കുന്നതിൽ ആശയക്കുഴപ്പത്തിലായ സുരക്ഷാ പ്രൊഫഷണലുകൾക്ക്, യഥാർത്ഥ വെളിപ്പെടുത്തൽ പ്ലാറ്റ്‌ഫോമിന്റെ സ്ഥിരസ്ഥിതി നയമായിരിക്കാം: എല്ലാം അനുവദിക്കുക.

നെറ്റ്‌വർക്ക് നയങ്ങളുടെ ആന്തരിക ഘടന മനസ്സിലാക്കാൻ ഈ ഗൈഡ് നിങ്ങളെ സഹായിക്കും; സാധാരണ ഫയർവാളുകളുടെ നിയമങ്ങളിൽ നിന്ന് അവ എങ്ങനെ വ്യത്യാസപ്പെട്ടിരിക്കുന്നുവെന്ന് മനസ്സിലാക്കുക. ഇത് ചില പോരായ്മകൾ മറയ്ക്കുകയും കുബർനെറ്റുകളിലെ ആപ്ലിക്കേഷനുകൾ സുരക്ഷിതമാക്കാൻ സഹായിക്കുന്നതിന് ശുപാർശകൾ നൽകുകയും ചെയ്യും.

കുബർനെറ്റസ് നെറ്റ്‌വർക്ക് നയങ്ങൾ

നെറ്റ്‌വർക്ക് ലെയറിലെ പ്ലാറ്റ്‌ഫോമിൽ വിന്യസിച്ചിരിക്കുന്ന ആപ്ലിക്കേഷനുകളുടെ ഇടപെടൽ നിയന്ത്രിക്കാൻ കുബർനെറ്റസ് നെറ്റ്‌വർക്ക് പോളിസി മെക്കാനിസം നിങ്ങളെ അനുവദിക്കുന്നു (ഒഎസ്‌ഐ മോഡലിലെ മൂന്നാമത്തേത്). നെറ്റ്‌വർക്ക് നയങ്ങളിൽ ഒഎസ്‌ഐ ലെയർ 7 എൻഫോഴ്‌സ്‌മെന്റ്, ഭീഷണി കണ്ടെത്തൽ എന്നിവ പോലുള്ള ആധുനിക ഫയർവാളുകളുടെ ചില നൂതന സവിശേഷതകൾ ഇല്ല, പക്ഷേ അവ നെറ്റ്‌വർക്ക് സുരക്ഷയുടെ അടിസ്ഥാന തലം നൽകുന്നു, അത് ഒരു നല്ല തുടക്കമാണ്.

നെറ്റ്‌വർക്ക് നയങ്ങൾ പോഡുകൾ തമ്മിലുള്ള ആശയവിനിമയം നിയന്ത്രിക്കുന്നു

ഒന്നോ അതിലധികമോ കണ്ടെയ്‌നറുകൾ ഒരുമിച്ച് വിന്യസിച്ചിരിക്കുന്ന പോഡുകളിലുടനീളം കുബർനെറ്റിലെ ജോലിഭാരം വിതരണം ചെയ്യപ്പെടുന്നു. കുബർനെറ്റസ് ഓരോ പോഡിനും മറ്റ് പോഡുകളിൽ നിന്ന് ആക്‌സസ് ചെയ്യാവുന്ന ഒരു 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 create -f policy.yaml

നെറ്റ്‌വർക്ക് പോളിസി സ്പെസിഫിക്കേഷൻ

കുബെർനെറ്റസ് നെറ്റ്‌വർക്ക് പോളിസി സ്പെസിഫിക്കേഷനിൽ നാല് ഘടകങ്ങൾ ഉൾപ്പെടുന്നു:

1. podSelector: ഈ നയം ബാധിച്ച പോഡുകൾ നിർവചിക്കുന്നു (ലക്ഷ്യങ്ങൾ) - ആവശ്യമാണ്;
2. policyTypes: ഇതിൽ ഏത് തരത്തിലുള്ള നയങ്ങളാണ് ഉൾപ്പെടുത്തിയിരിക്കുന്നതെന്ന് സൂചിപ്പിക്കുന്നു: പ്രവേശനം കൂടാതെ/അല്ലെങ്കിൽ പുറത്തുകടക്കൽ - ഓപ്ഷണൽ, എന്നാൽ എല്ലാ സാഹചര്യങ്ങളിലും ഇത് വ്യക്തമായി വ്യക്തമാക്കാൻ ഞാൻ ശുപാർശ ചെയ്യുന്നു;
3. ingress: അനുവദനീയമാണെന്ന് നിർവചിക്കുന്നു ഇൻകമിംഗ് ടാർഗെറ്റ് പോഡുകളിലേക്കുള്ള ട്രാഫിക് - ഓപ്ഷണൽ;
4. egress: അനുവദനീയമാണെന്ന് നിർവചിക്കുന്നു outട്ട്ഗോയിംഗ് ടാർഗെറ്റ് പോഡുകളിൽ നിന്നുള്ള ട്രാഫിക് ഓപ്ഷണൽ ആണ്.

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 എന്ന് ഓർക്കുക. നെറ്റ്‌വർക്ക് നയങ്ങൾ പിന്നീട് ചേർത്തു.

നെയിംസ്പേസുകൾ

കുബർനെറ്റസ് സഹകരണ സംവിധാനമാണ് നെയിംസ്പേസുകൾ. അവ പരസ്പരം ലോജിക്കൽ പരിതസ്ഥിതികളെ വേർതിരിക്കുന്നതിനാണ് രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്, അതേസമയം ഇടങ്ങൾ തമ്മിലുള്ള ആശയവിനിമയം സ്ഥിരസ്ഥിതിയായി അനുവദനീയമാണ്.

മിക്ക കുബർനെറ്റസ് ഘടകങ്ങളെയും പോലെ, നെറ്റ്‌വർക്ക് പോളിസികളും ഒരു പ്രത്യേക നെയിംസ്‌പെയ്‌സിൽ ജീവിക്കുന്നു. ബ്ലോക്കിൽ metadata പോളിസി ഏത് സ്‌പെയ്‌സിന്റേതാണെന്ന് നിങ്ങൾക്ക് വ്യക്തമാക്കാം:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: my-namespace  # <<<
spec:
...

മെറ്റാഡാറ്റയിൽ നെയിംസ്‌പെയ്‌സ് വ്യക്തമായി വ്യക്തമാക്കിയിട്ടില്ലെങ്കിൽ, സിസ്റ്റം kubectl-ൽ വ്യക്തമാക്കിയിരിക്കുന്ന നെയിംസ്‌പേസ് ഉപയോഗിക്കും (സ്ഥിരമായി namespace=default):

kubectl apply -n my-namespace -f namespace.yaml

ഞാൻ ശുപാർശ ചെയ്യുന്നു നെയിംസ്പേസ് വ്യക്തമായി വ്യക്തമാക്കുക, നിങ്ങൾ ഒരേസമയം ഒന്നിലധികം നെയിംസ്‌പെയ്‌സുകൾ ലക്ഷ്യമിടുന്ന ഒരു നയം എഴുതുന്നില്ലെങ്കിൽ.

പ്രധാനം മൂലകം podSelector പോളിസിയിൽ പോളിസി ഉൾപ്പെടുന്ന നെയിംസ്‌പെയ്‌സിൽ നിന്ന് പോഡുകൾ തിരഞ്ഞെടുക്കും (മറ്റൊരു നെയിംസ്‌പെയ്‌സിൽ നിന്നുള്ള പോഡുകളിലേക്കുള്ള ആക്‌സസ് ഇതിന് നിഷേധിക്കപ്പെടുന്നു).

അതുപോലെ, podSelectors ഇൻഗ്രെസ്, എഗ്രസ് ബ്ലോക്കുകളിൽ പോഡുകൾ അവരുടെ സ്വന്തം നെയിംസ്‌പെയ്‌സിൽ നിന്ന് മാത്രമേ തിരഞ്ഞെടുക്കാനാകൂ, തീർച്ചയായും നിങ്ങൾ അവയെ സംയോജിപ്പിച്ചില്ലെങ്കിൽ namespaceSelector (ഇത് "നെയിംസ്‌പെയ്‌സുകളും പോഡുകളും പ്രകാരം ഫിൽട്ടർ ചെയ്യുക" എന്ന വിഭാഗത്തിൽ ചർച്ചചെയ്യും).

നയ നാമകരണ നിയമങ്ങൾ

പോളിസി നാമങ്ങൾ ഒരേ നെയിംസ്‌പെയ്‌സിൽ അദ്വിതീയമാണ്. ഒരേ സ്‌പെയ്‌സിൽ ഒരേ പേരിൽ രണ്ട് പോളിസികൾ ഉണ്ടാകാൻ കഴിയില്ല, എന്നാൽ വ്യത്യസ്ത സ്‌പെയ്‌സുകളിൽ ഒരേ പേരിൽ പോളിസികൾ ഉണ്ടാകാം. ഒന്നിലധികം സ്‌പെയ്‌സുകളിൽ ഒരേ പോളിസി വീണ്ടും പ്രയോഗിക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുമ്പോൾ ഇത് ഉപയോഗപ്രദമാണ്.

പേരിടൽ രീതികളിൽ ഒന്ന് എനിക്ക് പ്രത്യേകിച്ച് ഇഷ്ടമാണ്. ടാർഗെറ്റ് പോഡുകളുമായി നെയിംസ്‌പെയ്‌സ് നാമം സംയോജിപ്പിക്കുന്നത് ഇതിൽ അടങ്ങിയിരിക്കുന്നു. ഉദാഹരണത്തിന്:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres  # <<<
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

ലേബലുകൾ

പോഡുകളും നെയിംസ്‌പെയ്‌സുകളും പോലുള്ള കുബർനെറ്റസ് ഒബ്‌ജക്‌റ്റുകളിലേക്ക് നിങ്ങൾക്ക് ഇഷ്‌ടാനുസൃത ലേബലുകൾ അറ്റാച്ചുചെയ്യാനാകും. ലേബലുകൾ (ലേബലുകൾ - ടാഗുകൾ) ക്ലൗഡിലെ ടാഗുകൾക്ക് തുല്യമാണ്. കുബർനെറ്റസ് നെറ്റ്‌വർക്ക് നയങ്ങൾ തിരഞ്ഞെടുക്കാൻ ലേബലുകൾ ഉപയോഗിക്കുന്നു കായ്കൾഅവർ പ്രയോഗിക്കുന്നവ:

podSelector:
  matchLabels:
    role: db

… അഥവാ നാമമേഖലകൾഅതിന് അവർ ബാധകമാണ്. ഈ ഉദാഹരണം നെയിംസ്‌പെയ്‌സിലെ എല്ലാ പോഡുകളും അനുബന്ധ ലേബലുകൾ ഉപയോഗിച്ച് തിരഞ്ഞെടുക്കുന്നു:

namespaceSelector:
  matchLabels:
    project: myproject

ഒരു മുന്നറിയിപ്പ്: ഉപയോഗിക്കുമ്പോൾ namespaceSelector നിങ്ങൾ തിരഞ്ഞെടുക്കുന്ന നെയിംസ്‌പെയ്‌സിൽ ശരിയായ ലേബൽ ഉണ്ടെന്ന് ഉറപ്പാക്കുക. പോലുള്ള ബിൽറ്റ്-ഇൻ നെയിംസ്‌പെയ്‌സുകൾ എന്ന് അറിഞ്ഞിരിക്കുക default и kube-system, സ്ഥിരസ്ഥിതിയായി ലേബലുകൾ അടങ്ങിയിരിക്കരുത്.

ഇതുപോലുള്ള ഒരു സ്‌പെയ്‌സിലേക്ക് നിങ്ങൾക്ക് ഒരു ലേബൽ ചേർക്കാൻ കഴിയും:

kubectl label namespace default namespace=default

അതേ സമയം, വിഭാഗത്തിൽ നെയിംസ്പേസ് metadata ലേബലല്ല, യഥാർത്ഥ സ്ഥല നാമത്തെ സൂചിപ്പിക്കണം:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default   # <<<
spec:
...

ഉറവിടവും ലക്ഷ്യസ്ഥാനവും

ഫയർവാൾ നയങ്ങളിൽ ഉറവിടങ്ങളും ലക്ഷ്യസ്ഥാനങ്ങളും അടങ്ങിയ നിയമങ്ങൾ അടങ്ങിയിരിക്കുന്നു. കുബർനെറ്റസ് നെറ്റ്‌വർക്ക് നയങ്ങൾ ഒരു ടാർഗെറ്റിനായി നിർവചിച്ചിരിക്കുന്നു - അവ പ്രയോഗിക്കുന്ന ഒരു കൂട്ടം പോഡുകൾ - തുടർന്ന് ഇൻഗ്രെസ് കൂടാതെ/അല്ലെങ്കിൽ എഗ്രസ് ട്രാഫിക്കിനുള്ള നിയമങ്ങൾ സജ്ജീകരിക്കുന്നു. ഞങ്ങളുടെ ഉദാഹരണത്തിൽ, നയത്തിന്റെ ലക്ഷ്യം നെയിംസ്‌പെയ്‌സിലെ എല്ലാ പോഡുകളായിരിക്കും default താക്കോലുള്ള ലേബലിനൊപ്പം app അർത്ഥവും db:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: db   # <<<
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

ഉപവിഭാഗം ingress ഈ നയത്തിൽ, ടാർഗെറ്റ് പോഡുകളിലേക്ക് ഇൻകമിംഗ് ട്രാഫിക് തുറക്കുന്നു. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, പ്രവേശനം ഉറവിടവും ലക്ഷ്യമാണ് അനുബന്ധ ലക്ഷ്യസ്ഥാനവും. അതുപോലെ, ഉദ്വേഗം ലക്ഷ്യസ്ഥാനവും ലക്ഷ്യം അതിന്റെ ഉറവിടവുമാണ്.

ഇത് രണ്ട് ഫയർവാൾ നിയമങ്ങൾക്ക് തുല്യമാണ്: Ingress → Target; ലക്ഷ്യം → എഗ്രസ്.

എഗ്രസും ഡിഎൻഎസും (പ്രധാനം!)

ഔട്ട്‌ഗോയിംഗ് ട്രാഫിക് പരിമിതപ്പെടുത്തുന്നതിലൂടെ, ഡിഎൻഎസിൽ പ്രത്യേക ശ്രദ്ധ നൽകുക - 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 അന്വേഷണങ്ങൾ അയയ്‌ക്കുക (സാധാരണയായി ബഹിരാകാശത്ത് പ്രവർത്തിക്കുന്നു kube-system).

ഈ സമീപനം പ്രവർത്തിക്കുന്നു, എന്നിരുന്നാലും അമിതമായി അനുവദനീയവും സുരക്ഷിതമല്ലാത്തതുമാണ്, കാരണം ഇത് ഡിഎൻഎസ് അന്വേഷണങ്ങൾ ക്ലസ്റ്ററിന് പുറത്തേക്ക് നയിക്കാൻ അനുവദിക്കുന്നു.

തുടർച്ചയായ മൂന്ന് ഘട്ടങ്ങളിലൂടെ നിങ്ങൾക്ക് ഇത് മെച്ചപ്പെടുത്താം.

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. പരിഭ്രാന്തരായ ആളുകൾക്ക് കൂടുതൽ മുന്നോട്ട് പോകാനും ഡിഎൻഎസ് അന്വേഷണങ്ങൾ ഒരു പ്രത്യേക ഡിഎൻഎസ് സേവനത്തിലേക്ക് പരിമിതപ്പെടുത്താനും കഴിയും 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

അത് ശ്രദ്ധിക്കുക നെയിംസ്‌പെയ്‌സിലെ പോഡുകളിലേക്ക് ട്രാഫിക് അനുവദിക്കുന്ന ഏതെങ്കിലും അധിക നയങ്ങൾ ഈ നിയമത്തെക്കാൾ മുൻഗണന നൽകും (ഒരു ഫയർവാൾ കോൺഫിഗറേഷനിൽ ഒരു നിഷേധ നിയമത്തിന് മുമ്പ് ഒരു അനുവദനീയ നിയമം ചേർക്കുന്നതിന് സമാനമാണ്).

എല്ലാം അനുവദിക്കുക (Any-Any-Any-Allow)

എല്ലാവരെയും അനുവദിക്കുക എന്ന നയം സൃഷ്‌ടിക്കുന്നതിന്, മുകളിലുള്ള നിരസിക്കുക എന്ന നയം ശൂന്യമായ ഒരു ഘടകത്തിനൊപ്പം ചേർക്കേണ്ടതുണ്ട് 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 എന്നതുമായി സംയോജിപ്പിച്ചിരിക്കുന്നു

എന്നാൽ അവ സംയോജിപ്പിക്കുമ്പോൾ, അതിന് ഒരു പരിമിതിയുണ്ട് ചൂണ്ടിക്കാട്ടി ക്രിസ് കൂണി: കുബർനെറ്റുകൾക്ക് വ്യത്യസ്ത നയങ്ങളുമായി മാത്രമേ നയങ്ങൾ സംയോജിപ്പിക്കാൻ കഴിയൂ 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 ലോജിക്കൽ അല്ലെങ്കിൽ ഉപയോഗിക്കുന്നത്.

ഒരു പ്രത്യേക ലേബൽ ഉള്ള പോഡുകൾ തിരഞ്ഞെടുക്കാൻ എല്ലാ നെയിംസ്പേസുകളിലും, ശൂന്യമായി നൽകുക 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

ഒന്നിലധികം ലേബലുകൾ ഐയുമായി സഹകരിക്കുന്നു

ഒന്നിലധികം ഒബ്‌ജക്‌റ്റുകൾ (ഹോസ്റ്റുകൾ, നെറ്റ്‌വർക്കുകൾ, ഗ്രൂപ്പുകൾ) ഉള്ള ഒരു ഫയർവാളിനുള്ള നിയമങ്ങൾ ലോജിക്കൽ OR ഉപയോഗിച്ച് സംയോജിപ്പിച്ചിരിക്കുന്നു. പാക്കറ്റ് ഉറവിടം പൊരുത്തപ്പെടുന്നെങ്കിൽ ഇനിപ്പറയുന്ന നിയമം പ്രവർത്തിക്കും Host_1 അല്ലെങ്കിൽ Host_2:

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

നേരെമറിച്ച്, കുബർനെറ്റസിൽ വിവിധ ലേബലുകൾ podSelector അഥവാ namespaceSelector ലോജിക്കൽ AND എന്നിവയുമായി സംയോജിപ്പിച്ചിരിക്കുന്നു. ഉദാഹരണത്തിന്, ഇനിപ്പറയുന്ന നിയമം രണ്ട് ലേബലുകളും ഉള്ള പോഡുകൾ തിരഞ്ഞെടുക്കും, role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

എല്ലാ തരം ഓപ്പറേറ്റർമാർക്കും ഒരേ ലോജിക് ബാധകമാണ്: പോളിസി ടാർഗെറ്റ് സെലക്‌ടറുകൾ, പോഡ് സെലക്‌ടറുകൾ, നെയിംസ്‌പേസ് സെലക്‌ടറുകൾ.

സബ്നെറ്റുകളും IP വിലാസങ്ങളും (IPBlocks)

ഒരു നെറ്റ്‌വർക്ക് സെഗ്‌മെന്റ് ചെയ്യുന്നതിന് ഫയർവാളുകൾ VLAN-കൾ, IP വിലാസങ്ങൾ, സബ്‌നെറ്റുകൾ എന്നിവ ഉപയോഗിക്കുന്നു.

Kubernetes-ൽ, IP വിലാസങ്ങൾ പോഡുകളിലേക്ക് സ്വയമേവ നിയോഗിക്കപ്പെടുന്നു, ഇടയ്ക്കിടെ മാറാം, അതിനാൽ നെറ്റ്‌വർക്ക് നയങ്ങളിൽ പോഡുകളും നെയിംസ്‌പെയ്‌സും തിരഞ്ഞെടുക്കാൻ ലേബലുകൾ ഉപയോഗിക്കുന്നു.

സബ്നെറ്റുകൾ (ipBlocks) ഇൻകമിംഗ് (പ്രവേശനം) അല്ലെങ്കിൽ ഔട്ട്‌ഗോയിംഗ് (എഗ്രസ്) ബാഹ്യ (വടക്ക്-തെക്ക്) കണക്ഷനുകൾ കൈകാര്യം ചെയ്യുമ്പോൾ ഉപയോഗിക്കുന്നു. ഉദാഹരണത്തിന്, ഈ നയം നെയിംസ്‌പെയ്‌സിൽ നിന്നുള്ള എല്ലാ പോഡുകളിലേക്കും തുറക്കുന്നു default Google DNS സേവനത്തിലേക്കുള്ള ആക്സസ്:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-dns
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 8.8.8.8/32
    ports:
    - protocol: UDP
      port: 53

ഈ ഉദാഹരണത്തിലെ ശൂന്യമായ പോഡ് സെലക്ടർ അർത്ഥമാക്കുന്നത് "നെയിംസ്പേസിലെ എല്ലാ പോഡുകളും തിരഞ്ഞെടുക്കുക" എന്നാണ്.

ഈ നയം 8.8.8.8-ലേക്ക് ആക്‌സസ്സ് മാത്രമേ അനുവദിക്കൂ; മറ്റേതെങ്കിലും ഐപിയിലേക്കുള്ള പ്രവേശനം നിരോധിച്ചിരിക്കുന്നു. അതിനാൽ, സാരാംശത്തിൽ, നിങ്ങൾ ആന്തരിക Kubernetes DNS സേവനത്തിലേക്കുള്ള ആക്സസ് തടഞ്ഞു. നിങ്ങൾക്ക് ഇപ്പോഴും ഇത് തുറക്കണമെങ്കിൽ, ഇത് വ്യക്തമായി സൂചിപ്പിക്കുക.

സാധാരണയായി ipBlocks и podSelectors പോഡുകളുടെ ആന്തരിക IP വിലാസങ്ങൾ ഉപയോഗിക്കാത്തതിനാൽ പരസ്പരവിരുദ്ധമാണ് ipBlocks. സൂചിപ്പിച്ചുകൊണ്ട് ആന്തരിക ഐപി പോഡുകൾ, നിങ്ങൾ യഥാർത്ഥത്തിൽ ഈ വിലാസങ്ങളുള്ള പോഡുകളിലേക്കുള്ള/നിന്നുള്ള കണക്ഷനുകൾ അനുവദിക്കും. പ്രായോഗികമായി, ഏത് IP വിലാസമാണ് ഉപയോഗിക്കേണ്ടതെന്ന് നിങ്ങൾക്കറിയില്ല, അതിനാലാണ് പോഡുകൾ തിരഞ്ഞെടുക്കാൻ അവ ഉപയോഗിക്കരുത്.

ഒരു എതിർ-ഉദാഹരണമായി, ഇനിപ്പറയുന്ന നയത്തിൽ എല്ലാ IP-കളും ഉൾപ്പെടുന്നു, അതിനാൽ മറ്റെല്ലാ പോഡുകളിലേക്കും പ്രവേശനം അനുവദിക്കുന്നു:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-any
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0

പോഡുകളുടെ ആന്തരിക ഐപി വിലാസങ്ങൾ ഒഴികെ, ബാഹ്യ ഐപികളിലേക്ക് മാത്രമേ നിങ്ങൾക്ക് ആക്സസ് തുറക്കാൻ കഴിയൂ. ഉദാഹരണത്തിന്, നിങ്ങളുടെ പോഡിന്റെ സബ്നെറ്റ് 10.16.0.0/14 ആണെങ്കിൽ:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-any
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 10.16.0.0/14

പോർട്ടുകളും പ്രോട്ടോക്കോളുകളും

സാധാരണ പോഡ്‌സ് ഒരു പോർട്ട് കേൾക്കുന്നു. ഇതിനർത്ഥം നിങ്ങൾക്ക് നയങ്ങളിൽ പോർട്ട് നമ്പറുകൾ വ്യക്തമാക്കാൻ കഴിയില്ലെന്നും എല്ലാം ഡിഫോൾട്ടായി ഉപേക്ഷിക്കാമെന്നുമാണ്. എന്നിരുന്നാലും, നയങ്ങൾ കഴിയുന്നത്ര നിയന്ത്രിതമാക്കാൻ ശുപാർശ ചെയ്യുന്നു, അതിനാൽ ചില സാഹചര്യങ്ങളിൽ നിങ്ങൾക്ക് ഇപ്പോഴും പോർട്ടുകൾ വ്യക്തമാക്കാൻ കഴിയും:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
    - podSelector:
        matchLabels:
          app: admin
    ports:             # <<<
      - port: 443      # <<<
        protocol: TCP  # <<<
      - port: 80       # <<<
        protocol: TCP  # <<<
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

സെലക്ടർ എന്നത് ശ്രദ്ധിക്കുക ports ബ്ലോക്കിലെ എല്ലാ ഘടകങ്ങൾക്കും ബാധകമാണ് to അഥവാ from, ഇതിൽ അടങ്ങിയിരിക്കുന്നു. വ്യത്യസ്ത ഘടകങ്ങൾക്കായി വ്യത്യസ്ത പോർട്ടുകൾ വ്യക്തമാക്കുന്നതിന്, വിഭജിക്കുക ingress അഥവാ egress കൂടെ നിരവധി ഉപവിഭാഗങ്ങളായി to അഥവാ from ഓരോന്നിലും നിങ്ങളുടെ പോർട്ടുകൾ രജിസ്റ്റർ ചെയ്യുക:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
    ports:             # <<<
     - port: 443       # <<<
       protocol: TCP   # <<<
  - from:
    - podSelector:
        matchLabels:
          app: admin
    ports:             # <<<
     - port: 80        # <<<
       protocol: TCP   # <<<
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

ഡിഫോൾട്ട് പോർട്ട് പ്രവർത്തനം:

• നിങ്ങൾ പോർട്ട് നിർവചനം പൂർണ്ണമായും ഒഴിവാക്കുകയാണെങ്കിൽ (ports), ഇതിനർത്ഥം എല്ലാ പ്രോട്ടോക്കോളുകളും എല്ലാ പോർട്ടുകളും;
• നിങ്ങൾ പ്രോട്ടോക്കോൾ നിർവചനം ഒഴിവാക്കുകയാണെങ്കിൽ (protocol), ഇതിനർത്ഥം ടിസിപി;
• നിങ്ങൾ പോർട്ട് നിർവചനം ഒഴിവാക്കുകയാണെങ്കിൽ (port), ഇതിനർത്ഥം എല്ലാ തുറമുഖങ്ങളും എന്നാണ്.

മികച്ച പരിശീലനം: ഡിഫോൾട്ട് മൂല്യങ്ങളെ ആശ്രയിക്കരുത്, നിങ്ങൾക്ക് ആവശ്യമുള്ളത് വ്യക്തമായി വ്യക്തമാക്കുക.

സേവന പോർട്ടുകളല്ല, പോഡ് പോർട്ടുകളാണ് നിങ്ങൾ ഉപയോഗിക്കേണ്ടതെന്ന കാര്യം ശ്രദ്ധിക്കുക (ഇതിനെക്കുറിച്ച് കൂടുതൽ അടുത്ത ഖണ്ഡികയിൽ).

പോഡുകൾക്കോ ​​സേവനങ്ങൾക്കോ ​​വേണ്ടി നയങ്ങൾ നിർവചിച്ചിട്ടുണ്ടോ?

സാധാരണഗതിയിൽ, കുബർനെറ്റസിലെ പോഡുകൾ ഒരു സേവനത്തിലൂടെ പരസ്പരം ആക്‌സസ് ചെയ്യുന്നു - സേവനം നടപ്പിലാക്കുന്ന പോഡുകളിലേക്ക് ട്രാഫിക് റീഡയറക്‌ട് ചെയ്യുന്ന ഒരു വെർച്വൽ ലോഡ് ബാലൻസർ. നെറ്റ്‌വർക്ക് നയങ്ങൾ സേവനങ്ങളിലേക്കുള്ള ആക്‌സസ് നിയന്ത്രിക്കുമെന്ന് നിങ്ങൾ ചിന്തിച്ചേക്കാം, എന്നാൽ ഇത് അങ്ങനെയല്ല. കുബർനെറ്റസ് നെറ്റ്‌വർക്ക് നയങ്ങൾ പോഡ് പോർട്ടുകളിലാണ് പ്രവർത്തിക്കുന്നത്, സർവീസ് പോർട്ടുകളിലല്ല.

ഉദാഹരണത്തിന്, ഒരു സേവനം പോർട്ട് 80 ശ്രദ്ധിക്കുന്നു, എന്നാൽ അതിന്റെ പോഡുകളുടെ പോർട്ട് 8080-ലേക്ക് ട്രാഫിക് റീഡയറക്‌ട് ചെയ്യുന്നുവെങ്കിൽ, നെറ്റ്‌വർക്ക് നയത്തിൽ നിങ്ങൾ കൃത്യമായി 8080 വ്യക്തമാക്കണം.

അത്തരമൊരു സംവിധാനം ഉപയുക്തമായി കണക്കാക്കണം: സേവനത്തിന്റെ ആന്തരിക ഘടന (പോഡുകൾ കേൾക്കുന്ന പോർട്ടുകൾ) മാറുകയാണെങ്കിൽ, നെറ്റ്‌വർക്ക് നയങ്ങൾ അപ്‌ഡേറ്റ് ചെയ്യേണ്ടിവരും.

സർവീസ് മെഷ് ഉപയോഗിച്ചുള്ള പുതിയ വാസ്തുവിദ്യാ സമീപനം (ഉദാഹരണത്തിന്, താഴെയുള്ള ഇസ്തിയോയെക്കുറിച്ച് കാണുക - ഏകദേശം. വിവർത്തനം.) ഈ പ്രശ്നം നേരിടാൻ നിങ്ങളെ അനുവദിക്കുന്നു.

ഇൻഗ്രസും എഗ്രസും രജിസ്റ്റർ ചെയ്യേണ്ടത് ആവശ്യമാണോ?

ചെറിയ ഉത്തരം അതെ എന്നതാണ്, പോഡ് ബിയുമായി ആശയവിനിമയം നടത്താൻ പോഡ് എയ്ക്ക്, ഒരു ഔട്ട്‌ഗോയിംഗ് കണക്ഷൻ സൃഷ്‌ടിക്കാൻ അനുവദിക്കണം (ഇതിനായി നിങ്ങൾ ഒരു എക്‌സ് പോളിസി കോൺഫിഗർ ചെയ്യേണ്ടതുണ്ട്), പോഡ് ബിക്ക് ഇൻകമിംഗ് കണക്ഷൻ സ്വീകരിക്കാൻ കഴിയണം ( ഇതിനായി, അതനുസരിച്ച്, നിങ്ങൾക്ക് ഒരു പ്രവേശന നയം ആവശ്യമാണ്).

എന്നിരുന്നാലും, പ്രായോഗികമായി, ഒന്നോ രണ്ടോ ദിശകളിലേക്ക് കണക്ഷനുകൾ അനുവദിക്കുന്നതിന് നിങ്ങൾക്ക് സ്ഥിരസ്ഥിതി നയത്തെ ആശ്രയിക്കാവുന്നതാണ്.

കുറച്ച് പോഡ് എങ്കിൽ-ഉറവിടം ഒന്നോ അതിലധികമോ പേർ തിരഞ്ഞെടുക്കും പുറത്തേക്കു പോകുക-രാഷ്ട്രീയക്കാരേ, അതിന് ഏർപ്പെടുത്തിയിരിക്കുന്ന നിയന്ത്രണങ്ങൾ അവരുടെ വിച്ഛേദനമനുസരിച്ച് തീരുമാനിക്കും. ഈ സാഹചര്യത്തിൽ, നിങ്ങൾ പോഡിലേക്കുള്ള കണക്ഷൻ വ്യക്തമായി അനുവദിക്കേണ്ടതുണ്ട് -വിലാസക്കാരൻ. ഏതെങ്കിലും നയം വഴി ഒരു പോഡ് തിരഞ്ഞെടുത്തിട്ടില്ലെങ്കിൽ, അതിന്റെ ഔട്ട്‌ഗോയിംഗ് (എഗ്രസ്) ട്രാഫിക് ഡിഫോൾട്ടായി അനുവദിക്കും.

അതുപോലെ, പോഡിന്റെ വിധിവിലാസക്കാരൻ, ഒന്നോ അതിലധികമോ തിരഞ്ഞെടുത്തു പ്രവേശിക്കുക-രാഷ്ട്രീയക്കാർ, അവരുടെ വിഭജനം നിർണ്ണയിക്കും. ഈ സാഹചര്യത്തിൽ, ഉറവിട പോഡിൽ നിന്ന് ട്രാഫിക് സ്വീകരിക്കാൻ നിങ്ങൾ അതിനെ വ്യക്തമായി അനുവദിക്കണം. ഏതെങ്കിലും നയം വഴി ഒരു പോഡ് തിരഞ്ഞെടുത്തിട്ടില്ലെങ്കിൽ, അതിനുള്ള എല്ലാ പ്രവേശന ട്രാഫിക്കും ഡിഫോൾട്ടായി അനുവദനീയമാണ്.

താഴെ സ്റ്റേറ്റ്‌ഫുൾ അല്ലെങ്കിൽ സ്റ്റേറ്റ്‌ലെസ് കാണുക.

രേഖകൾ

കുബർനെറ്റസ് നെറ്റ്‌വർക്ക് നയങ്ങൾക്ക് ട്രാഫിക് ലോഗ് ചെയ്യാൻ കഴിയില്ല. ഒരു നയം ഉദ്ദേശിച്ച രീതിയിൽ പ്രവർത്തിക്കുന്നുണ്ടോ എന്ന് നിർണ്ണയിക്കാൻ ഇത് ബുദ്ധിമുട്ടാക്കുകയും സുരക്ഷാ വിശകലനത്തെ വളരെയധികം സങ്കീർണ്ണമാക്കുകയും ചെയ്യുന്നു.

ബാഹ്യ സേവനങ്ങളിലേക്കുള്ള ട്രാഫിക് നിയന്ത്രണം

കുബെർനെറ്റസ് നെറ്റ്‌വർക്ക് നയങ്ങൾ, എഗ്രസ് വിഭാഗങ്ങളിൽ പൂർണ്ണ യോഗ്യതയുള്ള ഒരു ഡൊമെയ്ൻ നാമം (DNS) വ്യക്തമാക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നില്ല. ഒരു നിശ്ചിത ഐപി വിലാസം (aws.com പോലുള്ളവ) ഇല്ലാത്ത ബാഹ്യ ലക്ഷ്യസ്ഥാനങ്ങളിലേക്ക് ട്രാഫിക് പരിമിതപ്പെടുത്താൻ ശ്രമിക്കുമ്പോൾ ഈ വസ്തുത കാര്യമായ അസൗകര്യത്തിലേക്ക് നയിക്കുന്നു.

നയ പരിശോധന

ഫയർവാളുകൾ നിങ്ങൾക്ക് മുന്നറിയിപ്പ് നൽകും അല്ലെങ്കിൽ തെറ്റായ നയം അംഗീകരിക്കാൻ പോലും വിസമ്മതിക്കും. കുബെർനെറ്റസ് ചില പരിശോധനകളും നടത്തുന്നു. kubectl വഴി ഒരു നെറ്റ്‌വർക്ക് നയം സജ്ജീകരിക്കുമ്പോൾ, അത് തെറ്റാണെന്ന് കുബർനെറ്റസ് പ്രഖ്യാപിക്കുകയും അത് സ്വീകരിക്കാൻ വിസമ്മതിക്കുകയും ചെയ്തേക്കാം. മറ്റ് സന്ദർഭങ്ങളിൽ, കുബെർനെറ്റസ് പോളിസി എടുത്ത് വിട്ടുപോയ വിശദാംശങ്ങൾ ഉപയോഗിച്ച് പൂരിപ്പിക്കും. കമാൻഡ് ഉപയോഗിച്ച് അവ കാണാൻ കഴിയും:

kubernetes get networkpolicy <policy-name> -o yaml

കുബെർനെറ്റസ് മൂല്യനിർണ്ണയ സംവിധാനം തെറ്റല്ലെന്നും ചില തരത്തിലുള്ള പിശകുകൾ നഷ്‌ടമായേക്കാമെന്നും ഓർമ്മിക്കുക.

വധശിക്ഷ

കുബെർനെറ്റസ് നെറ്റ്‌വർക്ക് നയങ്ങൾ സ്വയം നടപ്പിലാക്കുന്നില്ല, മറിച്ച് കണ്ടെയ്‌നർ നെറ്റ്‌വർക്കിംഗ് ഇന്റർഫേസ് (സിഎൻഐ) എന്ന അടിസ്ഥാന സംവിധാനത്തിലേക്ക് നിയന്ത്രണത്തിന്റെ ഭാരം നിയോഗിക്കുന്ന ഒരു എപിഐ ഗേറ്റ്‌വേ മാത്രമാണ്. ഉചിതമായ CNI നൽകാതെ Kubernetes ക്ലസ്റ്ററിൽ നയങ്ങൾ ക്രമീകരിക്കുന്നത്, ഫയർവാളുകളിൽ ഇൻസ്റ്റാൾ ചെയ്യാതെ ഒരു ഫയർവാൾ മാനേജ്മെന്റ് സെർവറിൽ നയങ്ങൾ സൃഷ്ടിക്കുന്നതിന് തുല്യമാണ്. നിങ്ങൾക്ക് മാന്യമായ ഒരു CNI ഉണ്ടെന്ന് ഉറപ്പാക്കേണ്ടത് നിങ്ങളാണ് അല്ലെങ്കിൽ, കുബർനെറ്റസ് പ്ലാറ്റ്‌ഫോമുകളുടെ കാര്യത്തിൽ, ക്ലൗഡിൽ ഹോസ്റ്റ് ചെയ്‌തിരിക്കുന്നു (ദാതാക്കളുടെ പട്ടിക നിങ്ങൾക്ക് കാണാം ഇവിടെ - ഏകദേശം. ട്രാൻസ്.), നിങ്ങൾക്കായി CNI സജ്ജമാക്കുന്ന നെറ്റ്‌വർക്ക് നയങ്ങൾ പ്രവർത്തനക്ഷമമാക്കുക.

ഉചിതമായ സഹായി CNI ഇല്ലാതെ നിങ്ങൾ ഒരു നെറ്റ്‌വർക്ക് നയം സജ്ജീകരിക്കുകയാണെങ്കിൽ, Kubernetes നിങ്ങൾക്ക് മുന്നറിയിപ്പ് നൽകില്ല എന്നത് ശ്രദ്ധിക്കുക.

സ്‌റ്റേറ്റ്‌ഫുൾ അല്ലെങ്കിൽ സ്റ്റേറ്റ്‌ലെസ്?

ഞാൻ നേരിട്ട എല്ലാ Kubernetes CNI-കളും സ്റ്റേറ്റ്ഫുൾ ആണ് (ഉദാഹരണത്തിന്, Calico Linux contrack ഉപയോഗിക്കുന്നു). ഇത് പുനഃസ്ഥാപിക്കാതെ തന്നെ അത് ആരംഭിച്ച TCP കണക്ഷനിൽ പ്രതികരണങ്ങൾ സ്വീകരിക്കാൻ പോഡിനെ അനുവദിക്കുന്നു. എന്നിരുന്നാലും, സ്റ്റേറ്റ്ഫുൾനെസ് ഉറപ്പുനൽകുന്ന ഒരു കുബർനെറ്റസ് മാനദണ്ഡത്തെക്കുറിച്ച് എനിക്കറിയില്ല.

വിപുലമായ സുരക്ഷാ നയ മാനേജ്മെന്റ്

കുബർനെറ്റസിലെ സുരക്ഷാ നയ നിർവ്വഹണം മെച്ചപ്പെടുത്തുന്നതിനുള്ള ചില വഴികൾ ഇതാ:

1. സേവന തലത്തിൽ വിശദമായ ടെലിമെട്രിയും ട്രാഫിക് നിയന്ത്രണവും നൽകുന്നതിന് സർവീസ് മെഷ് ആർക്കിടെക്ചറൽ പാറ്റേൺ സൈഡ്കാർ കണ്ടെയ്‌നറുകൾ ഉപയോഗിക്കുന്നു. ഒരു ഉദാഹരണമായി നമുക്ക് എടുക്കാം ഇസ്തോ.
2. ചില CNI വെണ്ടർമാർ Kubernetes നെറ്റ്‌വർക്ക് നയങ്ങൾക്കപ്പുറത്തേക്ക് പോകാൻ അവരുടെ ഉപകരണങ്ങൾ വിപുലീകരിച്ചു.
3. തുഫിൻ ഓർക്ക കുബർനെറ്റസ് നെറ്റ്‌വർക്ക് നയങ്ങളുടെ ദൃശ്യപരതയും ഓട്ടോമേഷനും നൽകുന്നു.

Tufin Orca പാക്കേജ് Kubernetes നെറ്റ്‌വർക്ക് നയങ്ങൾ നിയന്ത്രിക്കുന്നു (മുകളിലുള്ള സ്‌ക്രീൻഷോട്ടുകളുടെ ഉറവിടവും).

കൂടുതൽ വിവരങ്ങൾ

• GKE-യിൽ നിന്ന് അഹ്‌മെത് ആൽപ് ബാൽക്കൻ തയ്യാറാക്കിയ നെറ്റ്‌വർക്ക് നയങ്ങളുടെ ഉദാഹരണങ്ങൾ;
• ഔദ്യോഗിക കുബർനെറ്റസ് വെബ്സൈറ്റിൽ നിന്നുള്ള ഡോക്യുമെന്റേഷൻ;
• കുബർനെറ്റസ് നെറ്റ്‌വർക്കിംഗ് മോഡലിലേക്കുള്ള ഒരു ഗൈഡ്;
• നെറ്റ്‌വർക്ക് നയങ്ങൾ പരിശോധിക്കുന്നതിനുള്ള സ്‌ക്രിപ്റ്റ്.

തീരുമാനം

കുബെർനെറ്റസ് നെറ്റ്‌വർക്ക് പോളിസികൾ ക്ലസ്റ്ററുകൾ വിഭജിക്കുന്നതിന് മികച്ച ഒരു കൂട്ടം ടൂളുകൾ വാഗ്ദാനം ചെയ്യുന്നു, എന്നാൽ അവ അവബോധജന്യമല്ല, കൂടാതെ നിരവധി സൂക്ഷ്മതകളുമുണ്ട്. ഈ സങ്കീർണ്ണത കാരണം, നിലവിലുള്ള പല ക്ലസ്റ്റർ നയങ്ങളും ബഗ്ഗിയാണെന്ന് ഞാൻ വിശ്വസിക്കുന്നു. ഈ പ്രശ്നത്തിനുള്ള സാധ്യമായ പരിഹാരങ്ങളിൽ പോളിസി നിർവചനങ്ങൾ ഓട്ടോമേറ്റ് ചെയ്യുന്നതും മറ്റ് സെഗ്മെന്റേഷൻ ടൂളുകൾ ഉപയോഗിക്കുന്നതും ഉൾപ്പെടുന്നു.

ചില ചോദ്യങ്ങൾ മായ്‌ക്കാനും നിങ്ങൾ നേരിട്ടേക്കാവുന്ന പ്രശ്‌നങ്ങൾ പരിഹരിക്കാനും ഈ ഗൈഡ് സഹായിക്കുമെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു.

വിവർത്തകനിൽ നിന്ന് പി.എസ്

ഞങ്ങളുടെ ബ്ലോഗിലും വായിക്കുക:

• "ഇസ്റ്റിയോ ഉപയോഗിച്ച് മൈക്രോസർവീസുകളിലേക്ക് മടങ്ങുക": ഭാഗം 1 (പ്രധാന സവിശേഷതകളിലേക്കുള്ള ആമുഖം), ഭാഗം 2 (റൂട്ടിംഗ്, ട്രാഫിക് നിയന്ത്രണം), ഭാഗം 3 (സുരക്ഷ);
• "കുബർനെറ്റസിലെ നെറ്റ്‌വർക്കിംഗിലേക്കുള്ള ഒരു ചിത്രീകരിച്ച ഗൈഡ്": ഭാഗങ്ങൾ 1, 2 (നെറ്റ്‌വർക്ക് മോഡൽ, ഓവർലേ നെറ്റ്‌വർക്കുകൾ), ഭാഗം 3 (സേവനങ്ങളും ട്രാഫിക് പ്രോസസ്സിംഗും);
• «സുരക്ഷാ സെൻസിറ്റീവ് പരിതസ്ഥിതികളിൽ ഡോക്കറും കുബർനെറ്റും";
• «9 കുബർനെറ്റസ് സുരക്ഷയ്ക്കുള്ള മികച്ച സമ്പ്രദായങ്ങൾ";
• «ഒരു കുബർനെറ്റസ് ഹാക്കിന്റെ ഇരയാകാനുള്ള (അല്ല) 11 വഴികൾ".

അവലംബം: www.habr.com