လုံခြုံရေးကျွမ်းကျင်သူများအတွက် Kubernetes ကွန်ရက်မူဝါဒများကို မိတ်ဆက်ခြင်း။

မှတ်ချက်။ ဘာသာပြန်: ဆောင်းပါးရေးသားသူ Reuven Harrison သည် ဆော့ဖ်ဝဲလ်ဖွံ့ဖြိုးတိုးတက်ရေးတွင် နှစ် 20 ကျော်အတွေ့အကြုံရှိပြီး ယနေ့တွင် လုံခြုံရေးမူဝါဒစီမံခန့်ခွဲမှုဖြေရှင်းချက်များကို ဖန်တီးပေးသည့် ကုမ္ပဏီတစ်ခုဖြစ်သည့် Tufin ၏ CTO နှင့် ပူးတွဲတည်ထောင်သူဖြစ်သည်။ သူက Kubernetes ကွန်ရက်မူဝါဒများကို အစုအဝေးတစ်ခုအတွင်း ကွန်ရက်ခွဲဝေခြင်းအတွက် အလွန်အစွမ်းထက်သည့်ကိရိယာတစ်ခုအဖြစ် ရှုမြင်သော်လည်း ၎င်းတို့သည် လက်တွေ့တွင် အသုံးပြုရလွယ်ကူသည်မဟုတ်ဟုလည်း သူယုံကြည်သည်။ ဤပစ္စည်း (အတော်လေး တောက်ပြောင်လွန်းသည်) သည် ဤပြဿနာနှင့် ပတ်သက်၍ ကျွမ်းကျင်သူများ၏ အသိအမြင်ကို မြှင့်တင်ရန်နှင့် လိုအပ်သော ဖွဲ့စည်းမှုပုံစံများကို ဖန်တီးရန် ကူညီပေးရန်အတွက် ရည်ရွယ်ပါသည်။

ယနေ့တွင်၊ ကုမ္ပဏီများစွာသည် ၎င်းတို့၏ အက်ပ်လီကေးရှင်းများကို လုပ်ဆောင်ရန် Kubernetes ကို ပိုမိုရွေးချယ်လာကြသည်။ ဤဆော့ဖ်ဝဲကို စိတ်ဝင်စားမှု အလွန်မြင့်မားသောကြောင့် အချို့က Kubernetes “ဒေတာစင်တာအတွက် လည်ပတ်မှုစနစ်အသစ်” ဟုခေါ်ဆိုကြသည်။ တဖြည်းဖြည်း၊ Kubernetes (သို့မဟုတ် k8s) သည် လုပ်ငန်း၏အရေးကြီးသောအစိတ်အပိုင်းတစ်ခုအဖြစ် စတင်မြင်လာရပြီး ကွန်ရက်လုံခြုံရေးအပါအဝင် ရင့်ကျက်သောလုပ်ငန်းလုပ်ငန်းစဉ်များကို ဖွဲ့စည်းရန်လိုအပ်ပါသည်။

Kubernetes နှင့် လုပ်ဆောင်ခြင်းဖြင့် ပဟေဋ္ဌိဖြစ်နေသော လုံခြုံရေး ကျွမ်းကျင်သူများအတွက်၊ အမှန်တကယ် ပေါ်ထွန်းမှုသည် ပလပ်ဖောင်း၏ မူရင်းမူဝါဒ ဖြစ်နိုင်သည်- အရာအားလုံးကို ခွင့်ပြုပါ။

ဤလမ်းညွှန်ချက်သည် ကွန်ရက်မူဝါဒများ၏ အတွင်းပိုင်းဖွဲ့စည်းပုံကို နားလည်ရန် ကူညီပေးပါမည်။ ပုံမှန် firewall များအတွက် စည်းမျဉ်းများနှင့် မည်သို့ကွာခြားသည်ကို နားလည်ပါ။ ၎င်းသည် အချို့သောအခက်အခဲများကို ဖုံးအုပ်ကာ Kubernetes ပေါ်ရှိ အပလီကေးရှင်းများကို လုံခြုံစေရန် ကူညီရန် အကြံပြုချက်များ ပေးမည်ဖြစ်သည်။

Kubernetes ကွန်ရက်မူဝါဒများ

Kubernetes ကွန်ရက်မူဝါဒယန္တရားသည် သင့်အား ကွန်ရက်အလွှာ (OSI မော်ဒယ်တွင် တတိယမြောက်) ပလပ်ဖောင်းပေါ်တွင် အသုံးပြုသည့် ပလပ်ဖောင်းပေါ်တွင် အသုံးပြုသည့် အပလီကေးရှင်းများ၏ အပြန်အလှန်တုံ့ပြန်မှုကို စီမံခန့်ခွဲရန် ခွင့်ပြုသည်။ ကွန်ရက်မူဝါဒများဖြစ်သည့် OSI Layer 7 ထိန်းသိမ်းရေးနှင့် ခြိမ်းခြောက်မှုကို ထောက်လှမ်းခြင်းကဲ့သို့သော ခေတ်မီ firewall များ၏ အဆင့်မြင့်အင်္ဂါရပ်အချို့ ချို့တဲ့သော်လည်း ၎င်းတို့သည် ကောင်းမွန်သော အစမှတ်ဖြစ်သည့် ကွန်ရက်လုံခြုံရေး၏ အခြေခံအဆင့်ကို ပေးဆောင်ပါသည်။

ကွန်ရက်မူဝါဒများသည် pods များအကြား ဆက်သွယ်မှုများကို ထိန်းချုပ်သည်။

Kubernetes ရှိ အလုပ်ဝန်များကို ပေါင်းစည်းထားသည့် ကွန်တိန်နာတစ်ခု သို့မဟုတ် တစ်ခုထက်ပိုသော ကွန်တိန်နာများပါရှိသော ဘူးများပေါ်တွင် ဖြန့်ခွဲထားသည်။ Kubernetes သည် အခြား pods များမှ ဝင်ရောက်နိုင်သော IP လိပ်စာတစ်ခုစီကို သတ်မှတ်ပေးသည်။ Kubernetes ကွန်ရက်မူဝါဒများသည် cloud ရှိ လုံခြုံရေးအဖွဲ့များကို virtual machine instances များသို့ဝင်ရောက်ခွင့်ကို ထိန်းချုပ်ရန်အတွက် cloud ရှိ လုံခြုံရေးအဖွဲ့များကို အသုံးပြုသည့်နည်းလမ်းအတိုင်း pods အဖွဲ့များအတွက် ဝင်ရောက်ခွင့်ကို သတ်မှတ်ပေးပါသည်။

ကွန်ရက်မူဝါဒများကို သတ်မှတ်ခြင်း။

အခြားသော 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

