ການແນະນໍາກ່ຽວກັບນະໂຍບາຍເຄືອຂ່າຍ Kubernetes ສໍາລັບຜູ້ຊ່ຽວຊານດ້ານຄວາມປອດໄພ

ຫມາຍ​ເຫດ​. ແປ.: ຜູ້ຂຽນຂອງບົດຄວາມ Reuven Harrison ມີປະສົບການຫຼາຍກວ່າ 20 ປີໃນການພັດທະນາຊອບແວ, ແລະໃນມື້ນີ້ແມ່ນ CTO ແລະຜູ້ຮ່ວມກໍ່ຕັ້ງຂອງ Tufin, ບໍລິສັດທີ່ສ້າງວິທີແກ້ໄຂການຄຸ້ມຄອງນະໂຍບາຍຄວາມປອດໄພ. ໃນຂະນະທີ່ລາວເບິ່ງນະໂຍບາຍເຄືອຂ່າຍ Kubernetes ເປັນເຄື່ອງມືທີ່ມີປະສິດທິພາບພໍສົມຄວນສໍາລັບການແບ່ງສ່ວນເຄືອຂ່າຍໃນກຸ່ມ, ລາວຍັງເຊື່ອວ່າພວກເຂົາບໍ່ງ່າຍທີ່ຈະປະຕິບັດໃນການປະຕິບັດ. ອຸປະກອນການນີ້ (ຂ້ອນຂ້າງມີແສງສະຫວ່າງ) ມີຈຸດປະສົງເພື່ອປັບປຸງຄວາມຮັບຮູ້ຂອງຜູ້ຊ່ຽວຊານກ່ຽວກັບບັນຫານີ້ແລະຊ່ວຍໃຫ້ພວກເຂົາສ້າງການຕັ້ງຄ່າທີ່ຈໍາເປັນ.

ໃນມື້ນີ້, ບໍລິສັດຈໍານວນຫຼາຍກໍາລັງເລືອກ Kubernetes ເພື່ອດໍາເນີນການຄໍາຮ້ອງສະຫມັກຂອງເຂົາເຈົ້າ. ຄວາມສົນໃຈໃນຊອບແວນີ້ແມ່ນສູງຫຼາຍທີ່ບາງຄົນເອີ້ນວ່າ Kubernetes "ລະບົບປະຕິບັດການໃຫມ່ສໍາລັບສູນຂໍ້ມູນ." ຄ່ອຍໆ, Kubernetes (ຫຼື k8s) ກໍາລັງເລີ່ມຖືກຮັບຮູ້ວ່າເປັນສ່ວນຫນຶ່ງທີ່ສໍາຄັນຂອງທຸລະກິດ, ເຊິ່ງຮຽກຮ້ອງໃຫ້ອົງການຈັດຕັ້ງຂອງຂະບວນການທຸລະກິດທີ່ໃຫຍ່ເຕັມທີ່, ລວມທັງຄວາມປອດໄພຂອງເຄືອຂ່າຍ.

ສໍາລັບຜູ້ຊ່ຽວຊານດ້ານຄວາມປອດໄພທີ່ສັບສົນໂດຍການເຮັດວຽກກັບ Kubernetes, ການເປີດເຜີຍທີ່ແທ້ຈິງອາດຈະເປັນນະໂຍບາຍເລີ່ມຕົ້ນຂອງເວທີ: ອະນຸຍາດໃຫ້ທຸກສິ່ງທຸກຢ່າງ.

ຄູ່ມືນີ້ຈະຊ່ວຍໃຫ້ທ່ານເຂົ້າໃຈໂຄງສ້າງພາຍໃນຂອງນະໂຍບາຍເຄືອຂ່າຍ; ເຂົ້າໃຈວ່າພວກມັນແຕກຕ່າງຈາກກົດລະບຽບສໍາລັບ firewalls ປົກກະຕິແນວໃດ. ມັນຍັງຈະກວມເອົາບາງຂຸມແລະໃຫ້ຄໍາແນະນໍາເພື່ອຊ່ວຍໃຫ້ຄໍາຮ້ອງສະຫມັກທີ່ປອດໄພໃນ Kubernetes.

ນະໂຍບາຍເຄືອຂ່າຍ Kubernetes

ກົນໄກນະໂຍບາຍເຄືອຂ່າຍ Kubernetes ອະນຸຍາດໃຫ້ທ່ານຈັດການການໂຕ້ຕອບຂອງແອັບພລິເຄຊັນທີ່ໃຊ້ໃນແພລດຟອມທີ່ຊັ້ນເຄືອຂ່າຍ (ອັນທີສາມໃນແບບຈໍາລອງ OSI). ນະໂຍບາຍເຄືອຂ່າຍຂາດຄຸນສົມບັດຂັ້ນສູງຂອງ Firewalls ທີ່ທັນສະໄຫມເຊັ່ນ: OSI Layer 7 ການບັງຄັບໃຊ້ແລະການກວດພົບໄພຂົ່ມຂູ່, ແຕ່ພວກເຂົາສະຫນອງລະດັບພື້ນຖານຂອງຄວາມປອດໄພຂອງເຄືອຂ່າຍທີ່ເປັນຈຸດເລີ່ມຕົ້ນທີ່ດີ.

ນະໂຍບາຍເຄືອຂ່າຍຄວບຄຸມການສື່ສານລະຫວ່າງຝັກ

