ការណែនាំអំពីគោលការណ៍បណ្តាញ Kubernetes សម្រាប់អ្នកជំនាញផ្នែកសុវត្ថិភាព

ចំណាំ។ បកប្រែ៖ អ្នកនិពន្ធអត្ថបទ - Reuven Harrison - មានបទពិសោធន៍ជាង 20 ឆ្នាំក្នុងការអភិវឌ្ឍន៍កម្មវិធី ហើយសព្វថ្ងៃនេះគឺជា CTO និងជាសហស្ថាបនិកនៃ Tufin ដែលជាក្រុមហ៊ុនដំណោះស្រាយគ្រប់គ្រងគោលនយោបាយសន្តិសុខ។ ខណៈពេលដែលគាត់ចាត់ទុកគោលការណ៍បណ្តាញ Kubernetes ថាមានថាមពលគ្រប់គ្រាន់ដើម្បីបែងចែកបណ្តាញនៅក្នុងចង្កោមមួយ គាត់ក៏ជឿជាក់ថាវាមិនងាយស្រួលទេក្នុងការអនុវត្តជាក់ស្តែង។ សម្ភារៈនេះ (ជាពន្លឺ) មានគោលបំណងធ្វើឱ្យប្រសើរឡើងនូវការយល់ដឹងរបស់អ្នកឯកទេសក្នុងបញ្ហានេះ និងជួយពួកគេក្នុងការបង្កើតការកំណត់រចនាសម្ព័ន្ធចាំបាច់។

សព្វថ្ងៃនេះ ក្រុមហ៊ុនជាច្រើនកំពុងជ្រើសរើស Kubernetes កាន់តែខ្លាំងឡើង ដើម្បីដំណើរការកម្មវិធីរបស់ពួកគេ។ ចំណាប់អារម្មណ៍លើកម្មវិធីនេះគឺខ្ពស់ណាស់ ដែលអ្នកខ្លះហៅ Kubernetes ថា "ប្រព័ន្ធប្រតិបត្តិការថ្មីសម្រាប់មជ្ឈមណ្ឌលទិន្នន័យ"។ បន្តិចម្ដងៗ Kubernetes (ឬ k8s) កំពុងចាប់ផ្តើមត្រូវបានយល់ថាជាផ្នែកសំខាន់នៃអាជីវកម្ម ដែលទាមទារឱ្យមានការរៀបចំដំណើរការអាជីវកម្មដែលមានភាពចាស់ទុំ រួមទាំងសុវត្ថិភាពបណ្តាញផងដែរ។

សម្រាប់អ្នកជំនាញផ្នែកសន្តិសុខដែលមានការងឿងឆ្ងល់ដោយការធ្វើការជាមួយ Kubernetes គោលការណ៍លំនាំដើមនៃវេទិកានេះអាចជាការរកឃើញពិតប្រាកដ៖ អនុញ្ញាតគ្រប់យ៉ាង។

មគ្គុទ្ទេសក៍នេះនឹងជួយអ្នកឱ្យយល់អំពីការងារខាងក្នុងនៃគោលការណ៍បណ្តាញ។ យល់ពីរបៀបដែលពួកវាខុសគ្នាពីច្បាប់សម្រាប់ជញ្ជាំងភ្លើងធម្មតា។ វាក៏នឹងនិយាយអំពីបញ្ហាមួយចំនួន និងផ្តល់ការណែនាំដែលនឹងជួយការពារកម្មវិធីនៅក្នុង Kubernetes ។

គោលការណ៍បណ្តាញ Kubernetes

យន្តការគោលនយោបាយបណ្តាញ Kubernetes អនុញ្ញាតឱ្យអ្នកគ្រប់គ្រងអន្តរកម្មនៃកម្មវិធីដែលបានដាក់ពង្រាយនៅលើវេទិកានៅស្រទាប់បណ្តាញ (ទីបីនៅក្នុងគំរូ OSI) ។ គោលការណ៍បណ្តាញខ្វះលក្ខណៈពិសេសកម្រិតខ្ពស់មួយចំនួននៃជញ្ជាំងភ្លើងទំនើប ដូចជាការគ្រប់គ្រង OSI ស្រទាប់ 7 និងការរកឃើញការគំរាមកំហែង ប៉ុន្តែពួកគេផ្តល់នូវស្រទាប់មូលដ្ឋាននៃសុវត្ថិភាពបណ្តាញដែលជាចំណុចចាប់ផ្តើមដ៏ល្អ។

គោលការណ៍បណ្តាញគ្រប់គ្រងទំនាក់ទំនងរវាងផត

បន្ទុកការងារនៅក្នុង Kubernetes ត្រូវបានចែកចាយពាសពេញផត ដែលរួមមានធុងមួយ ឬច្រើនដែលដាក់ពង្រាយជាមួយគ្នា។ Kubernetes កំណត់ផតនីមួយៗនូវអាសយដ្ឋាន IP ដែលអាចចូលប្រើបានពីផតផតផ្សេងទៀត។ គោលការណ៍បណ្តាញ Kubernetes កំណត់ការអនុញ្ញាតចូលប្រើសម្រាប់ក្រុមនៃផត តាមរបៀបដូចគ្នាដែលក្រុមសុវត្ថិភាពនៅក្នុងពពកត្រូវបានប្រើ ដើម្បីគ្រប់គ្រងការចូលប្រើម៉ាស៊ីននិម្មិត។