(မှတ်ချက်။ ဘာသာပြန်: ဤဖန်သားပြင်ဓာတ်ပုံကို နောက်ဆက်တွဲအလားသဏ္ဍာန်တူသည့်အရာအားလုံးကဲ့သို့ပင် မူရင်းဆောင်းပါးရှင်၏ကုမ္ပဏီမှ ဖန်တီးထားသည့် Tufin Orca တူးလ်ကို အသုံးပြု၍ အကြောင်းအရာ၏အဆုံးတွင် ဖော်ပြထားသည့် မူရင်း Kubernetes တူးလ်များကို အသုံးပြု၍ ဖန်တီးထားသည်။)

သင့်ကိုယ်ပိုင် ကွန်ရက်မူဝါဒကို သတ်မှတ်ရန် YAML ၏ အခြေခံအသိပညာ လိုအပ်ပါသည်။ ဤဘာသာစကားသည် တဘ်များထက် နေရာကွက်များထက် ကွက်ကွက်များဖြင့် ဖော်ပြခြင်းအပေါ် အခြေခံထားသည်။ အင်တင်းလုပ်ထားသောဒြပ်စင်သည် ၎င်းအပေါ်ရှိ အနီးဆုံးအင်တင်းလုပ်ထားသောဒြပ်စင်ဖြစ်သည်။ စာရင်းဒြပ်စင်အသစ်သည် တုံးတိုဖြင့်စတင်သည်၊ အခြားဒြပ်စင်အားလုံးတွင် ပုံစံရှိသည်။ သော့တန်ဖိုး.

မူဝါဒကို YAML တွင် ဖော်ပြထားပြီး အသုံးပြုပါ။ kubectl၎င်းကို အစုအဝေးတွင် ဖန်တီးရန်-

kubectl create -f policy.yaml

ကွန်ရက်မူဝါဒ သတ်မှတ်ချက်

Kubernetes ကွန်ရက်မူဝါဒ သတ်မှတ်ချက်တွင် အချက်လေးချက် ပါဝင်သည်-

1. podSelector: ဤမူဝါဒ (ပစ်မှတ်များ) မှ သက်ရောက်မှုရှိသော အကွက်များကို သတ်မှတ်သည် - လိုအပ်သည်;
2. policyTypes: ဤတွင် ပါဝင်သည့် မူဝါဒအမျိုးအစားများကို ညွှန်ပြသည်- အဝင်နှင့်/သို့မဟုတ် egress - ရွေးချယ်နိုင်သည်၊ သို့သော် ၎င်းကို ကိစ္စရပ်တိုင်းတွင် အတိအလင်းသတ်မှတ်ရန် အကြံပြုပါသည်။
3. ingressခွင့်ပြု: ဲ ဝင်လာသော ပစ်မှတ် pods များဆီသို့ အသွားအလာ - ရွေးချယ်နိုင်သည်;
4. egressခွင့်ပြု: ဲ အထွက် ပစ်မှတ် pods များမှ traffic သည် ရွေးချယ်နိုင်သည်။

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အခြား parameters များကိုအလိုရှိသောအတိုင်းအသုံးပြုနိုင်ပါသည်။

ချန်လှပ်ထားလျှင် policyTypesမူဝါဒကို အောက်ပါအတိုင်း အဓိပ္ပာယ်ဖွင့်ဆိုပါမည်။

• ပုံမှန်အားဖြင့်၊ ၎င်းသည် ingress side ကို သတ်မှတ်သည်ဟု ယူဆသည်။ မူဝါဒတွင် ယင်းကို အတိအလင်း မဖော်ပြထားပါက၊ လမ်းကြောင်းအားလုံးကို တားမြစ်ထားကြောင်း စနစ်က ယူဆမည်ဖြစ်သည်။
• egress ဘက်ခြမ်းရှိ အပြုအမူကို သက်ဆိုင်ရာ egress parameter ၏ ရှိနေခြင်း သို့မဟုတ် မရှိခြင်းမှ ဆုံးဖြတ်မည်ဖြစ်ပါသည်။

အမှားတွေကို ရှောင်ရှားဖို့ အကြံပြုချင်ပါတယ်။ အမြဲတမ်း ရှင်းပါတယ်။ policyTypes.

အထက်ဖော်ပြပါ ယုတ္တိဗေဒအရဆိုလျှင် ဘောင်များ ingress နှင့် / သို့မဟုတ် egress ချန်လှပ်ထားပါသည်၊ မူဝါဒသည် အသွားအလာအားလုံးကို ငြင်းပယ်လိမ့်မည် (အောက်တွင် "Stripping Rule" ကိုကြည့်ပါ)။

မူရင်းမူဝါဒမှာ Allow ဖြစ်သည်။

မူဝါဒများကို မသတ်မှတ်ထားပါက၊ Kubernetes သည် ပုံမှန်အားဖြင့် အသွားအလာအားလုံးကို ခွင့်ပြုသည်။ pods များအားလုံး အချင်းချင်း လွတ်လပ်စွာ သတင်းဖလှယ်နိုင်သည်။ ၎င်းသည် လုံခြုံရေးရှုထောင့်မှ ဆန့်ကျင်ဘက်ဟု ထင်ရသော်လည်း Kubernetes သည် အက်ပ်လီကေးရှင်း အပြန်အလှန်လုပ်ဆောင်နိုင်မှုကို ဖွင့်ရန်အတွက် ဆော့ဖ်ဝဲအင်ဂျင်နီယာများက မူလက ဒီဇိုင်းထုတ်ထားကြောင်း သတိရပါ။ ကွန်ရက်မူဝါဒများကို နောက်ပိုင်းတွင် ထည့်သွင်းခဲ့သည်။

အမည်နေရာများ

Namespaces များသည် Kubernetes ပူးပေါင်းဆောင်ရွက်သည့် ယန္တရားဖြစ်သည်။ ၎င်းတို့သည် ယုတ္တိတန်သောပတ်ဝန်းကျင်များကို တစ်ခုနှင့်တစ်ခု ခွဲထုတ်ရန် ဒီဇိုင်းထုတ်ထားပြီး၊ spaces များကြား ဆက်သွယ်မှုကို မူရင်းအတိုင်း ခွင့်ပြုထားသည်။

Kubernetes အစိတ်အပိုင်းအများစုကဲ့သို့ပင်၊ ကွန်ရက်မူဝါဒများသည် သီးခြား namespace တွင် ရှိနေသည်။ ဘလောက်ထဲမှာ metadata မူဝါဒတွင် မည်သည့်နေရာကို သင်သတ်မှတ်နိုင်သည်-

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