ປະລິມານວຽກໃນ Kubernetes ແມ່ນແຈກຢາຍໄປທົ່ວພອດ, ເຊິ່ງປະກອບດ້ວຍໜຶ່ງ ຫຼືຫຼາຍຖັງທີ່ນຳໃຊ້ຮ່ວມກັນ. Kubernetes ກຳນົດແຕ່ລະຝັກເປັນທີ່ຢູ່ IP ທີ່ສາມາດເຂົ້າເຖິງໄດ້ຈາກພອດອື່ນ. ນະ​ໂຍ​ບາຍ​ເຄືອ​ຂ່າຍ Kubernetes ຕັ້ງ​ສິດ​ການ​ເຂົ້າ​ເຖິງ​ສໍາ​ລັບ​ກຸ່ມ​ຂອງ pods ໃນ​ວິ​ທີ​ການ​ດຽວ​ກັນ​ທີ່​ກຸ່ມ​ຄວາມ​ປອດ​ໄພ​ໃນ​ຄ​ລາວ​ໄດ້​ຖືກ​ນໍາ​ໃຊ້​ເພື່ອ​ຄວບ​ຄຸມ​ການ​ເຂົ້າ​ເຖິງ​ຕົວ​ຢ່າງ virtual machines.

ການກໍານົດນະໂຍບາຍເຄືອຂ່າຍ

ເຊັ່ນດຽວກັນກັບຊັບພະຍາກອນ 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. ພາສານີ້ແມ່ນອີງໃສ່ການຫຍໍ້ໜ້າ (ລະບຸໂດຍຍະຫວ່າງຫຼາຍກວ່າແຖບ). ອົງປະກອບຫຍໍ້ໜ້າເປັນຂອງອົງປະກອບຫຍໍ້ໜ້າທີ່ໃກ້ທີ່ສຸດຢູ່ເທິງມັນ. ອົງປະກອບລາຍຊື່ໃໝ່ເລີ່ມຕົ້ນດ້ວຍຂີດໝາຍ, ອົງປະກອບອື່ນໆທັງໝົດມີແບບຟອມ key-value.

ໂດຍໄດ້ອະທິບາຍນະໂຍບາຍໃນ YAML, ໃຫ້ໃຊ້ kubectlເພື່ອສ້າງມັນຢູ່ໃນກຸ່ມ:

kubectl create -f policy.yaml

ການລະບຸນະໂຍບາຍເຄືອຂ່າຍ

ຂໍ້ສະເພາະຂອງນະໂຍບາຍເຄືອຂ່າຍ Kubernetes ປະກອບມີສີ່ອົງປະກອບ:

1. podSelector: ກໍານົດຝັກທີ່ໄດ້ຮັບຜົນກະທົບຈາກນະໂຍບາຍນີ້ (ເປົ້າຫມາຍ) - ຕ້ອງການ;
2. policyTypes: ຊີ້ບອກປະເພດຂອງນະໂຍບາຍທີ່ລວມຢູ່ໃນນີ້: ingress ແລະ / ຫຼື egress - ທາງເລືອກ, ແຕ່ຂ້າພະເຈົ້າແນະນໍາໃຫ້ລະບຸຢ່າງຊັດເຈນໃນທຸກກໍລະນີ;
3. ingress: ກໍານົດອະນຸຍາດ ເຂົ້າມາ ການຈະລາຈອນໄປຫາເມັດເປົ້າຫມາຍ - ທາງເລືອກ;
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, ນະ​ໂຍ​ບາຍ​ຈະ​ໄດ້​ຮັບ​ການ​ຕີ​ລາ​ຄາ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

• ໂດຍຄ່າເລີ່ມຕົ້ນ, ມັນແມ່ນສົມມຸດວ່າມັນກໍານົດດ້ານ ingress. ຖ້ານະໂຍບາຍບໍ່ໄດ້ບອກເລື່ອງນີ້ຢ່າງຈະແຈ້ງ, ລະບົບຈະຖືວ່າການຈະລາຈອນທັງໝົດຖືກຫ້າມ.
• ພຶດຕິກໍາຢູ່ຂ້າງ egress ຈະຖືກກໍານົດໂດຍການມີຫຼືບໍ່ມີຕົວກໍານົດການ egress ທີ່ສອດຄ້ອງກັນ.

ເພື່ອຫຼີກເວັ້ນການຜິດພາດຂ້າພະເຈົ້າແນະນໍາໃຫ້ ສະເຫມີເຮັດໃຫ້ມັນຊັດເຈນ policyTypes.

ອີງຕາມເຫດຜົນຂ້າງເທິງ, ຖ້າຕົວກໍານົດການ ingress ແລະ / ຫຼື egress ຍົກເວັ້ນ, ນະໂຍບາຍຈະປະຕິເສດການຈະລາຈອນທັງຫມົດ (ເບິ່ງ "ກົດລະບຽບການລອກເອົາ" ຂ້າງລຸ່ມນີ້).

ນະໂຍບາຍເລີ່ມຕົ້ນແມ່ນອະນຸຍາດ

ຖ້າບໍ່ມີການກໍານົດນະໂຍບາຍ, Kubernetes ອະນຸຍາດໃຫ້ການຈະລາຈອນທັງຫມົດໂດຍຄ່າເລີ່ມຕົ້ນ. ຝັກທັງໝົດສາມາດແລກປ່ຽນຂໍ້ມູນລະຫວ່າງກັນໄດ້ຢ່າງເສລີ. ອັນນີ້ອາດຈະເບິ່ງຄືກົງກັນຂ້າມກັບທັດສະນະຄວາມປອດໄພ, ແຕ່ຈື່ໄວ້ວ່າ Kubernetes ໄດ້ຖືກອອກແບບໃນເບື້ອງຕົ້ນໂດຍຜູ້ພັດທະນາເພື່ອໃຫ້ສາມາດເຮັດວຽກຮ່ວມກັນຂອງແອັບພລິເຄຊັນໄດ້. ນະໂຍບາຍເຄືອຂ່າຍໄດ້ຖືກເພີ່ມຕໍ່ມາ.