ការកំណត់គោលការណ៍បណ្តាញ

ដូចជាធនធាន Kubernetes ផ្សេងទៀត គោលការណ៍បណ្តាញត្រូវបានកំណត់នៅក្នុង YAML ។ នៅក្នុងឧទាហរណ៍ខាងក្រោមកម្មវិធី balance បើកការចូលប្រើ postgres:

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

(ចំណាំ។ បកប្រែ៖ រូបថតអេក្រង់នេះ ដូចជារូបថតអេក្រង់ស្រដៀងគ្នាជាបន្តបន្ទាប់ទាំងអស់ មិនត្រូវបានបង្កើតដោយប្រើឧបករណ៍ Kubernetes ដើមឡើយ ប៉ុន្តែប្រើឧបករណ៍ Tufin Orca ដែលត្រូវបានបង្កើតឡើងដោយក្រុមហ៊ុនរបស់អ្នកនិពន្ធអត្ថបទដើម ហើយដែលត្រូវបានលើកឡើងនៅចុងបញ្ចប់នៃសម្ភារៈ។)

ចំណេះដឹងជាមូលដ្ឋាននៃ YAML គឺត្រូវបានទាមទារដើម្បីកំណត់គោលការណ៍បណ្តាញផ្ទាល់ខ្លួនរបស់អ្នក។ ភាសានេះគឺផ្អែកលើការចូលបន្ទាត់ (បញ្ជាក់ដោយដកឃ្លា មិនមែនផ្ទាំង)។ ធាតុចូលបន្ទាត់ជាកម្មសិទ្ធិរបស់ធាតុចូលបន្ទាត់ដែលនៅជិតបំផុតនៅខាងលើវា។ ធាតុថ្មីនៃបញ្ជីចាប់ផ្តើមដោយសហសញ្ញា ធាតុផ្សេងទៀតទាំងអស់មានទម្រង់ តម្លៃគន្លឹះ.

បន្ទាប់ពីពិពណ៌នាអំពីគោលការណ៍នៅក្នុង YAML សូមប្រើ kubectlដើម្បីបង្កើតវានៅក្នុងចង្កោម៖

kubectl create -f policy.yaml

ការកំណត់គោលការណ៍បណ្តាញ

ការកំណត់គោលការណ៍បណ្តាញ Kubernetes រួមមានធាតុបួន៖

1. podSelector៖ កំណត់ pods ដែលរងផលប៉ះពាល់ដោយគោលការណ៍នេះ (គោលដៅ) - ទាមទារ;
2. policyTypes៖ បង្ហាញពីប្រភេទនៃគោលការណ៍ដែលត្រូវបានរួមបញ្ចូលនៅក្នុងមួយនេះ៖ ingress និង/ឬ egress - ស្រេចចិត្ត ប៉ុន្តែខ្ញុំសូមណែនាំឱ្យបញ្ជាក់វាយ៉ាងច្បាស់នៅក្នុងគ្រប់ករណីទាំងអស់។
3. ingress៖ កំណត់អនុញ្ញាត ចូល ចរាចរណ៍ទៅកាន់គោលដៅ pods - ស្រេចចិត្ត;
4. egress៖ កំណត់អនុញ្ញាត ចេញ ចរាចរណ៍ពី pods គោលដៅគឺស្រេចចិត្ត។

ឧទាហរណ៍មួយដែលបានខ្ចីពីគេហទំព័រ 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គោលនយោបាយនេះនឹងត្រូវបានបកស្រាយដូចខាងក្រោម៖

• វាត្រូវបានសន្មត់តាមលំនាំដើមដើម្បីកំណត់ផ្នែកខាងក្នុង។ ប្រសិនបើគោលការណ៍នេះមិនបានបញ្ជាក់ច្បាស់លាស់ទេ ប្រព័ន្ធនឹងសន្មត់ថាចរាចរណ៍ទាំងអស់ត្រូវបានហាមឃាត់។
• ឥរិយាបទនៅលើចំហៀង egress នឹងត្រូវបានកំណត់ដោយវត្តមានឬអវត្តមាននៃប៉ារ៉ាម៉ែត្រ egress ដែលត្រូវគ្នា។

ដើម្បីជៀសវាងកំហុសខ្ញុំសូមណែនាំ តែងតែច្បាស់លាស់ policyTypes.

យោងតាមតក្កវិជ្ជាខាងលើក្នុងករណីប៉ារ៉ាម៉ែត្រ ingress និង / ឬ។ egress បានលុបចោល គោលការណ៍នេះនឹងបដិសេធរាល់ចរាចរណ៍ទាំងអស់ (សូមមើល "Sweep Rule" ខាងក្រោម)។

គោលការណ៍លំនាំដើម - អនុញ្ញាត

ប្រសិនបើគ្មានគោលការណ៍កំណត់ទេ Kubernetes អនុញ្ញាតចរាចរណ៍ទាំងអស់តាមលំនាំដើម។ pods ទាំងអស់អាចផ្លាស់ប្តូរព័ត៌មានគ្នាទៅវិញទៅមកដោយសេរី។ តាមទស្សនៈសុវត្ថិភាព នេះអាចហាក់ដូចជាផ្ទុយស្រឡះ ប៉ុន្តែត្រូវចាំថា Kubernetes ដើមឡើយត្រូវបានបង្កើតឡើងដោយអ្នកអភិវឌ្ឍន៍ដែលមានគោលដៅធ្វើឱ្យកម្មវិធីអាចដំណើរការអន្តរកម្មបាន។ គោលការណ៍បណ្តាញត្រូវបានបន្ថែមនៅពេលក្រោយ។