အကယ်၍ namespace ကို metadata တွင် ပြတ်သားစွာ မဖော်ပြထားပါက၊ စနစ်သည် kubectl တွင် သတ်မှတ်ထားသော namespace ကို အသုံးပြုလိမ့်မည် (ပုံမှန်အားဖြင့် namespace=default):

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

ကျွန်တော်အကြံပြုသည်မှာ namespace ကို အတိအလင်း သတ်မှတ်ပါ။အမည်နေရာကွက်များစွာကို တစ်ပြိုင်နက် ပစ်မှတ်ထားမည့် မူဝါဒကို သင်မရေးထားပါက၊

မူလတန်း ဓါတ် podSelector မူဝါဒတွင် မူဝါဒပိုင်ဆိုင်သည့် namespace မှ pods များကို ရွေးချယ်ပါမည် (၎င်းကို အခြား namespace မှ pods များသို့ ဝင်ရောက်ခွင့် ငြင်းပယ်ထားသည်)။

အလားတူပင်၊ podSelectors ingress နှင့် egress လုပ်ကွက်များ ၎င်းတို့နှင့် ပေါင်းစပ်ထားခြင်းမရှိပါက ၎င်းတို့၏ကိုယ်ပိုင် namespace မှ pods များကိုသာ ရွေးချယ်နိုင်သည်။ namespaceSelector (၎င်းကို “အမည်ကွက်များနှင့် ကွက်များအလိုက် စစ်ထုတ်ခြင်း” ကဏ္ဍတွင် ဆွေးနွေးပါမည်။)

မူဝါဒအမည်ပေးခြင်း စည်းကမ်းများ

မူဝါဒအမည်များသည် တူညီသော namespace အတွင်း ထူးခြားပါသည်။ နေရာတစ်ခုတည်းတွင် နာမည်တူသော မူဝါဒနှစ်ခု မရှိနိုင်သော်လည်း မတူညီသောနေရာများတွင် နာမည်တူမူဝါဒများ ရှိနိုင်ပါသည်။ နေရာအများအပြားတွင် တူညီသောမူဝါဒကို ပြန်လည်အသုံးချလိုသည့်အခါ ၎င်းသည် အသုံးဝင်သည်။

အထူးသဖြင့် နာမည်ပေးနည်းကို ကြိုက်တယ်။ ၎င်းတွင် namespace အမည်ကို ပစ်မှတ် pods များနှင့် ပေါင်းစပ်ခြင်း ပါဝင်သည်။ ဥပမာအားဖြင့်:

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

တံဆိပ်များ

pods နှင့် namespaces ကဲ့သို့သော Kubernetes အရာဝတ္ထုများသို့ စိတ်ကြိုက်တံဆိပ်များ ပူးတွဲနိုင်ပါသည်။ တံဆိပ်များ (တံဆိပ်များ - tags) များသည် cloud ရှိ tag များနှင့် ညီမျှသည်။ Kubernetes ကွန်ရက်မူဝါဒများကို ရွေးချယ်ရန် အညွှန်းများကို အသုံးပြုသည်။ pods၎င်းတို့လျှောက်ထားသော၊

podSelector:
  matchLabels:
    role: db

… သို့မဟုတ် အမည်နေရာများသူတို့ လျှောက်ထားသည်။ ဤဥပမာသည် သက်ဆိုင်ရာတံဆိပ်များနှင့်အတူ namespaces တွင် pods အားလုံးကို ရွေးသည်-

namespaceSelector:
  matchLabels:
    project: myproject

တစ်ခုသတိထားပါ။ namespaceSelector သင်ရွေးချယ်သော namespace များတွင် မှန်ကန်သော အညွှန်းပါ၀င်ကြောင်း သေချာပါစေ။. ကဲ့သို့သော built-in namespaces ကိုသတိထားပါ။ default и kube-systemပုံမှန်အားဖြင့်၊ အညွှန်းများမပါဝင်ပါ။

ဤကဲ့သို့သောနေရာတစ်ခုသို့ အညွှန်းတစ်ခုထည့်နိုင်သည်။

kubectl label namespace default namespace=default

တစ်ချိန်တည်းမှာပင်၊ အပိုင်းရှိ namespace metadata အညွှန်းမဟုတ်ဘဲ တကယ့်နေရာအမည်ကို ရည်ညွှန်းသင့်သည်-

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

အရင်းအမြစ်နှင့် ဦးတည်ရာ

Firewall မူဝါဒများတွင် အရင်းအမြစ်များနှင့် ဦးတည်ရာများပါရှိသော စည်းမျဉ်းများပါဝင်သည်။ Kubernetes ကွန်ရက်ပေါ်လစီများကို ပစ်မှတ်တစ်ခုအတွက် သတ်မှတ်ထားသည် - ၎င်းတို့လျှောက်ထားသည့် pods အစုတစ်ခု - ထို့နောက် အဝင်နှင့်/သို့မဟုတ် egress traffic အတွက် စည်းမျဉ်းများ သတ်မှတ်သည်။ ကျွန်ုပ်တို့၏ဥပမာတွင်၊ မူဝါဒ၏ပစ်မှတ်သည် namespace ရှိ pods အားလုံးဖြစ်လိမ့်မည်။ 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 ဤမူဝါဒတွင်၊ ပစ်မှတ် pods များဆီသို့ အဝင်လမ်းကြောင်းကို ဖွင့်ပေးသည်။ တစ်နည်းဆိုရသော် Ingress သည် အရင်းအမြစ်ဖြစ်ပြီး ပစ်မှတ်သည် သက်ဆိုင်ရာ ဦးတည်ရာဖြစ်သည်။ အလားတူပင်၊ egress သည် ဦးတည်ရာဖြစ်ပြီး ပစ်မှတ်သည် ၎င်း၏အရင်းအမြစ်ဖြစ်သည်။

၎င်းသည် firewall စည်းမျဉ်းနှစ်ခုနှင့် ညီမျှသည်- Ingress → Target; ပန်းတိုင် → Egress ။

Egress နှင့် DNS (အရေးကြီးပါသည်။)

အထွက်လမ်းကြောင်းကို ကန့်သတ်ခြင်းဖြင့်၊ DNS ကို အထူးဂရုပြုပါ။ - Kubernetes သည် ဝန်ဆောင်မှုများကို IP လိပ်စာများသို့ မြေပုံဆွဲရန် ဤဝန်ဆောင်မှုကို အသုံးပြုသည်။ ဥပမာအားဖြင့်၊ သင်သည် လျှောက်လွှာကို ခွင့်မပြုသောကြောင့် အောက်ပါမူဝါဒသည် အလုပ်မဖြစ်ပါ။ balance DNS ကို အသုံးပြုခွင့်-

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  policyTypes:
  - Egress