Namespaces

Namespaces ແມ່ນກົນໄກການຮ່ວມມື Kubernetes. ພວກມັນຖືກອອກແບບເພື່ອແຍກສະພາບແວດລ້ອມທີ່ມີເຫດຜົນຈາກກັນແລະກັນ, ໃນຂະນະທີ່ການສື່ສານລະຫວ່າງສະຖານທີ່ຖືກອະນຸຍາດໂດຍຄ່າເລີ່ມຕົ້ນ.

ເຊັ່ນດຽວກັນກັບອົງປະກອບ Kubernetes ສ່ວນໃຫຍ່, ນະໂຍບາຍເຄືອຂ່າຍອາໄສຢູ່ໃນ namespace ສະເພາະ. ໃນຕັນ metadata ທ່ານສາມາດລະບຸພື້ນທີ່ທີ່ນະໂຍບາຍເປັນຂອງ:

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

ຖ້າ namespace ບໍ່ໄດ້ລະບຸຢ່າງຊັດເຈນໃນ metadata, ລະບົບຈະໃຊ້ namespace ທີ່ລະບຸໄວ້ໃນ kubectl (ໂດຍຄ່າເລີ່ມຕົ້ນ. namespace=default):

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

ຂ້ອຍຂໍແນະ ນຳ ລະບຸ namespace ຢ່າງຈະແຈ້ງ, ເວັ້ນເສຍແຕ່ວ່າທ່ານກໍາລັງຂຽນນະໂຍບາຍທີ່ເປົ້າຫມາຍຫຼາຍ namespaces ໃນເວລາດຽວກັນ.

ຫລັກ ອົງປະກອບ podSelector ໃນນະໂຍບາຍຈະເລືອກ pods ຈາກ namespace ທີ່ນະໂຍບາຍຂຶ້ນກັບ (ມັນຖືກປະຕິເສດການເຂົ້າເຖິງ pods ຈາກ namespace ອື່ນ).

ເຊັ່ນດຽວກັນ, podSelectors ໃນ ingress ແລະ egress ຕັນ ພຽງແຕ່ສາມາດເລືອກຝັກຈາກ namespace ຂອງເຂົາເຈົ້າເອງ, ເວັ້ນເສຍແຕ່ແນ່ນອນທ່ານສົມທົບໃຫ້ເຂົາເຈົ້າກັບ namespaceSelector (ນີ້ຈະຖືກສົນທະນາໃນພາກ "ການກັ່ນຕອງໂດຍ namespaces ແລະ pods").

ກົດລະບຽບການຕັ້ງຊື່ນະໂຍບາຍ

ຊື່ນະໂຍບາຍແມ່ນເປັນເອກະລັກພາຍໃນ 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

ປ້າຍກຳກັບ

ທ່ານສາມາດຕິດປ້າຍກຳກັບທີ່ກຳນົດເອງໃສ່ວັດຖຸ Kubernetes, ເຊັ່ນ: ຝັກ ແລະ namespaces. ປ້າຍກຳກັບ (ປ້າຍກໍາກັບ - tags) ແມ່ນທຽບເທົ່າກັບ tags ໃນເມຄ. ນະໂຍບາຍເຄືອຂ່າຍ Kubernetes ໃຊ້ປ້າຍກຳກັບເພື່ອເລືອກ ຝັກທີ່ເຂົາເຈົ້າສະຫມັກ:

podSelector:
  matchLabels:
    role: db

… ຫຼື namespacesທີ່ເຂົາເຈົ້າສະຫມັກ. ຕົວຢ່າງນີ້ເລືອກ pods ທັງຫມົດໃນ namespaces ທີ່ມີປ້າຍຊື່ທີ່ສອດຄ້ອງກັນ:

namespaceSelector:
  matchLabels:
    project: myproject

ຂໍ້ຄວນລະວັງຫນຶ່ງ: ເມື່ອໃຊ້ namespaceSelector ໃຫ້ແນ່ໃຈວ່າ namespaces ທີ່ທ່ານເລືອກມີປ້າຍຊື່ທີ່ຖືກຕ້ອງ. ຈົ່ງຮັບຮູ້ວ່າສ້າງໃນ 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 ທີ່​ເຂົາ​ເຈົ້າ​ນໍາ​ໃຊ້ - ແລະ​ຫຼັງ​ຈາກ​ນັ້ນ​ກໍາ​ນົດ​ກົດ​ລະ​ບຽບ​ສໍາ​ລັບ​ການ​ຈະ​ລາ​ຈອນ ingress ແລະ / ຫຼື egress. ໃນຕົວຢ່າງຂອງພວກເຮົາ, ເປົ້າຫມາຍຂອງນະໂຍບາຍຈະເປັນ pods ທັງຫມົດໃນ 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 ໃນນະໂຍບາຍນີ້, ເປີດການຈະລາຈອນຂາເຂົ້າໄປຫາ pods ເປົ້າຫມາຍ. ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ingress ແມ່ນແຫຼ່ງແລະເປົ້າຫມາຍແມ່ນຈຸດຫມາຍປາຍທາງທີ່ສອດຄ້ອງກັນ. ເຊັ່ນດຽວກັນ, egress ແມ່ນຈຸດຫມາຍປາຍທາງແລະເປົ້າຫມາຍແມ່ນແຫຼ່ງຂອງມັນ.

