🥇Коопсуздук адистери үчүн Kubernetes тармактык саясаттарына киришүү

Эскертүү. котормо.: Макаланын автору, Реувен Харрисон, программалык камсыздоону иштеп чыгууда 20 жылдан ашык тажрыйбага ээ жана бүгүнкү күндө коопсуздук саясатын башкаруу чечимдерин түзгөн Tufin компаниясынын CTO жана тең негиздөөчүсү. Ал Kubernetes тармактык саясатын кластерде тармак сегментациялоонун кыйла күчтүү куралы катары караганы менен, аларды иш жүзүндө ишке ашыруу анчалык деле оңой эмес деп эсептейт. Бул материал (бир кыйла көлөмдүү) адистердин бул маселе боюнча маалымдуулугун жогорулатуу жана аларга керектүү конфигурацияларды түзүүгө жардам берүү үчүн арналган.

Бүгүнкү күндө көптөгөн компаниялар өздөрүнүн тиркемелерин иштетүү үчүн Kubernetesти көбүрөөк тандап жатышат. Бул программага болгон кызыгуу ушунчалык жогору болгондуктан, айрымдар Kubernetesти "маалымат борборунун жаңы операциялык системасы" деп аташат. Бара-бара Kubernetes (же k8s) тармактык коопсуздукту камтыган жетилген бизнес-процесстерди уюштурууну талап кылган бизнестин маанилүү бөлүгү катары кабыл ала баштады.

Kubernetes менен иштөөдө таң калган коопсуздук адистери үчүн чыныгы ачылыш платформанын демейки саясаты болушу мүмкүн: бардыгына уруксат берүү.

Бул колдонмо тармак саясатынын ички түзүмүн түшүнүүгө жардам берет; алар кадимки брандмауэрлердин эрежелеринен кандайча айырмаланарын түшүнүңүз. Ал ошондой эле кээ бир тузактарды камтыйт жана Kubernetes тиркемелерин коргоого жардам берүү үчүн сунуштарды берет.

Kubernetes тармак саясаттары

Kubernetes тармак саясатынын механизми тармактык катмардагы платформада жайгаштырылган тиркемелердин өз ара аракеттенүүсүн башкарууга мүмкүндүк берет (OSI моделиндеги үчүнчү). Тармак саясаттарында заманбап брандмауэрлердин кээ бир өнүккөн өзгөчөлүктөрү жок, мисалы, OSI Layer 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 тармак саясатынын спецификациясы төрт элементти камтыйт:

podSelector: бул саясаттын таасири тийген поддондорду аныктайт (максаттар) - талап кылынат;
policyTypes: бул саясаттын кандай түрлөрү камтылганын көрсөтөт: кириш жана/же чыгуу - милдеттүү эмес, бирок мен аны бардык учурларда ачык көрсөтүүнү сунуштайм;
ingress: уруксат берет аныктайт Кирүүчү максаттуу подводдорго трафик - милдеттүү эмес;
egress: уруксат берет аныктайт чыгуучу максаттуу поддондордон келген трафик милдеттүү эмес.

Мисал Kubernetes веб-сайтынан алынган (мен алмаштырдым role боюнча app), бардык төрт элементтин кантип колдонулганын көрсөтөт:

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

Эскерте кетсек, төрт элементтин бардыгын камтыш керек эмес. Бул милдеттүү гана podSelector, башка параметрлерди каалагандай колдонсо болот.

калтырсак policyTypes, саясат төмөнкүчө чечмеленет:

Демейки боюнча, ал кирүү тарабын аныктайт деп болжолдонот. Эгер саясатта бул ачык айтылбаса, система бардык трафикке тыюу салынган деп эсептейт.
Чыгуу тарабындагы жүрүм-турум тиешелүү чыгуу параметринин болушу же жоктугу менен аныкталат.

Ката кетирбөө үчүн мен сунуштайм ар дайым ачык-айкын кылып policyTypes.

Жогорудагы логикага ылайык, эгерде параметрлер ingress жана / же egress алынып салынса, саясат бардык трафикти жокко чыгарат (төмөндөгү "Түшүртүү эрежесин" караңыз).

Демейки саясат - уруксат берүү