DNS ဝန်ဆောင်မှုကို ဖွင့်ဝင်ရောက်ခြင်းဖြင့် ၎င်းကို သင်ပြင်နိုင်သည်-

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:               # <<<
    ports:            # <<<
    - protocol: UDP   # <<<
      port: 53        # <<<
  policyTypes:
  - Egress

နောက်ဆုံးအချက် to ဗလာဖြစ်ပြီး ထို့ကြောင့် ၎င်းသည် သွယ်ဝိုက်၍ ရွေးချယ်သည်။ နာမည်နေရာများအားလုံးတွင် pods များအားလုံး, ခွင့်ပြုသည်။ 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. namespace အတွင်းတွင် DNS မေးမြန်းမှုများကိုသာ ခွင့်ပြုပါ။ kube-system.

၎င်းကိုပြုလုပ်ရန်အတွက် namespace တွင် အညွှန်းတစ်ခုထည့်ရန်လိုအပ်သည်။ 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. "အမည်ကွက်များနှင့် ကွက်များအလိုက် စစ်ထုတ်ခြင်း" ကဏ္ဍတွင် ၎င်းကို အောင်မြင်ရန် မည်သို့လုပ်ဆောင်ရမည်ကို ပြောပြပါမည်။

အခြားရွေးချယ်စရာမှာ namespace အဆင့်တွင် 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 namespace တွင် pods အားလုံးကို ရွေးသည်။

ပထမပွဲနှင့် စည်းကမ်းအမိန့်

သမားရိုးကျ firewall များတွင် packet တစ်ခုပေါ်ရှိ လုပ်ဆောင်ချက် (Allow or Deny) ကို ၎င်းကျေနပ်သည့် ပထမစည်းမျဉ်းဖြင့် ဆုံးဖြတ်သည်။ Kubernetes တွင်၊ မူဝါဒအစီအစဥ်သည် အရေးမကြီးပါ။

ပုံမှန်အားဖြင့်၊ မူဝါဒများကို မသတ်မှတ်ထားသည့်အခါ pods များကြား ဆက်သွယ်မှုများကို ခွင့်ပြုထားပြီး ၎င်းတို့သည် လွတ်လပ်စွာ သတင်းအချက်အလက်ဖလှယ်နိုင်သည်။ မူဝါဒများကို စတင်ရေးဆွဲပြီးသည်နှင့်၊ ၎င်းတို့ထဲမှ အနည်းဆုံးတစ်ခုမှ သက်ရောက်မှုရှိသော အချိတ်အဆက်တစ်ခုစီသည် ၎င်းအား ရွေးချယ်ထားသည့် မူဝါဒအားလုံး၏ ကွဲလွဲမှု (ယုတ္တိ OR) အရ သီးခြားဖြစ်လာသည်။ မူဝါဒတစ်ခုခုကြောင့် ထိခိုက်မှုမရှိသော Pods များကို ဆက်လက်ဖွင့်ထားသည်။

ဖယ်ရှားခြင်းစည်းမျဉ်းကို အသုံးပြု၍ ဤအပြုအမူကို သင်ပြောင်းလဲနိုင်သည်။

ဖယ်ရှားခြင်းဆိုင်ရာ စည်းမျဉ်း ("ငြင်းဆို")

Firewall မူဝါဒများသည် ပုံမှန်အားဖြင့် ပြတ်သားစွာ ခွင့်မပြုသော မည်သည့်အသွားအလာကိုမဆို ငြင်းဆိုပါသည်။

Kubernetes တွင် ငြင်းဆိုခြင်း လုပ်ဆောင်ချက် မရှိပါ။သို့ရာတွင်၊ ပုံမှန် (ခွင့်ပြုချက်) ပေါ်လစီဖြင့် အလားတူအကျိုးသက်ရောက်မှုအား အရင်းအမြစ် pods (ingress) အုပ်စုအလွတ်တစ်ခုကို ရွေးချယ်ခြင်းဖြင့် အောင်မြင်နိုင်သည်-

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Ingress

ဤမူဝါဒသည် namespace တွင် pods အားလုံးကို ရွေးချယ်ပြီး ingress ကို သတ်မှတ်မထားပါ။ အဝင်လမ်းကြောင်းအားလုံးကို ငြင်းပယ်သည်။

အလားတူနည်းဖြင့်၊ သင်သည် namespace မှ ထွက်အသွားအလာအားလုံးကို ကန့်သတ်နိုင်သည်-

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-egress
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress

သတိပြုပါ namespace တွင် pods များသို့ traffic ကိုခွင့်ပြုသောနောက်ထပ်မူဝါဒများမဆိုဤစည်းမျဉ်းထက်သာလွန်ပါမည်။ ( firewall configuration တွင် ငြင်းချက်စည်းကမ်းတစ်ခုရှေ့တွင် ခွင့်ပြုထားသော စည်းကမ်းကို ပေါင်းထည့်ခြင်းနှင့် ဆင်တူသည်)။

အားလုံးခွင့်ပြုပါ (Any-Any-Any-Allow)

Allow All မူဝါဒကို ဖန်တီးရန်၊ သင်သည် အထက်ဖော်ပြပါ ငြင်းဆိုမှုမူဝါဒကို အလွတ်ဒြပ်စင်တစ်ခုဖြင့် ဖြည့်စွက်ရန် လိုအပ်သည်။ ingress:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all
  namespace: default
spec:
  podSelector: {}
  ingress: # <<<
  - {}     # <<<
  policyTypes:
  - Ingress

တို့မှ ဝင်ရောက်ခွင့်ပြုသည်။ namespaces များအားလုံး (နှင့် IP များအားလုံး) ရှိ pods အားလုံးကို namespace ရှိမည်သည့် pod သို့မဆို default. ဤအပြုအမူကို ပုံသေအားဖြင့် ဖွင့်ထားသောကြောင့် ၎င်းကို အများအားဖြင့် ထပ်မံသတ်မှတ်ရန်မလိုအပ်ပါ။ သို့သော်၊ တစ်ခါတစ်ရံတွင် သင်သည် ပြဿနာကို ရှာဖွေဖော်ထုတ်ရန် အချို့သော သီးခြားခွင့်ပြုချက်များကို ယာယီပိတ်ထားရန် လိုအပ်နိုင်သည်။

ဝင်ရောက်ခွင့်ပြုရန် စည်းမျဉ်းကို ကျဉ်းမြောင်းစေနိုင်သည်။ သီးခြား pods အစုံ (app:balance) namespace မှာ 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

မူဝါဒများစွာကို ပေါင်းစပ်ခြင်း။