ນີ້ແມ່ນເທົ່າກັບສອງກົດລະບຽບຂອງ Firewall: Ingress → Target; ເປົ້າໝາຍ → ກ້າວອອກ.

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 ແມ່ນຫວ່າງເປົ່າ, ແລະດັ່ງນັ້ນມັນໂດຍທາງອ້ອມເລືອກ ຝັກທັງໝົດໃນ 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.

ເພື່ອເຮັດສິ່ງນີ້, ທ່ານຈໍາເປັນຕ້ອງເພີ່ມປ້າຍຊື່ໃສ່ 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. ຄົນ Paranoid ສາມາດໄປຕື່ມອີກແລະຈໍາກັດການສອບຖາມ DNS ກັບການບໍລິການ DNS ສະເພາະໃນ kube-system. ພາກສ່ວນ "ການກັ່ນຕອງໂດຍ namespaces ແລະ 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 ເລືອກຝັກທັງໝົດໃນ namespace.

ການແຂ່ງຂັນຄັ້ງທໍາອິດແລະຄໍາສັ່ງກົດລະບຽບ

ໃນ Firewalls ແບບດັ້ງເດີມ, ການປະຕິບັດ (ອະນຸຍາດຫຼືປະຕິເສດ) ໃນແພັກເກັດຖືກກໍານົດໂດຍກົດລະບຽບທໍາອິດທີ່ມັນພໍໃຈ. ໃນ Kubernetes, ຄໍາສັ່ງຂອງນະໂຍບາຍບໍ່ສໍາຄັນ.

ໂດຍຄ່າເລີ່ມຕົ້ນ, ເມື່ອບໍ່ມີການຕັ້ງນະໂຍບາຍ, ການສື່ສານລະຫວ່າງຝັກແມ່ນອະນຸຍາດ ແລະເຂົາເຈົ້າສາມາດແລກປ່ຽນຂໍ້ມູນໄດ້ຢ່າງເສລີ. ເມື່ອທ່ານເລີ່ມສ້າງນະໂຍບາຍ, ແຕ່ລະຝັກທີ່ໄດ້ຮັບຜົນກະທົບຈາກຢ່າງຫນ້ອຍຫນຶ່ງຂອງມັນຈະກາຍເປັນທີ່ໂດດດ່ຽວຕາມຄວາມແຕກແຍກ (ຫຼືເຫດຜົນ) ຂອງນະໂຍບາຍທັງຫມົດທີ່ເລືອກມັນ. Pods ບໍ່ໄດ້ຮັບຜົນກະທົບຈາກນະໂຍບາຍໃດໆຍັງຄົງເປີດຢູ່.

ທ່ານສາມາດປ່ຽນພຶດຕິກໍານີ້ໂດຍໃຊ້ກົດລະບຽບການລອກເອົາ.

ກົດລະບຽບການຖອດອອກ ("ປະຕິເສດ")

ປົກກະຕິແລ້ວນະໂຍບາຍ Firewall ປະຕິເສດການຈະລາຈອນໃດໆທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດຢ່າງຊັດເຈນ.

ບໍ່ມີການປະຕິບັດການປະຕິເສດໃນ Kubernetesແນວໃດກໍ່ຕາມ, ຜົນກະທົບທີ່ຄ້າຍຄືກັນສາມາດບັນລຸໄດ້ດ້ວຍນະໂຍບາຍປົກກະຕິ (ອະນຸຍາດ) ໂດຍການເລືອກກຸ່ມເປົ່າຂອງຝັກແຫຼ່ງ (ingress):

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 ທັງຫມົດ (ແລະ IP ທັງຫມົດ) ກັບ pod ໃດໃນ namespace default. ພຶດຕິກໍານີ້ຖືກເປີດໃຊ້ໂດຍຄ່າເລີ່ມຕົ້ນ, ດັ່ງນັ້ນມັນມັກຈະບໍ່ຈໍາເປັນຕ້ອງຖືກກໍານົດຕື່ມອີກ. ຢ່າງໃດກໍ່ຕາມ, ບາງຄັ້ງທ່ານອາດຈະຕ້ອງປິດການອະນຸຍາດສະເພາະບາງອັນຊົ່ວຄາວເພື່ອວິນິດໄສບັນຫາ.

ກົດລະບຽບສາມາດແຄບລົງເພື່ອອະນຸຍາດໃຫ້ເຂົ້າເຖິງພຽງແຕ່ ຊຸດສະເພາະຂອງຝັກ (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

ການລວມເອົາຫຼາຍນະໂຍບາຍ

ນະໂຍບາຍແມ່ນລວມກັນໂດຍໃຊ້ເຫດຜົນ OR ໃນສາມລະດັບ; ການອະນຸຍາດຂອງແຕ່ລະຝັກແມ່ນຖືກກຳນົດໃຫ້ສອດຄ່ອງກັບການແຍກນະໂຍບາຍທັງໝົດທີ່ມີຜົນກະທົບກັບມັນ:

1. ໃນທົ່ງນາ from и to ສາມປະເພດຂອງອົງປະກອບສາມາດຖືກກໍານົດ (ທັງຫມົດທີ່ປະສົມປະສານໂດຍໃຊ້ OR):

• namespaceSelector — ເລືອກ namespace ທັງ ຫມົດ;
• podSelector - ເລືອກຝັກ;
• ipBlock — ເລືອກ subnet ເປັນ.

ຍິ່ງໄປກວ່ານັ້ນ, ຈໍານວນຂອງອົງປະກອບ (ແມ້ແຕ່ອັນດຽວກັນ) ໃນສ່ວນຍ່ອຍ 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). ນະໂຍບາຍທີ່ກໍານົດ ingress (ຫຼື egress) ຈະຂຽນທັບເຊິ່ງກັນແລະກັນ.

ຄວາມສໍາພັນລະຫວ່າງ namespaces