Эгер эч кандай саясат аныкталбаса, Kubernetes демейки боюнча бардык трафикке уруксат берет. Бардык подколор өз ара эркин маалымат алмаша алышат. Бул коопсуздук көз карашынан алганда карама-каршы сезилиши мүмкүн, бирок Kubernetes алгач колдонмонун өз ара иштешүүсүн камсыз кылуу үчүн иштеп чыгуучулар тарабынан иштелип чыкканын унутпаңыз. Тармак саясаттары кийинчерээк кошулган.

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 саясатта бул саясат таандык болгон аттар мейкиндигинен подъезддерди тандайт (башка аттар мейкиндигинен подъезддерге кирүүгө тыюу салынган).

Ошо сыяктуу эле, podSelectors кирүү жана чыгуу блокторунда Албетте, сиз аларды айкалыштырмайынча, өз аттар мейкиндигинен подкасттарды гана тандай алышат namespaceSelector (бул “Аттар мейкиндиктери жана подколор боюнча чыпкалоо” бөлүмүндө талкууланат).

Саясатты атоо эрежелери

Саясат аттары бирдей аттар мейкиндигинде уникалдуу. Бир эле мейкиндикте бирдей аталыштагы эки саясат болушу мүмкүн эмес, бирок ар башка мейкиндиктерде бирдей аталыштагы саясаттар болушу мүмкүн. Бул бир эле саясатты бир нече мейкиндикте кайра колдонгуңуз келгенде пайдалуу.

Мага өзгөчө ат коюу ыкмаларынын бири жагат. Ал аттар мейкиндигинин атын максаттуу поддондор менен айкалыштыруудан турат. Мисалы:

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

Энбелгилер

Сиз Kubernetes объекттерине ыңгайлаштырылган энбелгилерди тиркөөңүз мүмкүн, мисалы, поддондор жана аттар мейкиндиктери. Энбелгилер (бренд - тэгдер) булуттагы тегдердин эквиваленти. Kubernetes тармак саясаттары тандоо үчүн энбелгилерди колдонот кабыктаралар колдонулат:

podSelector:
  matchLabels:
    role: db

… же аттар мейкиндиктериалар колдонулат. Бул мисал тиешелүү энбелгилери бар аттар мейкиндигиндеги бардык подкектерди тандайт:

namespaceSelector:
  matchLabels:
    project: myproject

Бир эскертүү: колдонууда namespaceSelector сиз тандаган аттар мейкиндигинде туура энбелги бар экенин текшериңиз. сыяктуу камтылган аттар мейкиндиктерин эске алыңыз default и kube-system, демейки боюнча энбелгилерди камтыбайт.

Сиз төмөнкүдөй боштукка энбелги кошо аласыз:

kubectl label namespace default namespace=default

Ошол эле учурда бөлүмдө аттар мейкиндиги metadata энбелгиге эмес, чыныгы мейкиндиктин аталышына кайрылышы керек:

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

Булак жана көздөгөн жер

Firewall саясаттары булактары жана көздөгөн жерлери бар эрежелерден турат. Kubernetes тармагынын саясаттары максаттуу үчүн аныкталат - алар колдонулуучу поддондор жыйындысы - андан кийин кирүү жана/же чыгуу трафиги үчүн эрежелерди белгилейт. Биздин мисалда саясаттын максаты аттар мейкиндигиндеги бардык подколор болот 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 бул саясатта, кирүүчү трафикти максаттуу поддондорго ачат. Башка сөз менен айтканда, кириш булак болуп саналат жана максаттуу тиешелүү көздөгөн. Ошо сыяктуу эле, чыгуу көздөгөн жер жана максат анын булагы.

Бул эки брандмауэр эрежесине барабар: Кирүү → Максат; Максат → Чыгуу.

Чыгуу жана 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 бош, ошондуктан ал кыйыр түрдө тандайт бардык аттар мейкиндиктериндеги бардык подколор, уруксат берүү balance DNS сурамдарын тиешелүү Kubernetes кызматына жөнөтүңүз (көбүнчө мейкиндикте иштейт kube-system).

Бирок, бул ыкма иштейт ашыкча уруксат берүүчү жана кооптуу, анткени ал DNS сурамдарын кластерден тышкары багыттоого мүмкүндүк берет.

Сиз аны үч кадам менен жакшыртсаңыз болот.

1. DNS сурамдарына гана уруксат бериңиз ичинде кошуу менен кластер namespaceSelector:

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