မူဝါဒများကို အဆင့်သုံးဆင့်ဖြင့် ယုတ္တိနည်း သို့မဟုတ် ပေါင်းစပ်ထားသည်။ pod တစ်ခုစီ၏ ခွင့်ပြုချက်များကို ၎င်းအပေါ် သက်ရောက်မှုရှိသော မူဝါဒအားလုံး၏ ကွဲလွဲမှုနှင့်အညီ သတ်မှတ်ထားသည်-

1. လယ်ကွင်း from и to ဒြပ်စင်သုံးမျိုးကို သတ်မှတ်နိုင်သည် (အားလုံးသည် OR ကို အသုံးပြု၍ ပေါင်းစပ်ထားသည်)။

• namespaceSelector — namespace တစ်ခုလုံးကို ရွေးပေးသည် ။
• 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 နှင့်လည်း ပေါင်းစပ်ထားသည်။

သို့သော် ၎င်းတို့ကို ပေါင်းစပ်သည့်အခါတွင် ကန့်သတ်ချက်တစ်ခုရှိသည်။ ထောက်ပြသည် Chris Cooney: Kubernetes သည် မတူညီသော မူဝါဒများနှင့်သာ ပေါင်းစပ်နိုင်သည်။ policyTypes (Ingress သို့မဟုတ် Egress) အဝင်အထွက် (သို့မဟုတ် egress) ကို သတ်မှတ်သည့် မူဝါဒများသည် တစ်ခုနှင့်တစ်ခု ထပ်ရေးပါမည်။

namespaces အကြားဆက်စပ်မှု

မူရင်းအတိုင်း၊ namespaces များအကြား သတင်းအချက်အလက်မျှဝေခြင်းကို ခွင့်ပြုထားသည်။ အဝင်အထွက်နှင့်/သို့မဟုတ် namespace သို့ အဝင်အထွက်ကို ကန့်သတ်မည့် ငြင်းဆိုမှုမူဝါဒကို အသုံးပြုခြင်းဖြင့် ၎င်းကို ပြောင်းလဲနိုင်သည် (အထက် "Stripping Rule" ကိုကြည့်ပါ)။

namespace တစ်ခုသို့ သင်ဝင်ရောက်ခွင့်ကို ပိတ်ဆို့လိုက်သည်နှင့် (အထက် "Stripping Rule" ကိုကြည့်ပါ)၊ သင်သည် သီးခြား namespace ကိုအသုံးပြု၍ ချိတ်ဆက်မှုများကို ခွင့်ပြုခြင်းဖြင့် ငြင်းပယ်ခြင်းမူဝါဒအား ခြွင်းချက်အဖြစ် သင်လုပ်နိုင်သည် 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

ရလဒ်အနေဖြင့် namespace ရှိ pods များအားလုံး default pods များဝင်ရောက်ခွင့်ရရှိမည်ဖြစ်သည်။ postgres namespace တွင် database. ဒါပေမယ့် ဖွင့်ချင်ရင် ဘယ်လိုဝင်နိုင်မလဲ။ postgres namespace တွင် သီးခြား pods များသာ default?

namespaces နှင့် pods များဖြင့် စစ်ထုတ်ပါ။

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 ကို အသုံးပြု.

သီးခြားတံဆိပ်တစ်ခုဖြင့် pods ကိုရွေးချယ်ရန် namespaces အားလုံးမှာ, blank ကိုရိုက်ထည့်ပါ။ 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 နှင့် ပေါင်းစပ်ထားသည်။

အရာများစွာရှိသော firewall အတွက် စည်းမျဉ်းများ (အိမ်ရှင်များ၊ ကွန်ရက်များ၊ အုပ်စုများ) ကို logical OR ဖြင့် ပေါင်းစပ်ထားသည်။ ပက်ကက်ရင်းမြစ်နှင့် ကိုက်ညီပါက အောက်ပါစည်းမျဉ်းသည် အလုပ်လုပ်ပါမည်။ Host_1 OR Host_2:

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

ဆန့်ကျင်ဘက်တွင်၊ Kubernetes တွင် တံဆိပ်အမျိုးမျိုးရှိသည်။ podSelector သို့မဟုတ် namespaceSelector ယုတ္တိဗေဒ AND နှင့် ပေါင်းစပ်ထားသည်။ ဥပမာအားဖြင့်၊ အောက်ဖော်ပြပါ စည်းမျဉ်းသည် အညွှန်းနှစ်ခုလုံးပါရှိသော pods များကို ရွေးချယ်မည်၊ role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

တူညီသော ယုတ္တိဗေဒသည် အော်ပရေတာ အမျိုးအစားအားလုံးနှင့် သက်ဆိုင်သည်- မူဝါဒ ပစ်မှတ် ရွေးချယ်သူများ၊ ပေါ့ဒ် ရွေးချယ်သူများ နှင့် namespace ရွေးချယ်သူများ။

Subnets နှင့် IP လိပ်စာများ (IPBlocks)

Firewall များသည် ကွန်ရက်တစ်ခုကို ခွဲခြမ်းရန် VLAN များ၊ IP လိပ်စာများနှင့် subnet များကို အသုံးပြုသည်။

Kubernetes တွင်၊ IP လိပ်စာများကို pods များသို့ အလိုအလျောက်သတ်မှတ်ပေးထားပြီး မကြာခဏပြောင်းလဲနိုင်သောကြောင့် ကွန်ရက်မူဝါဒများတွင် pods နှင့် namespaces များကို ရွေးချယ်ရန်အတွက် အညွှန်းများကို အသုံးပြုပါသည်။

ကွန်ရက်များ (ipBlocks) အဝင် (အဝင်) သို့မဟုတ် အထွက် (egress) ပြင်ပ (မြောက်-တောင်) ချိတ်ဆက်မှုများကို စီမံရာတွင် အသုံးပြုသည်။ ဥပမာအားဖြင့်၊ ဤမူဝါဒသည် namespace မှ pods အားလုံးကိုဖွင့်သည်။ default Google DNS ဝန်ဆောင်မှုသို့ ဝင်ရောက်ခွင့်-

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

ဤဥပမာရှိ အချည်းနှီးသော ပေါ့ဒ်ရွေးချယ်သည့်ကိရိယာသည် "အမည်နေရာရှိ အကွက်အားလုံးကို ရွေးပါ" ကို ဆိုလိုသည်။

ဤမူဝါဒသည် 8.8.8.8 သို့သာ ဝင်သုံးခွင့်ပြုသည်။ အခြား IP တစ်ခုခုကို အသုံးပြုခွင့်ကို တားမြစ်ထားသည်။ ထို့ကြောင့်၊ အနှစ်သာရအားဖြင့်၊ သင်သည် အတွင်း Kubernetes DNS ဝန်ဆောင်မှုသို့ ဝင်ရောက်ခွင့်ကို ပိတ်ဆို့ထားသည်။ အဲဒါကို ဖွင့်ချင်သေးရင် ဒါကို အတိအလင်း ဖော်ပြပါ။