ໂດຍຄ່າເລີ່ມຕົ້ນ, ການແບ່ງປັນຂໍ້ມູນລະຫວ່າງ namespaces ແມ່ນອະນຸຍາດ. ນີ້ສາມາດປ່ຽນແປງໄດ້ໂດຍໃຊ້ນະໂຍບາຍການປະຕິເສດທີ່ຈະຈໍາກັດການຈະລາຈອນຂາອອກແລະ / ຫຼືຂາເຂົ້າເຂົ້າໄປໃນ namespace (ເບິ່ງ "ກົດລະບຽບການລອກເອົາ" ຂ້າງເທິງ).

ເມື່ອທ່ານໄດ້ຂັດຂວາງການເຂົ້າເຖິງ namespace (ເບິ່ງ "ກົດລະບຽບການລອກເອົາ" ຂ້າງເທິງ), ທ່ານສາມາດຍົກເວັ້ນນະໂຍບາຍການປະຕິເສດໂດຍການອະນຸຍາດໃຫ້ເຊື່ອມຕໍ່ຈາກ 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 default ຈະມີການເຂົ້າເຖິງຝັກ postgres ໃນ namespace database. ແຕ່ຖ້າຫາກວ່າທ່ານຕ້ອງການທີ່ຈະເປີດການເຂົ້າເຖິງ postgres ສະເພາະຝັກໃນ namespace 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

ເປັນຫຍັງອັນນີ້ຈຶ່ງຖືກຕີຄວາມໝາຍເປັນ AND ແທນ OR ປົກກະຕິ?

ໃຫ້ສັງເກດວ່າ podSelector ບໍ່ໄດ້ເລີ່ມຕົ້ນດ້ວຍຂີດໝາຍ. ໃນ YAML ນີ້ຫມາຍຄວາມວ່າ podSelector ແລະຢືນຢູ່ຕໍ່ໜ້າພຣະອົງ namespaceSelector ອ້າງເຖິງອົງປະກອບລາຍຊື່ດຽວກັນ. ດັ່ງນັ້ນ, ພວກມັນຖືກລວມເຂົ້າກັບເຫດຜົນ AND.

ເພີ່ມຂີດໝາຍກ່ອນ podSelector ຈະສົ່ງຜົນໃຫ້ເກີດອົງປະກອບລາຍຊື່ໃໝ່, ເຊິ່ງຈະຖືກລວມເຂົ້າກັບອັນກ່ອນໜ້າ namespaceSelector ການນໍາໃຊ້ເຫດຜົນ OR.

ເພື່ອເລືອກຝັກທີ່ມີປ້າຍສະເພາະ ໃນ namespaces ທັງຫມົດ, ໃສ່ຊ່ອງຫວ່າງ 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 ທີ່​ມີ​ວັດ​ຖຸ​ຫຼາຍ (ແມ່​ຂ່າຍ​, ເຄືອ​ຂ່າຍ​, ກຸ່ມ​) ຖືກ​ລວມ​ເຂົ້າ​ກັນ​ໂດຍ​ການ​ນໍາ​ໃຊ້​ຢ່າງ​ມີ​ເຫດ​ຜົນ 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.

ເຄືອຂ່າຍຍ່ອຍ ແລະທີ່ຢູ່ 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

ຕົວເລືອກຝັກເປົ່າໃນຕົວຢ່າງນີ້ຫມາຍຄວາມວ່າ "ເລືອກຝັກທັງຫມົດໃນ namespace."

ນະໂຍບາຍນີ້ອະນຸຍາດໃຫ້ເຂົ້າເຖິງ 8.8.8.8 ເທົ່ານັ້ນ; ການເຂົ້າເຖິງ IP ອື່ນໆແມ່ນຖືກຫ້າມ. ດັ່ງນັ້ນ, ໂດຍເນື້ອແທ້ແລ້ວ, ທ່ານໄດ້ສະກັດການເຂົ້າເຖິງການບໍລິການ DNS Kubernetes ພາຍໃນ. ຖ້າທ່ານຍັງຕ້ອງການເປີດມັນ, ໃຫ້ຊີ້ບອກອັນນີ້ຢ່າງຈະແຈ້ງ.

ປົກກະຕິແລ້ວ ipBlocks и podSelectors ແມ່ນສະເພາະເຊິ່ງກັນແລະກັນ, ເພາະວ່າທີ່ຢູ່ IP ພາຍໃນຂອງຝັກບໍ່ໄດ້ຖືກນໍາໃຊ້ໃນ ipBlocks. ໂດຍການຊີ້ບອກ ຝັກ IP ພາຍໃນ, ທ່ານຈະອະນຸຍາດໃຫ້ເຊື່ອມຕໍ່ / ຈາກ pods ກັບທີ່ຢູ່ເຫຼົ່ານີ້. ໃນທາງປະຕິບັດ, ທ່ານຈະບໍ່ຮູ້ວ່າຈະໃຊ້ທີ່ຢູ່ 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 ພາຍໃນຂອງ pods. ຕົວຢ່າງ, ຖ້າເຄືອຂ່າຍຍ່ອຍຂອງພອດຂອງທ່ານແມ່ນ 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), ນີ້ຫມາຍຄວາມວ່າພອດທັງຫມົດ.

ການປະຕິບັດທີ່ດີທີ່ສຸດ: ຢ່າອີງໃສ່ຄ່າເລີ່ມຕົ້ນ, ລະບຸສິ່ງທີ່ທ່ານຕ້ອງການຢ່າງຈະແຈ້ງ.