2. DNS сурамдарына аттар мейкиндигинде гана уруксат бериңиз kube-system.

Бул үчүн сиз аттар мейкиндигине энбелги кошуу керек kube-system: kubectl label namespace kube-system namespace=kube-system - жана аны колдонуу менен саясатка жаз namespaceSelector:

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

3. Параноид адамдар андан да ары барып, DNS сурамдарын белгилүү DNS кызматына чектей алышат kube-system. "Аттар мейкиндиктери ЖАНА подкектер боюнча чыпкалоо" бөлүмү буга кантип жетүүнү айтып берет.

Дагы бир вариант - DNS мейкиндигинин деңгээлинде чечүү. Бул учурда, ар бир кызмат үчүн ачуунун кереги жок:

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

бош podSelector аттар мейкиндигиндеги бардык подкасттарды тандайт.

Биринчи матч жана эреже тартиби

Кадимки брандмауэрлерде пакеттеги аракет (Уруксат берүү же четке кагуу) ал канааттандырган биринчи эреже менен аныкталат. Кубернетесте саясаттын тартиби маанилүү эмес.

Демейки боюнча, эч кандай саясат коюлбаганда, поддондордун ортосундагы байланышка уруксат берилет жана алар эркин маалымат алмаша алышат. Саясаттарды түзө баштаганыңыздан кийин, алардын жок дегенде бирөөсү таасир эткен ар бир поддон аны тандап алган бардык саясаттардын ажырашуусуна (логикалык ЖЕ) ылайык обочолонуп калат. Эч кандай саясаттын таасири тийбеген подколор ачык бойдон калууда.

Бул жүрүм-турумду чечип салуу эрежеси менен өзгөртө аласыз.

Сыноо эрежеси ("Чок")

Firewall саясаттары, адатта, ачык уруксат берилбеген трафикти четке кагат.

Kubernetesте баш тартуу аракети жок, бирок, ушундай эле эффектке булак капчыгынын бош тобун (кирүү) тандоо аркылуу үзгүлтүксүз (уруксат берүүчү) саясат менен жетишүүгө болот:

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

Бул саясат ат мейкиндигиндеги бардык подкасттарды тандап, кирүүнү аныкталбаган бойдон калтырып, бардык келген трафикти четке кагат.

Ушундай эле жол менен, сиз аттар мейкиндигинен бардык чыгуучу трафикти чектей аласыз:

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

Белгилей кетчү нерсе, аттар мейкиндигиндеги подкасттарга трафикке уруксат берген бардык кошумча саясаттар бул эрежеден артыкчылыкка ээ болот (брандмауэр конфигурациясындагы четке кагуу эрежесинин алдында уруксат берүү эрежесин кошууга окшош).

Баарына уруксат бер

"Баарына уруксат берүү" саясатын түзүү үчүн жогорудагы "Баар" саясатын бош элемент менен толукташыңыз керек ingress:

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

Бул кирүү мүмкүнчүлүгүн берет бардык аттар мейкиндиктериндеги (жана бардык IP) бардык подколор аттар мейкиндигиндеги каалаган подкокко default. Бул жүрүм-турум демейки боюнча иштетилген, ошондуктан, адатта, андан ары аныктоонун кереги жок. Бирок, кээде көйгөйдү аныктоо үчүн кээ бир атайын уруксаттарды убактылуу өчүрүшүңүз керек болушу мүмкүн.

Эрежени кирүү мүмкүнчүлүгүн гана кыскартууга болот тактардын белгилүү бир топтому (app:balance) аттар мейкиндигинде default:

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

Төмөнкү саясат бардык кириш жана чыгуу трафигине, анын ичинде кластерден тышкары каалаган IPге кирүү мүмкүнчүлүгүн берет:

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

Бир нече саясатты айкалыштыруу

Саясат логикалык ЖЕ үч деңгээлде бириктирилет; Ар бир поддондун уруксаттары ага таасир эткен бардык саясаттардын бөлүнүшүнө ылайык орнотулган:

1. Талааларда from и to элементтердин үч түрүн аныктоого болот (алардын баары ЖЕ колдонуу менен бириктирилет):

namespaceSelector — толук аталыш мейкиндигин тандайт;
podSelector — бадалдарды тандайт;
ipBlock — ички тармакты тандайт.