များသောအားဖြင့် ipBlocks и podSelectors pods များ၏ အတွင်း IP လိပ်စာများကို အသုံးမပြုသောကြောင့် နှစ်ဦးနှစ်ဖက် သီးသန့်ဖြစ်သည်။ ipBlocks. ညွှန်ပြခြင်းဖြင့် အတွင်းပိုင်း IP pod များသင်သည် ဤလိပ်စာများဖြင့် pods များသို့ ချိတ်ဆက်မှုများကို အမှန်တကယ် ခွင့်ပြုပါမည်။ လက်တွေ့တွင်၊ မည်သည့် IP လိပ်စာကို အသုံးပြုရမည်ကို သင်မသိနိုင်သောကြောင့် ၎င်းတို့ကို pods ရွေးရန် အသုံးမပြုသင့်ပါ။

တန်ပြန်ဥပမာအနေဖြင့်၊ အောက်ဖော်ပြပါမူဝါဒတွင် IP များအားလုံးပါဝင်ပြီး ထို့ကြောင့် အခြားသော pods များအားလုံးကို ဝင်ရောက်ကြည့်ရှုခွင့်ပေးသည်-

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

pods များ၏အတွင်းပိုင်း IP လိပ်စာများမပါဝင်ဘဲ ပြင်ပ IP များသို့သာ ဝင်ရောက်ကြည့်ရှုနိုင်ပါသည်။ ဥပမာအားဖြင့်၊ သင့် pod ၏ subnet သည် 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

ဆိပ်ကမ်းများနှင့် ပရိုတိုကောများ

ပုံမှန်အားဖြင့် pods များသည် port တစ်ခုတွင် နားထောင်သည်။ ဆိုလိုသည်မှာ သင်သည် မူဝါဒများတွင် ပို့တ်နံပါတ်များကို ရိုးရိုးရှင်းရှင်း သတ်မှတ်၍ မရဘဲ အရာအားလုံးကို ပုံသေအဖြစ် ထားခဲ့နိုင်သည်။ သို့ရာတွင်၊ မူဝါဒများကို တတ်နိုင်သမျှ ကန့်သတ်ရန် အကြံပြုထားသောကြောင့် အချို့ကိစ္စများတွင် သင်သည် ဆိပ်ကမ်းများကို သတ်မှတ်နိုင်ပါသေးသည်။

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 block ရှိ အစိတ်အပိုင်းအားလုံးနှင့် သက်ဆိုင်သည်။ 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

ပုံသေ ဆိပ်ကမ်း လုပ်ဆောင်ချက်-

• port အဓိပ္ပါယ်ကို လုံးဝ ချန်လှပ်ထားရင် (ports) ၎င်းသည် ပရိုတိုကောအားလုံးနှင့် ဆိပ်ကမ်းအားလုံးကို ဆိုလိုသည်။
• ပရိုတိုကော အဓိပ္ပါယ်ကို ချန်လှပ်ထားလျှင် (protocol) ဆိုလိုသည်မှာ TCP;
• port အဓိပ္ပါယ်ကို ချန်လှပ်ထားလျှင် (port) ဒါက port အားလုံးကို ဆိုလိုတာပါ။

အကောင်းဆုံးအလေ့အကျင့်- မူရင်းတန်ဖိုးများကို အားမကိုးပါနှင့်၊ သင်လိုအပ်သောအရာကို ပြတ်သားစွာ သတ်မှတ်ပါ။

ဝန်ဆောင်မှုဆိပ်ကမ်းများမဟုတ်ဘဲ pod ports များကို အသုံးပြုရမည်ဖြစ်ကြောင်း ကျေးဇူးပြု၍ သတိပြုပါ (နောက်စာပိုဒ်တွင် ဤအရာအား နောက်ထပ်လေ့လာပါ)။

pods သို့မဟုတ် ဝန်ဆောင်မှုများအတွက် မူဝါဒများသတ်မှတ်ထားပါသလား။

ပုံမှန်အားဖြင့်၊ Kubernetes ရှိ pods များသည် ဝန်ဆောင်မှုကို အကောင်အထည်ဖော်သည့် pods များသို့ လမ်းကြောင်းပြောင်းပေးသည့် virtual load balancer ဝန်ဆောင်မှုတစ်ခုမှတဆင့် အပြန်အလှန်ဝင်ရောက်ကြသည်။ ကွန်ရက်မူဝါဒများသည် ဝန်ဆောင်မှုများသို့ ဝင်ရောက်ခွင့်ကို ထိန်းချုပ်သည်ဟု သင်ထင်ကောင်းထင်နိုင်သော်လည်း ၎င်းမှာ ထိုသို့မဟုတ်ပါ။ Kubernetes ကွန်ရက်မူဝါဒများသည် ဝန်ဆောင်မှုဆိပ်ကမ်းများမဟုတ်ဘဲ pod ports များတွင် အလုပ်လုပ်ပါသည်။

ဥပမာအားဖြင့်၊ ဝန်ဆောင်မှုတစ်ခုသည် port 80 ကိုနားထောင်သော်လည်း ၎င်း၏ pods များ၏ port 8080 သို့ traffic ကိုပြန်ညွှန်းပါက၊ သင်သည် network policy တွင် 8080 ကိုအတိအကျသတ်မှတ်ရပါမည်။

ထိုသို့သော ယန္တရားအား အသင့်တော်ဆုံးဟု ယူဆသင့်သည်- ဝန်ဆောင်မှု၏ အတွင်းပိုင်းဖွဲ့စည်းပုံ (Pods နားထောင်သည့် ဆိပ်ကမ်းများ) ပြောင်းလဲပါက ကွန်ရက်မူဝါဒများကို အပ်ဒိတ်လုပ်ရမည်ဖြစ်ပါသည်။

Service Mesh ကို အသုံးပြု၍ ဗိသုကာဆိုင်ရာချဉ်းကပ်မှုအသစ် (ဥပမာ၊ အောက်တွင် Istio အကြောင်းကြည့်ပါ - အနီးစပ်ဆုံး ဘာသာပြန်ပါသည်။) ဒီပြဿနာကို ရင်ဆိုင်နိုင်ရမယ်။

Ingress နှင့် Egress နှစ်မျိုးလုံးကို စာရင်းသွင်းရန် လိုအပ်ပါသလား။