ចន្លោះឈ្មោះ

Namespaces គឺជាយន្តការសហការ 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 នៅក្នុងគោលការណ៍នឹងជ្រើសរើស pods ពី namespace ដែលគោលការណ៍នេះជាកម្មសិទ្ធិ (វាមិនមានសិទ្ធិចូលប្រើ pods ពី namespace ផ្សេងទៀតទេ)។

ដូចគ្នានេះដែរ podSelectors នៅក្នុងប្លុក ingress និង egress អាចជ្រើសរើស pods ពី namespace ផ្ទាល់របស់ពួកគេតែប៉ុណ្ណោះ លុះត្រាតែអ្នកបញ្ចូលពួកវាជាមួយ 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 ដូចជាផត និងចន្លោះឈ្មោះ។ ស្លាក (ស្លាក tags) គឺស្មើនឹងស្លាកនៅក្នុងពពក។ គោលការណ៍បណ្តាញ Kubernetes ប្រើស្លាកដើម្បីជ្រើសរើស ផតដែលពួកគេអនុវត្ត៖

podSelector:
  matchLabels:
    role: db

… ឬ ចន្លោះឈ្មោះដែលពួកគេអនុវត្ត។ ឧទាហរណ៍នេះជ្រើសរើស pods ទាំងអស់នៅក្នុង namespaces ដែលមានស្លាកដែលត្រូវគ្នា៖

namespaceSelector:
  matchLabels:
    project: myproject

ការព្រមានមួយ: នៅពេលប្រើ namespaceSelector សូមប្រាកដថា ចន្លោះឈ្មោះដែលអ្នកជ្រើសរើសមានស្លាកត្រឹមត្រូវ។. ត្រូវ​ដឹង​ថា​មាន​ចន្លោះ​ឈ្មោះ​ដែល​បាន​បង្កើត​ឡើង​ដូច​ជា​ default и kube-systemមិន​មាន​ស្លាក​តាម​លំនាំដើម។

អ្នកអាចបន្ថែមស្លាកទៅចន្លោះដូចនេះ៖

kubectl label namespace default namespace=default

ក្នុងករណីនេះ ចន្លោះឈ្មោះក្នុងផ្នែក metadata គួរ​យោង​ទៅ​លើ​ឈ្មោះ​ពិត​នៃ​លំហ​មិន​មែន​ស្លាក​:

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

ប្រភព និងទិសដៅ

គោលការណ៍ជញ្ជាំងភ្លើងមានច្បាប់ប្រភព និងទិសដៅ។ គោលការណ៍បណ្តាញ Kubernetes ត្រូវបានកំណត់ក្នុងមួយគោលដៅ សំណុំនៃផតឃែរដែលពួកគេអនុវត្ត ហើយបន្ទាប់មកកំណត់ច្បាប់សម្រាប់ការចូល និង/ឬចរាចរចូល។ ក្នុងឧទាហរណ៍របស់យើង គោលដៅគោលនយោបាយនឹងជាផតឃែរទាំងអស់នៅក្នុង namespace 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; គោលដៅ → 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 ទាំងអស់នៅក្នុង namespaces ទាំងអស់។, អនុញ្ញាត 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 តែនៅក្នុង namespace ប៉ុណ្ណោះ។ 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. មនុស្ស Paranoid អាចទៅបន្ថែមទៀត និងដាក់កម្រិតលើសំណើ DNS ទៅកាន់សេវា DNS ជាក់លាក់មួយនៅក្នុង kube-system. ផ្នែក "Filter by Namespaces AND Pods" នឹងបង្ហាញអ្នកពីរបៀបដើម្បីសម្រេចបាន។

ជម្រើសមួយទៀតគឺត្រូវដោះស្រាយ DNS នៅកម្រិត namespace ។ ក្នុងករណីនេះ វានឹងមិនចាំបាច់បើកសម្រាប់រាល់សេវាកម្មទេ៖

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 ជ្រើសរើស pods ទាំងអស់នៅក្នុង namespace ។

ការប្រកួតដំបូងនិងលំដាប់

នៅក្នុងជញ្ជាំងភ្លើងធម្មតា សកម្មភាព (អនុញ្ញាត ឬបដិសេធ) នៅលើកញ្ចប់ព័ត៌មានត្រូវបានកំណត់ដោយច្បាប់ទីមួយដែលវាពេញចិត្ត។ នៅក្នុង Kubernetes លំដាប់នៃគោលការណ៍មិនសំខាន់ទេ។

តាមលំនាំដើម នៅពេលដែលគ្មានគោលការណ៍កំណត់ ការទំនាក់ទំនងរវាងផតស៍ត្រូវបានអនុញ្ញាត ហើយពួកគេអាចផ្លាស់ប្តូរព័ត៌មានដោយសេរី។ ដរាបណាអ្នកចាប់ផ្តើមបង្កើតគោលការណ៍ ផតនីមួយៗដែលរងផលប៉ះពាល់ដោយយ៉ាងហោចណាស់មួយក្នុងចំណោមពួកវានឹងក្លាយទៅជាដាច់ដោយឡែកយោងទៅតាមការផ្តាច់ (ឡូជីខល OR) នៃគោលនយោបាយទាំងអស់ដែលបានជ្រើសរើសវា។ Pods មិនរងផលប៉ះពាល់ដោយគោលការណ៍ណាមួយនៅតែបើកចំហ។