Мындан тышкары, бөлүмчөлөрдөгү элементтердин саны (ал тургай, бирдей). from/to чектелген эмес. Алардын баары логикалык ЖЕ менен бириктирилет.

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 (логикалык ЖЕ менен бириктирилген). Ошо сыяктуу эле, бөлүм 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. Ар кандай саясаттар да логикалык ЖЕ менен айкалышат

Бирок аларды бириктирип жатканда, бир чектөө бар Мен бар Крис Куни: Kubernetes саясаттарды башка менен гана айкалыштыра алат policyTypes (Ingress же Egress). Кирүүнү (же чыгууну) аныктаган саясаттар бири-биринин үстүнөн жазылат.

Ат мейкиндиктеринин ортосундагы байланыш

Демейки боюнча, аттар мейкиндиктери ортосунда маалымат алмашууга уруксат берилет. Муну аттар мейкиндигине чыгуучу жана/же кирүүчү трафикти чектей турган четке кагуу саясатын колдонуу менен өзгөртүүгө болот (жогоруда "Чыгуу эрежесин" караңыз).

Аттар мейкиндигине кирүү мүмкүнчүлүгүн бөгөттөп койгондон кийин (жогоруда "Аюу эрежесин" караңыз), белгилүү бир аттар мейкиндигинен туташууга уруксат берүү менен баш тартуу саясатынан өзгөчөлүктөр жасай аласыз. namespaceSelector:

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

Натыйжада, аттар мейкиндигиндеги бардык подколор default подряддарга кирүү мүмкүнчүлүгүнө ээ болот postgres аттар мейкиндигинде database. Бирок, эгер сиз кирүү мүмкүнчүлүгүн ачууну кааласаңыз postgres аттар мейкиндигинде конкреттүү подколор гана default?

Ат мейкиндиктери жана подколор боюнча чыпкалоо

Kubernetes версиясы 1.11 жана андан жогору операторлорду бириктирүүгө мүмкүндүк берет namespaceSelector и podSelector логикалык ЖАНА колдонуу. Бул төмөнкүдөй көрүнөт:

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

Эмне үчүн бул кадимки ЖЕ ордуна ЖАНА деп чечмеленет?

деп белгилешет podSelector дефис менен башталбайт. YAML бул дегенди билдирет podSelector жана анын алдында турат namespaceSelector ошол эле тизме элементине кайрылыңыз. Демек, алар логикалык ЖАНА менен айкалышат.

Алдын ала дефис кошуу podSelector жаңы тизме элементинин пайда болушуна алып келет, ал мурунку менен бириктирилет namespaceSelector логикалык ЖЕ колдонуу.

Белгилүү бир энбелгиси бар кабыктарды тандоо үчүн бардык аттар мейкиндигинде, бош киргизиңиз namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database.postgres
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

Бир нече энбелгилер мен менен биригет

Бир нече объектилер (хосттор, тармактар, топтор) менен брандмауэрдин эрежелери логикалык ЖЕ аркылуу бириктирилет. Пакет булагы дал келсе, төмөнкү эреже иштейт Host_1 ЖЕ Host_2:

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

Тескерисинче, Kubernetes-те ар кандай энбелгилер podSelector же namespaceSelector логикалык ЖАНА менен айкалыштырылган. Мисалы, төмөнкү эреже эки энбелгиси бар подкасттарды тандайт, role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

Ошол эле логика операторлордун бардык түрлөрүнө карата колдонулат: саясаттын максаттуу тандагычтары, поддон селекторлору жана аттар мейкиндигин тандагычтар.

Субтеттер жана IP даректер (IPBlocks)

Тармакты сегменттөө үчүн Firewalls VLANларды, IP даректерди жана субторлорду колдонушат.

Kubernetes'те IP даректер подъезддерге автоматтык түрдө дайындалат жана тез-тез өзгөрүп турушу мүмкүн, андыктан энбелгилер тармак саясаттарында подкасттарды жана аттар мейкиндиктерин тандоо үчүн колдонулат.

Кошумча тармактар (ipBlocks) кирүүчү (кирүүчү) же чыгуучу (чыгыш) тышкы (Түндүк-Түштүк) байланыштарды башкарууда колдонулат. Мисалы, бул саясат аттар мейкиндигиндеги бардык подколор үчүн ачылат default Google DNS кызматына кирүү:

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