တိုတောင်းသောအဖြေမှာ ဟုတ်ကဲ့၊ pod A သည် pod B နှင့် ဆက်သွယ်ရန်အတွက် အထွက်ချိတ်ဆက်မှုတစ်ခုဖန်တီးရန် ခွင့်ပြုရပါမည် (ဤအတွက် သင်သည် egress မူဝါဒကို ပြင်ဆင်ရန် လိုအပ်သည်) နှင့် pod B သည် အဝင်ချိတ်ဆက်မှုကို လက်ခံနိုင်ရမည် ( ဤအတွက်ကြောင့်၊ သင်သည် ingress policy လိုအပ်ပါသည်။) policy)။

သို့သော် လက်တွေ့တွင်၊ လမ်းကြောင်းတစ်ခု သို့မဟုတ် နှစ်ခုစလုံးတွင် ချိတ်ဆက်မှုများကို ခွင့်ပြုရန် မူရင်းမူဝါဒကို သင်အားကိုးနိုင်သည်။

အချိုမှုန့်ဆိုရင်-အရင်းအမြစ် တစ်ခု သို့မဟုတ် တစ်ခုထက်ပိုသော ရွေးချယ်မည်ဖြစ်သည်။ ထွက်ပေါက်- နိုင်ငံရေးသမားများ၊ ကန့်သတ်ချက်များသည် ၎င်းတို့၏ ကွဲလွဲမှုဖြင့် ဆုံးဖြတ်မည်ဖြစ်သည်။ ဤကိစ္စတွင်၊ သင်သည် pod နှင့်ချိတ်ဆက်မှုကိုအတိအလင်းခွင့်ပြုရန်လိုလိမ့်မည် -လိပ်စာပေးသူထံသို့. pod တစ်ခုအား မည်သည့်မူဝါဒမှ မရွေးချယ်ပါက ၎င်း၏အထွက် (egress) လမ်းကြောင်းကို မူရင်းအတိုင်း ခွင့်ပြုထားသည်။

အလားတူပင် စပါးပင်၏ ကံကြမ္မာလည်း ရှိသည်။လိပ်စာပေးသူတစ်ခု သို့မဟုတ် တစ်ခုထက်ပိုသော ရွေးချယ်ထားသည်။ ingress- နိုင်ငံရေးသမားများသည် ၎င်းတို့၏ ကွဲလွဲမှုဖြင့် ဆုံးဖြတ်မည်ဖြစ်သည်။ ဤကိစ္စတွင်၊ အရင်းအမြစ် pod မှအသွားအလာကိုလက်ခံရန်၎င်းကိုသင်အတိအလင်းခွင့်ပြုရပါမည်။ pod တစ်ခုအား မည်သည့်မူဝါဒမှ မရွေးချယ်ပါက၊ ၎င်းအတွက် အဝင်လမ်းကြောင်းအားလုံးကို မူရင်းအတိုင်း ခွင့်ပြုထားသည်။

အောက်တွင် Stateful သို့မဟုတ် Stateless ကိုကြည့်ပါ။

မှတ်တမ်းများ

Kubernetes ကွန်ရက်မူဝါဒများသည် လမ်းကြောင်းအသွားအလာကို မှတ်တမ်းမတင်နိုင်ပါ။ ယင်းက မူဝါဒတစ်ခုသည် ရည်ရွယ်ထားသည့်အတိုင်း အလုပ်လုပ်ခြင်းရှိမရှိ ဆုံးဖြတ်ရန် ခက်ခဲစေပြီး လုံခြုံရေးဆိုင်ရာ ခွဲခြမ်းစိတ်ဖြာမှုကို အလွန်ရှုပ်ထွေးစေသည်။

ပြင်ပဝန်ဆောင်မှုများသို့ အသွားအလာ ထိန်းချုပ်ခြင်း။

Kubernetes ကွန်ရက်မူဝါဒများသည် ပြင်ပကဏ္ဍများတွင် အရည်အချင်းပြည့်မီသော ဒိုမိန်းအမည် (DNS) ကို သတ်မှတ်ရန် ခွင့်မပြုပါ။ ဤအချက်သည် ပုံသေ IP လိပ်စာမရှိသော ပြင်ပနေရာများသို့ အသွားအလာကန့်သတ်ရန် ကြိုးစားသောအခါတွင် သိသာထင်ရှားသော အဆင်မပြေမှုများ ဖြစ်စေသည်။

မူဝါဒစစ်ဆေးခြင်း။

Firewalls သည် သင့်အား သတိပေးမည် သို့မဟုတ် မှားယွင်းသောမူဝါဒကို လက်ခံရန် ငြင်းဆိုမည်ဖြစ်သည်။ Kubernetes သည်လည်း အတည်ပြုမှုအချို့ ပြုလုပ်ပါသည်။ kubectl မှတစ်ဆင့် ကွန်ရက်မူဝါဒကို သတ်မှတ်သည့်အခါ၊ Kubernetes သည် ၎င်းသည် မှားယွင်းကြောင်း ကြေညာနိုင်ပြီး ၎င်းကို လက်ခံရန် ငြင်းဆိုနိုင်သည်။ အခြားကိစ္စများတွင်၊ Kubernetes သည် မူဝါဒကိုခံယူပြီး ပျောက်ဆုံးနေသောအသေးစိတ်အချက်အလက်များကို ဖြည့်စွက်ပါမည်။ ၎င်းတို့ကို command ကိုအသုံးပြု၍ တွေ့မြင်နိုင်သည်-

kubernetes get networkpolicy <policy-name> -o yaml

Kubernetes အတည်ပြုခြင်းစနစ်သည် အမှားအယွင်းမရှိသည့်အပြင် အချို့သောအမှားအယွင်းများ လွတ်သွားနိုင်ကြောင်း သတိရပါ။

သတ်ခြင်း

Kubernetes သည် ကွန်ရက်မူဝါဒများကို ကိုယ်တိုင်အကောင်အထည်ဖော်ခြင်းမရှိသော်လည်း Container Networking Interface (CNI) ဟုခေါ်သော အရင်းခံစနစ်သို့ ထိန်းချုပ်မှုဝန်ထုပ်ဝန်ပိုးကို လွှဲအပ်ပေးသည့် API တံခါးပေါက်တစ်ခုမျှသာဖြစ်သည်။ သင့်လျော်သော CNI ကို တာဝန်မပေးဘဲ Kubernetes အစုအဝေးတစ်ခုပေါ်ရှိ မူဝါဒများသတ်မှတ်ခြင်းသည် Firewall စီမံခန့်ခွဲမှုဆာဗာတွင် ၎င်းတို့အား တပ်ဆင်ခြင်းမပြုဘဲ firewall တွင် မူဝါဒများဖန်တီးခြင်းနှင့် အတူတူပင်ဖြစ်ပါသည်။ သင့်တွင် သင့်တင့်လျောက်ပတ်သော CNI သို့မဟုတ် Kubernetes ပလပ်ဖောင်းများတွင်၊ cloud တွင် လက်ခံဆောင်ရွက်ပေးကြောင်း သေချာစေရန်အတွက် သင့်တွင် မူတည်သည် (ဝန်ဆောင်မှုပေးသူများစာရင်းကို သင်ကြည့်ရှုနိုင်ပါသည်။ ဒီမှာ - ခန့်မှန်းခြေ ဘာသာပြန်။)သင့်အတွက် CNI သတ်မှတ်ပေးမည့် ကွန်ရက်မူဝါဒများကို ဖွင့်ပါ။