អ្នកអាចផ្លាស់ប្តូរឥរិយាបទនេះដោយប្រើច្បាប់បោសសំអាត។

ច្បាប់សម្អាត ("ហាម")

គោលការណ៍ Firewall ជាធម្មតាបដិសេធចរាចរណ៍ដែលមិនត្រូវបានអនុញ្ញាតយ៉ាងច្បាស់។

Kubernetes មិនមានសកម្មភាព "បដិសេធ" ទេ។ប៉ុន្តែឥទ្ធិពលដូចគ្នាអាចត្រូវបានសម្រេចជាមួយនឹងគោលការណ៍ធម្មតា (អនុញ្ញាត) ដោយជ្រើសរើសក្រុមទទេនៃប្រភពផត (ចូល)៖

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

គោលការណ៍នេះជ្រើសរើស pods ទាំងអស់នៅក្នុង namespace ហើយទុក ingress មិនបានកំណត់ ដោយបដិសេធរាល់ចរាចរចូល។

ដូចគ្នានេះដែរ អ្នកអាចដាក់កម្រិតចរាចរណ៍ចេញទាំងអស់ពី namespace៖

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

សូមចំណាំថា គោលការណ៍បន្ថែមណាមួយដែលអនុញ្ញាតឱ្យចរាចរទៅកាន់ pods នៅក្នុងតំបន់ namespace នឹងមានអាទិភាពលើច្បាប់នេះ។ (ស្រដៀងនឹងការបន្ថែមច្បាប់អនុញ្ញាត មុនពេលច្បាប់បដិសេធក្នុងការកំណត់រចនាសម្ព័ន្ធជញ្ជាំងភ្លើង)។

អនុញ្ញាតទាំងអស់ (Any-Any-Any-Allow)

ដើម្បីបង្កើតគោលការណ៍ "អនុញ្ញាតទាំងអស់" អ្នកត្រូវបន្ថែមគោលការណ៍បដិសេធខាងលើជាមួយនឹងធាតុទទេ ingress:

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

វាផ្តល់នូវការចូលទៅកាន់ pods ទាំងអស់នៅក្នុង namespaces ទាំងអស់ (និង IPs ទាំងអស់) ទៅកាន់ pod ណាមួយនៅក្នុង namespace default. ឥរិយាបថនេះត្រូវបានបើកតាមលំនាំដើម ដូច្នេះជាធម្មតាវាមិនចាំបាច់កំណត់បន្ថែមទៀតទេ។ ទោះយ៉ាងណាក៏ដោយ ពេលខ្លះ វាអាចចាំបាច់ក្នុងការបិទការអនុញ្ញាតជាក់លាក់មួយចំនួនជាបណ្តោះអាសន្ន ដើម្បីធ្វើរោគវិនិច្ឆ័យបញ្ហា។