Бул мисалдагы бош подкачка селектору "ат мейкиндигиндеги бардык подкасттарды тандоо" дегенди билдирет.

Бул саясат 8.8.8.8ге гана мүмкүнчүлүк берет; башка IP кирүүсүнө тыюу салынат. Демек, сиз ички Kubernetes DNS кызматына кирүү мүмкүнчүлүгүн бөгөттөп койдуңуз. Эгер дагы эле аны ачкыңыз келсе, муну ачык көрсөтүңүз.

адатта, ipBlocks и podSelectors бири-бирин жокко чыгарат, анткени поддондордун ички IP даректери колдонулбайт ipBlocks. көрсөтүү менен ички IP подколор, сиз чындыгында бул даректер менен подколор менен байланышууга уруксат бересиз. Иш жүзүндө, сиз кайсы IP даректи колдонууну билбей каласыз, ошондуктан аларды поддондорду тандоо үчүн колдонбоо керек.

Каршы мисал катары, төмөнкү саясат бардык IP'дерди камтыйт жана ошондуктан бардык башка подколорго мүмкүнчүлүк берет:

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

Сиз подкасттардын ички IP даректерин кошпогондо, тышкы 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

Порттор жана протоколдор

Адатта поддондор бир портту угат. Бул саясаттарда жөн гана порт номерлерин көрсөтпөй, бардыгын демейки катары калтыра албайсыз дегенди билдирет. Бирок, саясаттарды мүмкүн болушунча чектөөчү кылуу сунушталат, андыктан кээ бир учурларда сиз дагы эле портторду көрсөтө аласыз:

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 көрсөтүшүңүз керек.

Мындай механизмди оптималдуу эмес деп эсептеш керек: эгерде сервистин ички түзүмү (поддор уга турган порттору) өзгөрсө, тармактык саясаттарды жаңыртуу керек болот.

Service Mesh колдонуу менен жаңы архитектуралык ыкма (мисалы, төмөнкү Istio жөнүндө караңыз - болжол менен котормо.) бул көйгөй менен күрөшүүгө мүмкүндүк берет.

Ingress жана Egress экөөнү тең каттоо керекпи?

Кыска жооп: ооба, А подчосунун В подчасы менен байланышы үчүн, ага чыгуучу туташууну түзүүгө уруксат берилиши керек (бул үчүн сиз чыгуу саясатын конфигурациялашыңыз керек), ал эми B подкруги кирген байланышты кабыл ала алышы керек ( бул үчүн, демек, сиз кириш саясаты керек).

Бирок, иш жүзүндө, сиз бир же эки багытта туташууларга уруксат берүү үчүн демейки саясатка таяна аласыз.

Эгерде кээ бир под-булак бир же бир нече тарабынан тандалат чыгуу-саясатчылар, ага коюлган чектөөлөр алардын дизюнкциясы менен аныкталат. Бул учурда, сиз подкастка туташууга ачык уруксат беришиңиз керек болот -адресат. Подгон эч кандай саясат менен тандалбаса, анын чыгуу (чыгаруу) трафигине демейки боюнча уруксат берилет.

Ошо сыяктуу эле, поптун тагдырыадресат, бир же бир нече тарабынан тандалган кирүү-саясатчылар, алардын дизюнктурасы менен аныкталат. Бул учурда, сиз ага булактан трафикти алууга ачык уруксат беришиңиз керек. Кош эч кандай саясат менен тандалбаса, демейки боюнча ага бардык кириш трафигине уруксат берилет.

Төмөндө Мамлекеттик же жарандыгы жок караңыз.

журналдар |

Kubernetes тармак саясаттары трафикти каттай албайт. Бул саясат максатка ылайык иштеп жатканын аныктоону кыйындатат жана коопсуздук анализин бир топ татаалдатат.

Тышкы кызматтарга трафикти көзөмөлдөө

Kubernetes тармагынын саясаттары чыгуу бөлүмдөрүндө толук квалификациялуу домен атын (DNS) көрсөтүүгө жол бербейт. Бул факт туруктуу IP дареги жок (мисалы, aws.com) тышкы багыттарга трафикти чектөө аракетинде олуттуу ыңгайсыздыкка алып келет.

Саясат текшерүү