သင့်လျော်သောအကူအညီ CNI မပါဘဲ ကွန်ရက်မူဝါဒကို သင်သတ်မှတ်ပါက Kubernetes သည် သင့်ကိုသတိပေးမည်မဟုတ်ကြောင်း သတိပြုပါ။

နိုင်ငံမဲ့လား ဒါမှမဟုတ် နိုင်ငံမဲ့လား။

ကျွန်ုပ်ကြုံတွေ့ခဲ့ရသည့် Kubernetes CNI များအားလုံးသည် တည်ငြိမ်သည် (ဥပမာ၊ Calico သည် Linux conntrack ကို အသုံးပြုသည်)။ ၎င်းသည် ပေါ့ဒ်အား ပြန်လည်တည်ဆောက်ရန်မလိုဘဲ စတင်လုပ်ဆောင်ခဲ့သည့် TCP ချိတ်ဆက်မှုတွင် တုံ့ပြန်မှုများကို လက်ခံရရှိစေပါသည်။ သို့သော်၊ တည်ငြိမ်မှုကိုအာမခံမည့် Kubernetes စံနှုန်းကို ကျွန်ုပ်မသိပါ။

အဆင့်မြင့် လုံခြုံရေးမူဝါဒ စီမံခန့်ခွဲမှု

Kubernetes တွင် လုံခြုံရေးမူဝါဒ ကျင့်သုံးမှုကို မြှင့်တင်ရန် ဤနည်းလမ်းအချို့ ရှိပါသည်။

1. Service Mesh ဗိသုကာပုံစံသည် ဝန်ဆောင်မှုအဆင့်တွင် အသေးစိတ် telemetry နှင့် traffic control ကိုပေးဆောင်ရန် sidecar containers ကိုအသုံးပြုသည်။ သာဓကအနေနဲ့ ယူလို့ရတယ်။ Istio.
2. CNI ရောင်းချသူအချို့သည် Kubernetes ကွန်ရက်မူဝါဒများကိုကျော်လွန်၍ ၎င်းတို့၏ကိရိယာများကို တိုးချဲ့ထားသည်။
3. Tufin Orca Kubernetes ကွန်ရက်မူဝါဒများကို မြင်နိုင်စွမ်းနှင့် အလိုအလျောက်လုပ်ဆောင်ပေးသည်။

Tufin Orca ပက်ကေ့ဂျ်သည် Kubernetes ကွန်ရက်မူဝါဒများကို စီမံခန့်ခွဲသည် (အထက်ပါ ဖန်သားပြင်ဓာတ်ပုံများ၏ အရင်းအမြစ်ဖြစ်သည်)။

နောက်ထပ်သတင်းအချက်အလက်များကို

• GKE မှ Ahmet Alp Balkan မှ ပြင်ဆင်သော ကွန်ရက်မူဝါဒများ နမူနာများ;
• တရားဝင် Kubernetes ဝဘ်ဆိုက်မှ စာရွက်စာတမ်း;
• Kubernetes ကွန်ရက်ချိတ်ဆက်မှုပုံစံအတွက် လမ်းညွှန်ချက်;
• ကွန်ရက်မူဝါဒများကို စစ်ဆေးခြင်းအတွက် Script.

ကောက်ချက်

Kubernetes ကွန်ရက်မူဝါဒများသည် အစုအစည်းများကို ခွဲခြမ်းခြင်းအတွက် ကောင်းမွန်သောကိရိယာအစုံကို ပေးစွမ်းသော်လည်း ၎င်းတို့သည် အလိုလိုသိမြင်ခြင်းမရှိသည့်အပြင် ပရိယာယ်များစွာပါရှိသည်။ ဤရှုပ်ထွေးမှုကြောင့် လက်ရှိအစုအဖွဲ့မူဝါဒများစွာသည် အမှားအယွင်းဖြစ်နေသည်ဟု ကျွန်တော်ယုံကြည်ပါသည်။ ဤပြဿနာအတွက် ဖြစ်နိုင်ချေရှိသော ဖြေရှင်းနည်းများတွင် အလိုအလျောက် မူဝါဒ အဓိပ္ပါယ်ဖွင့်ဆိုချက်များ သို့မဟုတ် အခြားသော ခွဲထွက်ရေးကိရိယာများကို အသုံးပြုခြင်းတို့ ပါဝင်သည်။

ဤလမ်းညွှန်ချက်သည် မေးခွန်းအချို့ကို ရှင်းလင်းစေပြီး သင်ကြုံတွေ့ရနိုင်သည့် ပြဿနာများကို ဖြေရှင်းရန် ကူညီပေးမည်ဟု မျှော်လင့်ပါသည်။

PS ဘာသာပြန်မှ

ကျွန်ုပ်တို့၏ဘလော့ဂ်တွင်လည်းဖတ်ပါ

• "Istio ဖြင့် အသေးစားဝန်ဆောင်မှုများသို့ ပြန်သွားရန်"- အပိုင်း 1 (အဓိကအင်္ဂါရပ်များမိတ်ဆက်), အပိုင်း 2 (လမ်းကြောင်း၊ ယာဉ်ထိန်း), အပိုင်း ၃ (လုံခြုံရေး);
• " Kubernetes တွင် ကွန်ရက်ချိတ်ဆက်ခြင်းဆိုင်ရာ ရုပ်ပြလမ်းညွှန်"- အပိုင်း ၁ နှင့် ၂ (ကွန်ရက်ပုံစံ၊ ထပ်ဆင့်ကွန်ရက်များ), အပိုင်း 3 (ဝန်ဆောင်မှုများနှင့် ယာဉ်အသွားအလာ လုပ်ဆောင်ခြင်း);
• «လုံခြုံရေးအကဲဆတ်သော ပတ်ဝန်းကျင်များတွင် Docker နှင့် Kubernetes";
• «Kubernetes လုံခြုံရေးအတွက် အကောင်းဆုံး အလေ့အကျင့် ၉ ခု";
• «Kubernetes ဟက်ကာ၏ သားကောင်ဖြစ်ရန် (မပြုရန်) နည်းလမ်း 11 ခု"။

source: www.habr.com