ច្បាប់នេះអាចត្រូវបានបង្រួបបង្រួមដើម្បីអនុញ្ញាតឱ្យចូលប្រើតែប៉ុណ្ណោះ សំណុំជាក់លាក់នៃ pods (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

គោលការណ៍ខាងក្រោមអនុញ្ញាតឱ្យចរាចរចូល (ចូល) និង ចេញ (egress) ទាំងអស់ រួមទាំងការចូលប្រើ IP ណាមួយនៅខាងក្រៅចង្កោម៖

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

ការរួមបញ្ចូលគ្នានៃគោលការណ៍ជាច្រើន។

គោលនយោបាយត្រូវបាន ORed ឡូជីខលនៅបីកម្រិត; ការអនុញ្ញាតរបស់ផតនីមួយៗត្រូវបានកំណត់យោងទៅតាមការផ្តាច់ចេញពីគោលការណ៍ទាំងអស់ដែលប៉ះពាល់ដល់វា៖

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 ផងដែរ។

ប៉ុន្តែនៅពេលដែលពួកគេត្រូវបានបញ្ចូលគ្នា, មានការរឹតបន្តឹងមួយនៅលើ ចង្អុលបង្ហាញ លោក Chris Cooney៖ Kubernetes អាចរួមបញ្ចូលគ្នាបានតែគោលការណ៍ផ្សេងៗគ្នាប៉ុណ្ណោះ។ policyTypes (Ingress ឬ Egress) គោលការណ៍ដែលកំណត់ការចូល (ឬ egress) នឹងសរសេរជាន់លើគ្នាទៅវិញទៅមក។

ទំនាក់ទំនងរវាងចន្លោះឈ្មោះ

តាមលំនាំដើម ការផ្លាស់ប្តូរព័ត៌មានរវាង namespaces ត្រូវបានអនុញ្ញាត។ អ្នកអាចផ្លាស់ប្តូរវាដោយប្រើគោលការណ៍រឹតត្បិតដែលដាក់កម្រិតការចេញចូល និង/ឬចរាចរចូលទៅកាន់លំហឈ្មោះ (សូមមើល "ច្បាប់បោសសម្អាត" ខាងលើ)។

ដោយការទប់ស្កាត់ការចូលទៅកាន់ namespace (សូមមើល "Sweep 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

ជាលទ្ធផល pods ទាំងអស់នៅក្នុង namespace default ទទួលបានសិទ្ធិចូលប្រើ pods postgres នៅក្នុង namespace database. ប៉ុន្តែចុះយ៉ាងណាបើអ្នកចង់បើកការចូលប្រើ postgres មានតែ pods ជាក់លាក់នៅក្នុង namespace 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

ហេតុអ្វីបានជាវាត្រូវបានបកប្រែជា AND ជំនួសឱ្យ OR ធម្មតា?

ចំណាំ​ថា 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

ស្លាកជាច្រើនផ្សំជាមួយ AND

ច្បាប់ជញ្ជាំងភ្លើងដែលមានអង្គភាពច្រើន (ម៉ាស៊ីន បណ្តាញ ក្រុម) ត្រូវបានរួមបញ្ចូលគ្នាដោយប្រើឡូជីខល OR ។ ច្បាប់ខាងក្រោមនឹងឈប់ដំណើរការ ប្រសិនបើប្រភពកញ្ចប់ព័ត៌មានត្រូវគ្នា។ Host_1 ឬ Host_2:

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

ផ្ទុយទៅវិញនៅក្នុង Kubernetes ស្លាកផ្សេងគ្នានៅក្នុង podSelector ឬ namespaceSelector ត្រូវ​បាន​ផ្សំ​ជាមួយ​នឹង​ឡូជីខល AND។ ឧទាហរណ៍ ច្បាប់​ខាងក្រោម​នឹង​ជ្រើសរើស​ផត​ដែល​មាន​ស្លាក​ទាំងពីរ role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

តក្កវិជ្ជាដូចគ្នាអនុវត្តចំពោះគ្រប់ប្រភេទនៃសេចក្តីថ្លែងការណ៍៖ ឧបករណ៍ជ្រើសរើសគោលដៅគោលនយោបាយ ឧបករណ៍ជ្រើសរើសផត និងឧបករណ៍ជ្រើសរើសលំហឈ្មោះ។

បណ្តាញរង និងអាសយដ្ឋាន IP (IPBlocks)

Firewalls ប្រើ VLANs អាសយដ្ឋាន IP និងបណ្តាញរងដើម្បីបែងចែកបណ្តាញ។

នៅក្នុង Kubernetes អាសយដ្ឋាន IP ត្រូវបានកំណត់ដោយស្វ័យប្រវត្តិទៅ pods ហើយអាចផ្លាស់ប្តូរជាញឹកញាប់ ដូច្នេះស្លាកត្រូវបានប្រើដើម្បីជ្រើសរើស pods និង namespaces នៅក្នុងគោលការណ៍បណ្តាញ។

បណ្តាញរង (ipBlocks) ត្រូវ​បាន​ប្រើ​នៅ​ពេល​គ្រប់គ្រង​ការ​តភ្ជាប់​ចូល (ចូល) ឬ​ចេញ (egress) ខាង​ក្រៅ (ខាងជើង-ខាងត្បូង) ។ ឧទាហរណ៍ គោលការណ៍នេះបើក pods ទាំងអស់ពី namespace default ការចូលប្រើសេវាកម្ម DNS របស់ Google៖

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

ឧបករណ៍ជ្រើសរើស pods ទទេនៅក្នុងឧទាហរណ៍នេះមានន័យថា "ជ្រើសរើស pods ទាំងអស់នៅក្នុង namespace" ។

គោលការណ៍នេះអនុញ្ញាតឱ្យចូលប្រើតែ 8.8.8.8; ការចូលប្រើ IP ផ្សេងទៀតត្រូវបានហាមឃាត់។ ដូច្នេះ ជារួម អ្នកបានរារាំងការចូលប្រើសេវាកម្ម DNS Kubernetes ខាងក្នុង។ ប្រសិនបើអ្នកនៅតែចង់បើកវា បញ្ជាក់វាឱ្យច្បាស់លាស់។

ជាធម្មតា ipBlocks и podSelectors គឺផ្តាច់មុខទៅវិញទៅមក ចាប់តាំងពីអាសយដ្ឋាន IP ខាងក្នុងរបស់ផតថលមិនត្រូវបានប្រើនៅក្នុង ipBlocks. ការចង្អុលបង្ហាញ ផត IP ខាងក្នុងអ្នកនឹងអនុញ្ញាតឱ្យមានការតភ្ជាប់ទៅ/ពីផតផតជាមួយនឹងអាសយដ្ឋានទាំងនោះ។ នៅក្នុងការអនុវត្ត អ្នកនឹងមិនដឹងថាអាសយដ្ឋាន IP មួយណាដែលត្រូវប្រើ ដែលជាមូលហេតុដែលអ្នកមិនគួរប្រើពួកវាដើម្បីជ្រើសរើសផត។

ជាឧទាហរណ៍ផ្ទុយគ្នា គោលការណ៍ខាងក្រោមរួមបញ្ចូល IPs ទាំងអស់ ដូច្នេះហើយអនុញ្ញាតឱ្យចូលប្រើ 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

អ្នកអាចបើកការចូលប្រើបានតែ IPs ខាងក្រៅប៉ុណ្ណោះ ដោយមិនរាប់បញ្ចូលអាសយដ្ឋាន IP ខាងក្នុងរបស់ផត។ ឧទាហរណ៍ ប្រសិនបើបណ្តាញរងរបស់ផតរបស់អ្នកគឺ 10.16.0.0/14៖

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

ច្រកនិងពិធីការ

ជាធម្មតា pods ស្តាប់នៅលើច្រកមួយ។ នេះមានន័យថា អ្នកគ្រាន់តែអាចទុកលេខច្រកនៅក្នុងគោលការណ៍របស់អ្នក ហើយទុកអ្វីៗទាំងអស់តាមលំនាំដើម។ ទោះយ៉ាងណាក៏ដោយ វាត្រូវបានផ្ដល់អនុសាសន៍ឱ្យធ្វើគោលការណ៍រឹតត្បិតតាមដែលអាចធ្វើទៅបាន ដូច្នេះក្នុងករណីខ្លះ អ្នកនៅតែអាចបញ្ជាក់ច្រកបាន៖

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

ចំណាំថាអ្នកជ្រើសរើស ports អនុវត្តចំពោះធាតុទាំងអស់នៅក្នុងប្លុក to ឬ from, ដែលមាន។ ដើម្បីបញ្ជាក់ច្រកផ្សេងគ្នាសម្រាប់សំណុំធាតុផ្សេងគ្នា សូមបំបែក ingress ឬ egress ទៅក្នុងផ្នែករងជាច្រើន។ to ឬ from ហើយក្នុងនីមួយៗសរសេរច្រករបស់អ្នក៖

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

ច្រកលំនាំដើមដំណើរការ៖

• ប្រសិនបើអ្នកបដិសេធនិយមន័យនៃច្រកទាំងស្រុង (ports) ដែលមានន័យថាពិធីការទាំងអស់ និងច្រកទាំងអស់;
• ប្រសិនបើអ្នកបដិសេធនិយមន័យពិធីការ (protocol) ដែលមានន័យថា TCP;
• ប្រសិនបើអ្នកបដិសេធនិយមន័យច្រក (port) ដែលមានន័យថាច្រកទាំងអស់។

ការអនុវត្តល្អបំផុត៖ កុំពឹងផ្អែកលើតម្លៃលំនាំដើម បញ្ជាក់អ្វីដែលអ្នកត្រូវការយ៉ាងច្បាស់លាស់។

ចំណាំថាអ្នកត្រូវប្រើផតផត មិនមែនសេវាកម្មទេ (បន្ថែមលើវានៅកថាខណ្ឌបន្ទាប់)។

គោលការណ៍កំណត់សម្រាប់ផត ឬសេវាកម្ម?

ជាធម្មតា ផតនៅក្នុង Kubernetes ប្រាស្រ័យទាក់ទងគ្នាតាមរយៈសេវាកម្មមួយ ដែលជាឧបករណ៍ផ្ទុកបន្ទុកនិម្មិត ដែលប្តូរទិសចរាចរណ៍ទៅកាន់ផតដែលអនុវត្តសេវាកម្ម។ អ្នកប្រហែលជាគិតថាគោលការណ៍បណ្តាញគ្រប់គ្រងការចូលប្រើសេវាកម្ម ប៉ុន្តែនោះមិនមែនជាករណីនោះទេ។ គោលការណ៍បណ្តាញ Kubernetes ដំណើរការជាមួយផតផត មិនមែនសេវាកម្មទេ។

ឧទាហរណ៍ ប្រសិនបើសេវាកម្មស្តាប់នៅលើច្រក 80 ប៉ុន្តែបញ្ជូនចរាចរទៅកាន់ច្រក 8080 នៃផតរបស់វា អ្នកត្រូវតែបញ្ជាក់ 8080 នៅក្នុងគោលការណ៍បណ្តាញ។

យន្តការបែបនេះគួរតែត្រូវបានគេទទួលស្គាល់ថាល្អបំផុត៖ ប្រសិនបើឧបករណ៍ខាងក្នុងនៃសេវាកម្ម (ច្រកដែលស្តាប់ pods) ផ្លាស់ប្តូរ គោលការណ៍បណ្តាញនឹងត្រូវធ្វើបច្ចុប្បន្នភាព។

វិធីសាស្រ្តស្ថាបត្យកម្មថ្មីដោយប្រើ Service Mesh (ឧទាហរណ៍ សូមមើលអំពី Istio ខាងក្រោម - approx. transl ។ ) អនុញ្ញាតឱ្យអ្នកដោះស្រាយបញ្ហានេះ។

តើចាំបាច់ត្រូវសរសេរទាំង Ingress និង Egress ទេ?

ចំលើយខ្លីគឺបាទ/ចាស ដើម្បីឱ្យផត A ទំនាក់ទំនងជាមួយផត B អ្នកត្រូវអនុញ្ញាតឱ្យវាបង្កើតការតភ្ជាប់ចេញ (សម្រាប់នេះអ្នកត្រូវកំណត់រចនាសម្ព័ន្ធគោលការណ៍ egress) ហើយផត B ត្រូវតែអាចទទួលយកការតភ្ជាប់ចូល (សម្រាប់នេះ, យោងទៅតាម, អ្នកត្រូវការ ingress- policy) ។

ទោះយ៉ាងណាក៏ដោយ នៅក្នុងការអនុវត្ត អ្នកអាចពឹងផ្អែកលើគោលការណ៍លំនាំដើម ដើម្បីអនុញ្ញាតឱ្យមានការតភ្ជាប់ក្នុងទិសដៅមួយ ឬទាំងពីរ។

ប្រសិនបើមានផតខ្លះ -ប្រភព នឹងត្រូវបានជ្រើសរើសដោយមួយ ឬច្រើន។ ចេញ- អ្នកនយោបាយ ការរឹតបន្តឹងដែលដាក់លើវានឹងត្រូវបានកំណត់ដោយការផ្តាច់ខ្លួនរបស់ពួកគេ។ ក្នុងករណីនេះអ្នកនឹងត្រូវអនុញ្ញាតឱ្យមានការភ្ជាប់ជាមួយ pod យ៉ាងច្បាស់អ្នកទទួល. ប្រសិនបើ pod មិនត្រូវបានជ្រើសរើសដោយគោលការណ៍ណាមួយទេ ចរាចរណ៍ចេញ (egress) របស់វាត្រូវបានអនុញ្ញាតតាមលំនាំដើម។

ដូចគ្នានេះដែរ ជោគវាសនារបស់ pod'a-អ្នកទទួលជ្រើសរើសដោយមួយ ឬច្រើន។ ចូល- គោលនយោបាយនឹងត្រូវបានកំណត់ដោយការផ្តាច់ខ្លួន។ ក្នុងករណីនេះ អ្នកត្រូវតែអនុញ្ញាតឱ្យវាទទួលបានចរាចរណ៍ពីប្រភពផត។ ប្រសិនបើផតមិនត្រូវបានជ្រើសរើសដោយគោលការណ៍ណាមួយទេ ចរាចរណ៍ចូលទាំងអស់ទៅកាន់វាត្រូវបានអនុញ្ញាតតាមលំនាំដើម។

សូមមើល "Stateful or Stateless" ខាងក្រោម។

កំណត់ហេតុ

គោលការណ៍បណ្តាញ Kubernetes មិនដឹងពីរបៀបកត់ត្រាចរាចរណ៍ទេ។ នេះធ្វើឱ្យមានការលំបាកក្នុងការកំណត់ថាតើគោលការណ៍មួយកំពុងដំណើរការដូចការរំពឹងទុក និងធ្វើឱ្យការវិភាគសុវត្ថិភាពមានការលំបាកខ្លាំងណាស់។

ការគ្រប់គ្រងចរាចរណ៍ទៅកាន់សេវាខាងក្រៅ

គោលការណ៍បណ្តាញ Kubernetes មិនអនុញ្ញាតឱ្យអ្នកបញ្ជាក់ឈ្មោះដែនដែលមានលក្ខណៈសម្បត្តិគ្រប់គ្រាន់ពេញលេញ (DNS) នៅក្នុងផ្នែក egress ទេ។ ការពិតនេះនាំឱ្យមានការរអាក់រអួលខ្លាំងនៅពេលព្យាយាមដាក់កម្រិតចរាចរណ៍ទៅកាន់គោលដៅខាងក្រៅដែលមិនមានអាសយដ្ឋាន IP ថេរ (ដូចជា aws.com)។

ការត្រួតពិនិត្យគោលនយោបាយ

ជញ្ជាំងភ្លើងនឹងព្រមានអ្នក ឬសូម្បីតែបដិសេធមិនទទួលយកគោលការណ៍ខុស។ Kubernetes ក៏ធ្វើការផ្ទៀងផ្ទាត់ខ្លះដែរ។ នៅពេលកំណត់គោលការណ៍បណ្តាញតាមរយៈ kubectl Kubernetes អាចប្រកាសថាគោលការណ៍នេះមិនត្រឹមត្រូវ ហើយបដិសេធមិនទទួលយកវា។ ក្នុងករណីផ្សេងទៀត Kubernetes នឹងយកគោលការណ៍នេះ ហើយបំពេញវាជាមួយនឹងព័ត៌មានលម្អិតដែលបាត់។ អ្នកអាចឃើញពួកវាដោយប្រើពាក្យបញ្ជា៖

kubernetes get networkpolicy <policy-name> -o yaml

សូមចងចាំថាប្រព័ន្ធសុពលភាព Kubernetes មិនអាចខ្វះបាន ហើយអាចខកខានប្រភេទនៃកំហុសមួយចំនួន។

ការប្រតិបត្តិ

Kubernetes មិនអនុវត្តគោលការណ៍បណ្តាញដោយខ្លួនឯងទេ ប៉ុន្តែគ្រាន់តែជាច្រក API ដែលដាក់បន្ទុកនៃការគ្រប់គ្រងលើប្រព័ន្ធដែលហៅថា Container Networking Interface (CNI) ប៉ុណ្ណោះ។ ការកំណត់គោលការណ៍នៅលើចង្កោម Kubernetes ដោយមិនកំណត់ CNI សមស្របគឺស្រដៀងនឹងការកំណត់គោលការណ៍នៅលើម៉ាស៊ីនមេគ្រប់គ្រងជញ្ជាំងភ្លើងដោយមិនកំណត់ពួកវាជាបន្តបន្ទាប់នៅលើជញ្ជាំងភ្លើង។ វាអាស្រ័យលើអ្នកក្នុងការធ្វើឱ្យប្រាកដថាអ្នកមាន CNI សមរម្យ ឬនៅក្នុងករណីនៃវេទិកា Kubernetes ដែលបង្ហោះនៅក្នុងពពក (សម្រាប់បញ្ជីអ្នកផ្តល់សេវាសូមមើល នៅទីនេះ - ប្រហែល ឆ្លង)បើកគោលការណ៍បណ្តាញដែលនឹងកំណត់ CNI សម្រាប់អ្នក។

សូមចំណាំថា Kubernetes នឹងមិនព្រមានអ្នកទេ ប្រសិនបើអ្នកកំណត់គោលការណ៍បណ្តាញដោយគ្មានអ្នកជំនួយសមរម្យ CNI ។

រដ្ឋឬគ្មានរដ្ឋ?

Kubernetes CNIs ទាំងអស់ដែលខ្ញុំបានឆ្លងកាត់គឺមានលក្ខណៈរដ្ឋ (ឧទាហរណ៍ Calico ប្រើ Linux conntrack)។ នេះអនុញ្ញាតឱ្យ pod ទទួលបានការឆ្លើយតបនៅលើការតភ្ជាប់ TCP ដែលវាបានចាប់ផ្តើមដោយមិនចាំបាច់បង្កើតវាឡើងវិញ។ ទោះយ៉ាងណាក៏ដោយ ខ្ញុំមិនដឹងពីស្តង់ដារ Kubernetes ដែលនឹងធានាភាពពេញលេញនោះទេ។

ការគ្រប់គ្រងគោលនយោបាយសុវត្ថិភាពកម្រិតខ្ពស់

នេះគឺជាវិធីមួយចំនួនដើម្បីបង្កើនប្រសិទ្ធភាពនៃការអនុវត្តគោលនយោបាយសុវត្ថិភាពនៅក្នុង Kubernetes៖

1. គំរូស្ថាបត្យកម្ម Service Mesh ប្រើ sidecars ដើម្បីផ្តល់ telemetry លម្អិត និងការត្រួតពិនិត្យចរាចរណ៍នៅកម្រិតសេវាកម្ម។ ជាឧទាហរណ៍គេអាចយកបាន។ អ៊ីស៊ីអូ.
2. អ្នកលក់ CNI មួយចំនួនបានពង្រីកឧបករណ៍របស់ពួកគេដើម្បីលើសពីគោលការណ៍បណ្តាញ Kubernetes ។
3. ធូហ្វីន អ័រកា ផ្តល់នូវតម្លាភាព និងស្វ័យប្រវត្តិកម្មនៃគោលការណ៍បណ្តាញ Kubernetes ។

កញ្ចប់ Tufin Orca គ្រប់គ្រងគោលការណ៍បណ្តាញ Kubernetes (ហើយជាប្រភពនៃរូបថតអេក្រង់ខាងលើ)។

បន្ថែម

• ឧទាហរណ៍គោលនយោបាយបណ្តាញរៀបចំដោយ Ahmet Alp Balkan នៃ GKE;
• ឯកសារពីគេហទំព័រ Kubernetes ផ្លូវការ;
• ការណែនាំអំពីគំរូបណ្តាញ Kubernetes;
• ស្គ្រីបសម្រាប់ពិនិត្យមើលគោលការណ៍បណ្តាញ.

សេចក្តីសន្និដ្ឋាន

គោលការណ៍បណ្តាញ Kubernetes ផ្តល់នូវសំណុំឧបករណ៍ដ៏ល្អសម្រាប់ការបែងចែកចង្កោម ប៉ុន្តែពួកវាមិនមានវិចារណញាណ និងមានព័ត៌មានលំអិតជាច្រើន។ ខ្ញុំជឿថា ដោយសារតែភាពស្មុគស្មាញនេះ គោលនយោបាយនៃចង្កោមដែលមានស្រាប់ជាច្រើនមានកំហុស។ ដំណោះស្រាយដែលអាចកើតមានចំពោះបញ្ហានេះ គឺការកំណត់គោលការណ៍ដោយស្វ័យប្រវត្តិ ឬប្រើឧបករណ៍បែងចែកផ្សេងទៀត។

ខ្ញុំសង្ឃឹមថាការណែនាំនេះនឹងជួយជម្រះសំណួរមួយចំនួន និងដោះស្រាយបញ្ហាដែលអ្នកអាចជួបប្រទះ។

PS ពីអ្នកបកប្រែ

សូមអានផងដែរនៅលើប្លក់របស់យើង៖

• "ត្រលប់ទៅសេវាកម្មខ្នាតតូចជាមួយ Istio"៖ ផ្នែកទី 1 (ការណែនាំអំពីលក្ខណៈសំខាន់ៗ), ផ្នែកទី 2 (ផ្លូវ, ការត្រួតពិនិត្យចរាចរណ៍), ផ្នែកទី 3 (សុវត្ថិភាព);
• "មគ្គុទ្ទេសក៍គំនូរលើបណ្តាញនៅក្នុង Kubernetes"៖ ផ្នែកទី 1 និងទី 2 (គំរូបណ្តាញ បណ្តាញត្រួតលើគ្នា), ផ្នែកទី 3 (សេវាកម្ម និងដំណើរការចរាចរណ៍);
• «Docker និង Kubernetes នៅក្នុងបរិស្ថានដែលទាមទារសុវត្ថិភាព»
• «ការអនុវត្តល្អបំផុត 9 Kubernetes Security»
• «11 វិធីដើម្បី (មិន) ទទួលបានការ Hack នៅក្នុង Kubernetes"។

ប្រភព: www.habr.com