Firewalls сизге эскертет же туура эмес саясатты кабыл алуудан баш тартат. Kubernetes ошондой эле кээ бир текшерүүлөрдү жүргүзөт. kubectl аркылуу тармак саясатын коюп жатканда, Kubernetes аны туура эмес деп жарыялап, аны кабыл алуудан баш тартышы мүмкүн. Башка учурларда, Kubernetes саясатты алып, аны жетишпеген маалыматтар менен толтурат. Алар буйрукту колдонуу менен көрүүгө болот:

kubernetes get networkpolicy <policy-name> -o yaml

Kubernetes валидация системасы жаңылбас эмес жана каталардын айрым түрлөрүн өткөрүп жибериши мүмкүн экенин эстен чыгарбаңыз.

аткаруу

Kubernetes тармак саясатын өзү ишке ашырбайт, бирок жөн гана API шлюзи болуп саналат, ал башкаруу жүгүн Container Networking Interface (CNI) деп аталган негизги системага өткөрүп берет. Тиешелүү CNI дайындабастан Kubernetes кластеринде саясаттарды коюу, аларды брандмауэрлерге орнотпой туруп, брандмауэрди башкаруу серверинде саясаттарды түзүү менен бирдей. Сизде татыктуу CNI же, Kubernetes платформаларында булутта жайгаштырылган болушу сизге көз каранды. (сиз провайдерлердин тизмесин көрө аласыз бул жерде — болжол менен. транс.), сиз үчүн CNI орното турган тармак саясаттарын иштетиңиз.

Эгер CNI тиешелүү жардамчысы жок тармак саясатын орнотсоңуз, Kubernetes сизге эскертпей турганын эске алыңыз.

Мамлекеттик же жарандыгы жок?

Мен жолуккан бардык Kubernetes CNI'лери абалды билдирет (мисалы, Calico Linux conntrack колдонот). Бул подкастка ал баштаган TCP байланышы боюнча жоопторду аны кайра орнотпой туруп алууга мүмкүндүк берет. Бирок, мен абалга кепилдик бере турган Kubernetes стандартын билбейм.

Өркүндөтүлгөн коопсуздук саясатын башкаруу

Бул жерде Kubernetes коопсуздук саясатын жакшыртуу үчүн кээ бир жолдору:

Service Mesh архитектуралык үлгүсү тейлөө деңгээлинде деталдуу телеметрия жана жол кыймылын көзөмөлдөө үчүн каптал контейнерлерин колдонот. Мисал катары алсак болот Istio.
Кээ бир CNI сатуучулары Kubernetes тармактык саясаттарынын чегинен чыгуу үчүн куралдарын кеңейтишти.
Туфин Орка Kubernetes тармак саясаттарынын көрүнө жана автоматташтырылышын камсыз кылат.

Tufin Orca топтому Kubernetes тармактык саясаттарын башкарат (жана жогорудагы скриншоттордун булагы).

кошумча маалымат

жыйынтыктоо

Kubernetes тармактык саясаттары кластерлерди сегменттөө үчүн жакшы куралдар топтомун сунуштайт, бирок алар интуитивдик эмес жана көптөгөн кылдаттыктарга ээ. Ушул татаалдыктан улам, мен учурдагы кластердик саясаттардын көбү катаал деп эсептейм. Бул маселенин мүмкүн болгон чечимдери саясаттын аныктамаларын автоматташтыруу же башка сегментациялоо куралдарын колдонууну камтыйт.

Бул колдонмо кээ бир суроолорду чечүүгө жана сиз кабылган маселелерди чечүүгө жардам берет деп үмүттөнөм.

Котормочудан PS

Биздин блогдон дагы окуңуз:

"Istio менен микросервистерге кайтуу": 1-бөлүк (негизги өзгөчөлүктөргө киришүү), 2-бөлүк (маршрутизация, жол кыймылын башкаруу), 3-бөлүк (коопсуздук);
"Kubernetes тармагында иллюстрацияланган колдонмо": 1 жана 2 бөлүктөрү (тармак модели, кабаттуу тармактар), 3-бөлүк (кызматтар жана трафикти иштетүү);
«Docker жана Kubernetes коопсуздукту сезгич чөйрөлөрдө";
«9 Kubernetes коопсуздуктун мыкты тажрыйбалары";
«Kubernetes хакынын курмандыгы болуунун (эмес) 11 жолу«.

Source: www.habr.com

Коопсуздук адистери үчүн Kubernetes тармактык саясаттарына киришүү