ກະລຸນາຮັບຊາບວ່າທ່ານຈະຕ້ອງໃຊ້ພອດພອດ, ບໍ່ແມ່ນພອດບໍລິການ (ເພີ່ມເຕີມກ່ຽວກັບເລື່ອງນີ້ໃນວັກຕໍ່ໄປ).

ນະໂຍບາຍຖືກກໍານົດສໍາລັບ pods ຫຼືການບໍລິການ?

ໂດຍປົກກະຕິ, pods ໃນ Kubernetes ເຂົ້າເຖິງກັນແລະກັນໂດຍຜ່ານການບໍລິການ - virtual load balancer ທີ່ປ່ຽນເສັ້ນທາງການຈະລາຈອນໄປຫາ pods ທີ່ປະຕິບັດການບໍລິການ. ທ່ານອາດຈະຄິດວ່ານະໂຍບາຍເຄືອຂ່າຍຄວບຄຸມການເຂົ້າເຖິງການບໍລິການ, ແຕ່ນີ້ບໍ່ແມ່ນກໍລະນີ. ນະໂຍບາຍເຄືອຂ່າຍ Kubernetes ເຮັດວຽກຢູ່ໃນພອດພອດ, ບໍ່ແມ່ນພອດບໍລິການ.

ຕົວຢ່າງ, ຖ້າບໍລິການຟັງພອດ 80, ແຕ່ປ່ຽນເສັ້ນທາງການຈາລະຈອນໄປຫາພອດ 8080 ຂອງຝັກຂອງມັນ, ທ່ານຕ້ອງລະບຸ 8080 ຢ່າງແທ້ຈິງໃນນະໂຍບາຍເຄືອຂ່າຍ.

ກົນໄກດັ່ງກ່າວຄວນໄດ້ຮັບການພິຈາລະນາທີ່ດີທີ່ສຸດ: ຖ້າໂຄງສ້າງພາຍໃນຂອງການບໍລິການ (ບັນດາທ່າເຮືອທີ່ pods ຟັງ) ມີການປ່ຽນແປງ, ນະໂຍບາຍເຄືອຂ່າຍຈະຕ້ອງປັບປຸງ.

ວິທີການສະຖາປັດຕະຍະກໍາໃຫມ່ໂດຍໃຊ້ Service Mesh (ຕົວຢ່າງ, ເບິ່ງກ່ຽວກັບ Istio ຂ້າງລຸ່ມນີ້ - approx. transl.) ອະນຸຍາດໃຫ້ທ່ານເພື່ອຮັບມືກັບບັນຫານີ້.

ມັນຈໍາເປັນຕ້ອງລົງທະບຽນທັງ Ingress ແລະ Egress ບໍ?

ຄໍາຕອບສັ້ນແມ່ນແມ່ນແລ້ວ, ເພື່ອໃຫ້ pod A ຕິດຕໍ່ສື່ສານກັບ pod B, ມັນຕ້ອງໄດ້ຮັບການອະນຸຍາດໃຫ້ສ້າງການເຊື່ອມຕໍ່ຂາອອກ (ສໍາລັບນີ້, ທ່ານຈໍາເປັນຕ້ອງໄດ້ກໍານົດນະໂຍບາຍ egress), ແລະ pod B ຈະຕ້ອງສາມາດຍອມຮັບການເຊື່ອມຕໍ່ຂາເຂົ້າ ( ສໍາລັບການນີ້, ຕາມຄວາມເຫມາະສົມ, ທ່ານຕ້ອງການນະໂຍບາຍ ingress).

ຢ່າງໃດກໍ່ຕາມ, ໃນທາງປະຕິບັດ, ທ່ານສາມາດອີງໃສ່ນະໂຍບາຍເລີ່ມຕົ້ນເພື່ອອະນຸຍາດໃຫ້ເຊື່ອມຕໍ່ໃນຫນຶ່ງຫຼືທັງສອງທິດທາງ.

ຖ້າບາງຝັກ -ແຫຼ່ງຂໍ້ມູນ ຈະຖືກເລືອກໂດຍຫນຶ່ງຫຼືຫຼາຍກວ່ານັ້ນ ຜູ້ຍິງ- ນັກການເມືອງ, ຂໍ້ຈໍາກັດທີ່ວາງໄວ້ຈະຖືກກໍານົດໂດຍການແບ່ງແຍກຂອງພວກເຂົາ. ໃນ​ກໍ​ລະ​ນີ​ນີ້​, ທ່ານ​ຈະ​ຈໍາ​ເປັນ​ຕ້ອງ​ອະ​ນຸ​ຍາດ​ໃຫ້​ການ​ເຊື່ອມ​ຕໍ່​ກັບ​ຝັກ​ຢ່າງ​ຊັດ​ເຈນ -ກັບຜູ້ຮັບ. ຖ້າ pod ບໍ່ໄດ້ຖືກເລືອກໂດຍນະໂຍບາຍໃດໆ, ການຈະລາຈອນຂາອອກຂອງມັນຖືກອະນຸຍາດຕາມຄ່າເລີ່ມຕົ້ນ.

ເຊັ່ນດຽວກັນ, ຊະຕາກໍາຂອງຝັກແມ່ນທີ່ຢູ່, ເລືອກໂດຍຫນຶ່ງຫຼືຫຼາຍກວ່ານັ້ນ ເຄື່ອງດື່ມ- ນັກການເມືອງ, ຈະຖືກກໍານົດໂດຍ disjunction ຂອງເຂົາເຈົ້າ. ໃນກໍລະນີນີ້, ທ່ານຕ້ອງອະນຸຍາດໃຫ້ມັນໄດ້ຮັບການຈະລາຈອນຈາກຝັກແຫຼ່ງຢ່າງຊັດເຈນ. ຖ້າ pod ບໍ່ໄດ້ຖືກເລືອກໂດຍນະໂຍບາຍໃດໆ, ການຈະລາຈອນຂາເຂົ້າທັງຫມົດສໍາລັບມັນຖືກອະນຸຍາດໂດຍຄ່າເລີ່ມຕົ້ນ.

ເບິ່ງ Stateful ຫຼື Stateless ຂ້າງລຸ່ມນີ້.

ບັນທຶກ

ນະໂຍບາຍເຄືອຂ່າຍ Kubernetes ບໍ່ສາມາດບັນທຶກການຈະລາຈອນໄດ້. ນີ້ເຮັດໃຫ້ມັນຍາກທີ່ຈະກໍານົດວ່ານະໂຍບາຍແມ່ນເຮັດວຽກຕາມຈຸດປະສົງແລະເຮັດໃຫ້ເກີດຄວາມສັບສົນຫຼາຍໃນການວິເຄາະຄວາມປອດໄພ.

ການຄວບຄຸມການຈະລາຈອນກັບການບໍລິການພາຍນອກ

ນະ​ໂຍ​ບາຍ​ເຄືອ​ຂ່າຍ Kubernetes ບໍ່​ອະ​ນຸ​ຍາດ​ໃຫ້​ທ່ານ​ເພື່ອ​ລະ​ບຸ​ຊື່​ໂດ​ເມນ​ທີ່​ມີ​ຄຸນ​ສົມ​ບັດ (DNS) ຢ່າງ​ເຕັມ​ທີ່​ໃນ​ພາກ​ສ່ວນ egress. ຄວາມຈິງນີ້ເຮັດໃຫ້ຄວາມບໍ່ສະດວກທີ່ສໍາຄັນໃນເວລາທີ່ພະຍາຍາມຈໍາກັດການຈະລາຈອນໄປຫາຈຸດຫມາຍປາຍທາງພາຍນອກທີ່ບໍ່ມີທີ່ຢູ່ IP ຄົງທີ່ (ເຊັ່ນ: aws.com).

ການກວດສອບນະໂຍບາຍ

Firewalls ຈະເຕືອນທ່ານຫຼືແມ້ກະທັ້ງປະຕິເສດທີ່ຈະຍອມຮັບນະໂຍບາຍທີ່ບໍ່ຖືກຕ້ອງ. Kubernetes ຍັງເຮັດການຢັ້ງຢືນບາງຢ່າງ. ເມື່ອຕັ້ງນະໂຍບາຍເຄືອຂ່າຍຜ່ານ kubectl, Kubernetes ອາດຈະປະກາດວ່າມັນບໍ່ຖືກຕ້ອງ ແລະປະຕິເສດບໍ່ຍອມຮັບມັນ. ໃນກໍລະນີອື່ນໆ, Kubernetes ຈະເອົານະໂຍບາຍດັ່ງກ່າວແລະຕື່ມຂໍ້ມູນໃສ່ໃນລາຍລະອຽດທີ່ຂາດຫາຍໄປ. ພວກເຂົາສາມາດເຫັນໄດ້ໂດຍໃຊ້ຄໍາສັ່ງ:

kubernetes get networkpolicy <policy-name> -o yaml

ຈົ່ງຈື່ໄວ້ວ່າລະບົບການກວດສອບ Kubernetes ແມ່ນບໍ່ຜິດແລະອາດຈະພາດບາງປະເພດຂອງຄວາມຜິດພາດ.

ການປະຕິບັດ

Kubernetes ບໍ່ໄດ້ປະຕິບັດນະໂຍບາຍເຄືອຂ່າຍຕົວມັນເອງ, ແຕ່ເປັນພຽງປະຕູ API ທີ່ມອບຫມາຍພາລະຂອງການຄວບຄຸມໃຫ້ກັບລະບົບພື້ນຖານທີ່ເອີ້ນວ່າ Container Networking Interface (CNI). ການຕັ້ງຄ່ານະໂຍບາຍກ່ຽວກັບກຸ່ມ Kubernetes ໂດຍບໍ່ມີການກໍານົດ CNI ທີ່ເຫມາະສົມແມ່ນຄືກັນກັບການສ້າງນະໂຍບາຍກ່ຽວກັບເຄື່ອງແມ່ຂ່າຍການຄຸ້ມຄອງໄຟວໍໂດຍບໍ່ມີການຕິດຕັ້ງພວກມັນຢູ່ໃນໄຟວໍ. ມັນຂຶ້ນກັບທ່ານເພື່ອຮັບປະກັນວ່າທ່ານມີ CNI ທີ່ເຫມາະສົມຫຼື, ໃນກໍລະນີຂອງເວທີ Kubernetes, ເປັນເຈົ້າພາບຢູ່ໃນຄລາວ. (ທ່ານສາມາດເບິ່ງລາຍຊື່ຜູ້ໃຫ້ບໍລິການ ທີ່ນີ້ — ປະ​ມານ​. trans.), ເປີດໃຊ້ນະໂຍບາຍເຄືອຂ່າຍທີ່ຈະກໍານົດ CNI ສໍາລັບທ່ານ.

ໃຫ້ສັງເກດວ່າ Kubernetes ຈະບໍ່ເຕືອນທ່ານຖ້າທ່ານຕັ້ງນະໂຍບາຍເຄືອຂ່າຍໂດຍບໍ່ມີຕົວຊ່ວຍທີ່ເຫມາະສົມ CNI.

Stateful ຫຼື Stateless?

Kubernetes CNI ທັງໝົດທີ່ຂ້ອຍໄດ້ພົບແມ່ນສະຖານະ (ຕົວຢ່າງ, Calico ໃຊ້ Linux conntrack). ນີ້ອະນຸຍາດໃຫ້ຝັກໄດ້ຮັບການຕອບສະຫນອງກ່ຽວກັບການເຊື່ອມຕໍ່ TCP ທີ່ມັນລິເລີ່ມໂດຍບໍ່ຈໍາເປັນຕ້ອງສ້າງມັນໃຫມ່. ແນວໃດກໍ່ຕາມ, ຂ້ອຍບໍ່ຮູ້ມາດຕະຖານ Kubernetes ທີ່ຈະຮັບປະກັນຄວາມສົມບູນ.

ການຄຸ້ມຄອງນະໂຍບາຍຄວາມປອດໄພຂັ້ນສູງ

ນີ້ແມ່ນບາງວິທີເພື່ອປັບປຸງການບັງຄັບໃຊ້ນະໂຍບາຍຄວາມປອດໄພໃນ Kubernetes:

1. ຮູບແບບສະຖາປັດຕະຍະກໍາ Service Mesh ໃຊ້ຕູ້ຄອນເທນເນີ sidecar ເພື່ອສະຫນອງລາຍລະອຽດ telemetry ແລະການຄວບຄຸມການຈະລາຈອນໃນລະດັບການບໍລິການ. ເປັນຕົວຢ່າງທີ່ພວກເຮົາສາມາດເອົາ ອິຊິໂອ.
2. ຜູ້ຂາຍ CNI ບາງຄົນໄດ້ຂະຫຍາຍເຄື່ອງມືຂອງພວກເຂົາໄປນອກເຫນືອຈາກນະໂຍບາຍເຄືອຂ່າຍ Kubernetes.
3. Tufin Orca ສະໜອງການເບິ່ງເຫັນ ແລະລະບົບອັດຕະໂນມັດຂອງນະໂຍບາຍເຄືອຂ່າຍ Kubernetes.

ຊຸດ Tufin Orca ຄຸ້ມຄອງນະໂຍບາຍເຄືອຂ່າຍ Kubernetes (ແລະເປັນທີ່ມາຂອງພາບໜ້າຈໍຂ້າງເທິງ).

ຂໍ້ມູນເພີ່ມເຕີມ

• ຕົວຢ່າງຂອງນະໂຍບາຍເຄືອຂ່າຍທີ່ກະກຽມໂດຍ Ahmet Alp Balkan ຈາກ GKE;
• ເອກະສານຈາກເວັບໄຊທ໌ທາງການ Kubernetes;
• ຄູ່ມືກ່ຽວກັບຮູບແບບເຄືອຂ່າຍ Kubernetes;
• Script ສໍາລັບການກວດສອບນະໂຍບາຍເຄືອຂ່າຍ.

ສະຫລຸບ

ນະໂຍບາຍເຄືອຂ່າຍ Kubernetes ສະເໜີຊຸດເຄື່ອງມືທີ່ດີສຳລັບການແບ່ງກຸ່ມກຸ່ມ, ແຕ່ພວກມັນບໍ່ເຂົ້າໃຈງ່າຍ ແລະມີຄວາມອ່ອນໂຍນຫຼາຍ. ເນື່ອງຈາກຄວາມສັບສົນນີ້, ຂ້ອຍເຊື່ອວ່ານະໂຍບາຍຂອງກຸ່ມທີ່ມີຢູ່ຫຼາຍແມ່ນ buggy. ການແກ້ໄຂທີ່ເປັນໄປໄດ້ສໍາລັບບັນຫານີ້ລວມມີການກໍານົດນະໂຍບາຍອັດຕະໂນມັດຫຼືການນໍາໃຊ້ເຄື່ອງມືການແບ່ງສ່ວນອື່ນໆ.

ຂ້ອຍຫວັງວ່າຄູ່ມືນີ້ຈະຊ່ວຍລຶບບາງຄໍາຖາມແລະແກ້ໄຂບັນຫາທີ່ເຈົ້າອາດຈະພົບ.

PS ຈາກນັກແປ

ອ່ານຍັງຢູ່ໃນ blog ຂອງພວກເຮົາ:

• "ກັບຄືນໄປບ່ອນບໍລິການຈຸລະພາກກັບ Istio": ພາກ​ທີ 1 (ການ​ນໍາ​ສະ​ເຫນີ​ກ່ຽວ​ກັບ​ລັກ​ສະ​ນະ​ຕົ້ນ​ຕໍ​), ພາກ​ທີ 2 (ເສັ້ນ​ທາງ​, ການ​ຄວບ​ຄຸມ​ຈະ​ລາ​ຈອນ​), ພາກ​ທີ 3 (ຄວາມ​ປອດ​ໄພ​);
• "ຄູ່ມືຮູບພາບກ່ຽວກັບເຄືອຂ່າຍໃນ Kubernetes": ພາກທີ 1 ແລະ 2 (ຕົວແບບເຄືອຂ່າຍ, ເຄືອຂ່າຍຊ້ອນກັນ), ພາກ​ທີ 3 (ການ​ບໍ​ລິ​ການ​ແລະ​ການ​ປຸງ​ແຕ່ງ​ຈະ​ລາ​ຈອນ​);
• «Docker ແລະ Kubernetes ໃນສະພາບແວດລ້ອມທີ່ຕ້ອງການຄວາມປອດໄພ"
• «9 ການປະຕິບັດທີ່ດີທີ່ສຸດສໍາລັບຄວາມປອດໄພ Kubernetes"
• «11 ວິທີທີ່ຈະ (ບໍ່) ຕົກເປັນເຫຍື່ອຂອງການ Hack Kubernetes".

ແຫຼ່ງຂໍ້ມູນ: www.habr.com