🥇Аюулгүй байдлын мэргэжилтнүүдэд зориулсан Kubernetes сүлжээний бодлогын танилцуулга

Анхаарна уу. орчуулга.: Өгүүллийн зохиогч Рэвэн Харрисон нь програм хангамж боловсруулах чиглэлээр 20 гаруй жил ажилласан туршлагатай бөгөөд өнөөдөр аюулгүй байдлын бодлогын удирдлагын шийдлийг бий болгодог Tufin компанийн CTO бөгөөд хамтран үүсгэн байгуулагч юм. Тэрээр Кубернетес сүлжээний бодлогыг кластер дахь сүлжээний сегментчилэлд зориулсан нэлээд хүчирхэг хэрэгсэл гэж үздэг ч практикт хэрэгжүүлэхэд тийм ч хялбар биш гэж тэр үзэж байна. Энэхүү материал (нэлээн том хэмжээтэй) нь мэргэжилтнүүдийн энэ асуудлын талаарх мэдлэгийг дээшлүүлэх, шаардлагатай тохиргоог хийхэд нь туслах зорилготой юм.

Өнөөдөр олон компаниуд өөрсдийн програмуудыг ажиллуулахын тулд Kubernetes-ийг сонгох нь нэмэгдсээр байна. Энэ програм хангамжийн сонирхол маш өндөр байгаа тул зарим хүмүүс Kubernetes-ийг "өгөгдлийн төвийн шинэ үйлдлийн систем" гэж нэрлэж байна. Аажмаар Кубернетес (эсвэл k8s) нь сүлжээний аюулгүй байдлыг багтаасан төлөвшсөн бизнесийн үйл явцыг зохион байгуулахыг шаарддаг бизнесийн чухал хэсэг гэж ойлгож эхэлж байна.

Kubernetes-тэй ажиллахдаа эргэлзэж буй аюулгүй байдлын мэргэжилтнүүдийн хувьд жинхэнэ илчлэлт нь платформын үндсэн бодлого байж болох юм: бүгдийг зөвшөөрөх.

Энэхүү гарын авлага нь сүлжээний бодлогын дотоод бүтцийг ойлгоход тусална; ердийн галт ханын дүрмээс юугаараа ялгаатай болохыг ойлгох. Энэ нь мөн зарим бэрхшээлийг хамарч, Kubernetes дээрх програмуудыг хамгаалахад туслах зөвлөмжийг өгөх болно.

Kubernetes сүлжээний бодлого

Kubernetes сүлжээний бодлогын механизм нь сүлжээний давхаргад (OSI загварын гурав дахь) платформ дээр байрлуулсан програмуудын харилцан үйлчлэлийг удирдах боломжийг олгодог. Сүлжээний бодлогод OSI Layer 7-ын хэрэгжилт, аюул заналыг илрүүлэх зэрэг орчин үеийн галт ханын зарим дэвшилтэт шинж чанарууд дутагдаж байгаа боловч тэдгээр нь сүлжээний аюулгүй байдлын үндсэн түвшинг хангадаг бөгөөд энэ нь сайн эхлэл болдог.

Сүлжээний бодлого нь pods хоорондын харилцаа холбоог хянадаг

Кубернетес дэх ажлын ачааллыг хамт байрлуулсан нэг буюу хэд хэдэн контейнерээс бүрдэх pods-д хуваарилдаг. Кубернетес нь под тус бүрт бусад pods-ээс хандах боломжтой IP хаягийг оноодог. Кубернетес сүлжээний бодлого нь үүлэн доторх аюулгүй байдлын бүлгүүдийг виртуал машины инстанцуудад хандах хандалтыг хянахад ашигладагтай адилаар бүлгүүдэд нэвтрэх эрхийг тогтоодог.

Сүлжээний бодлогыг тодорхойлох

Kubernetes-ийн бусад нөөцийн нэгэн адил сүлжээний бодлогыг YAML-д заасан байдаг. Доорх жишээнд програм balance хандах postgres:

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

(Анхаарна уу. орчуулга.: энэхүү дэлгэцийн агшинг дараагийн ижил төстэй зургуудын нэгэн адил уугуул Kubernetes хэрэгслийг бус харин эх нийтлэлийн зохиогчийн компаний боловсруулсан Tufin Orca хэрэгслийг ашиглан хийсэн бөгөөд материалын төгсгөлд дурдсан болно.)

Өөрийн сүлжээний бодлогыг тодорхойлохын тулд танд YAML-ийн үндсэн мэдлэг хэрэгтэй болно. Энэ хэл нь догол мөрөнд суурилдаг (табууд биш хоосон зайгаар тодорхойлогддог). Доголтой элемент нь түүний дээрх хамгийн ойр доголтой элементэд хамаарна. Жагсаалтын шинэ элемент нь зураасаар эхэлдэг, бусад бүх элементүүд нь хэлбэртэй байна түлхүүр-утга.

YAML-д бодлогыг тайлбарласны дараа ашиглана уу кубектлкластерт үүсгэхийн тулд:

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 орхигдуулсан тохиолдолд бодлого нь бүх урсгалыг үгүйсгэх болно (доорх "Хуулгах дүрэм"-ийг үзнэ үү).

Өгөгдмөл бодлого нь Зөвшөөрөх

Хэрэв ямар нэгэн бодлого тодорхойлогдоогүй бол Кубернетес бүх урсгалыг анхдагчаар зөвшөөрдөг. Бүх pods хоорондоо чөлөөтэй мэдээлэл солилцох боломжтой. Аюулгүй байдлын үүднээс энэ нь ойлгомжгүй мэт санагдаж болох ч Kubernetes-ийг анх программуудын харилцан ажиллах чадварыг идэвхжүүлэхийн тулд хөгжүүлэгчид бүтээсэн гэдгийг санаарай. Сүлжээний бодлогыг дараа нь нэмсэн.

Нэрийн орон зай

Нэрийн орон зай нь 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 сонгох болно (энэ нь өөр нэрийн талбараас pods руу хандах эрхгүй).

Үүний нэгэн адил podSelectors орох ба гарах блокуудад Мэдээжийн хэрэг та тэдгээрийг нэгтгэхээс бусад тохиолдолд зөвхөн өөрийн нэрийн зайнаас pods сонгох боломжтой namespaceSelector (үүнийг "Нэрний орон зай ба хонгилоор шүүх" хэсэгт авч үзэх болно).

Бодлогын нэрлэх дүрэм

Бодлогын нэрс нь ижил нэрийн зайд өвөрмөц байна. Нэг орон зайд ижил нэртэй хоёр бодлого байж болохгүй, гэхдээ өөр өөр орон зайд ижил нэртэй бодлого байж болно. Энэ нь олон орон зайд ижил бодлогыг дахин хэрэглэхийг хүсвэл хэрэг болно.

Би ялангуяа нэрлэх аргуудын нэгд дуртай. Энэ нь нэрийн орон зайн нэрийг зорилтот 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 объектууд, тухайлбал pods, namespace гэх мэт тусгай шошго хавсаргаж болно. Шошго (хаяг - шошго) нь үүлэн дээрх шошготой тэнцүү юм. Kubernetes сүлжээний бодлого нь сонгохдоо шошгыг ашигладаг хонхорцогтэдгээрт хамаарах:

podSelector:
  matchLabels:
    role: db

… эсвэл нэрийн орон зайтэдгээрт хамаарах. Энэ жишээ нь нэрийн талбар дахь бүх pods-ыг харгалзах шошготойгоор сонгоно:

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 сүлжээний бодлогууд нь зорилтот бүлэгт зориулагдсан байдаг - тэдгээрийн хамаарах багцын багц - дараа нь нэвтрэх болон/эсвэл гарах хөдөлгөөний дүрмийг тогтоодог. Бидний жишээн дээр бодлогын зорилт нь нэрийн талбар дахь бүх 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 → Target; Зорилго → Гарах.

Гарах болон 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. Зөвхөн нэрийн зайд 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 нэрийн талбар дахь бүх pods-ыг сонгоно.

Эхний тоглолт ба дүрмийн дараалал

Ердийн галт хананд пакет дээрх үйлдлийг (Зөвшөөрөх эсвэл үгүйсгэх) эхний дүрмээр тодорхойлдог. Кубернетесэд бодлогын дараалал хамаагүй.

Өгөгдмөл байдлаар, ямар ч бодлого тохируулаагүй үед pods хоорондын харилцааг зөвшөөрдөг бөгөөд тэд чөлөөтэй мэдээлэл солилцох боломжтой. Бодлого боловсруулж эхэлмэгц дор хаяж нэг нь нөлөөлөлд өртсөн хэсэг бүр нь түүнийг сонгосон бүх бодлогын салгах (логик OR) дагуу тусгаарлагдана. Аливаа бодлогод өртөөгүй хонхорцог нээлттэй хэвээр байна.

Та тайрах дүрмийг ашиглан энэ зан үйлийг өөрчилж болно.

Хөрс тайлах дүрэм ("Татгалзах")

Галт ханын бодлого нь ихэвчлэн зөвшөөрөгдөөгүй аливаа урсгалыг үгүйсгэдэг.

Kubernetes-д татгалзах үйлдэл байхгүй, гэхдээ ижил төстэй нөлөөг эх сурвалжийн хоосон бүлгийг (оролтын) сонгох замаар тогтмол (зөвшөөрөх) бодлогоор хийж болно:

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

Энэ удирдамж нь нэрийн талбар дахь бүх pods-ыг сонгож, нэвтрэлтийг тодорхойгүй орхиж, ирж буй бүх урсгалыг үгүйсгэдэг.

Үүнтэй адилаар та нэрийн зайнаас гарах бүх урсгалыг хязгаарлаж болно:

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

Үүнийг анхаарна уу Нэрийн талбар дахь pods руу урсгалыг зөвшөөрөх аливаа нэмэлт бодлого энэ дүрмээс давуу байх болно (галт ханын тохиргоонд татгалзах дүрмийн өмнө зөвшөөрөх дүрмийг нэмэхтэй адил).

Бүх зүйлийг зөвшөөрөх (Ямар ч-ямар-ямар-зөвшөөрөх)

Бүгдийг зөвшөөрөх бодлогыг үүсгэхийн тулд дээрх Татгалзах бодлогыг хоосон элементээр нэмэх шаардлагатай ingress:

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

-аас хандах боломжийг олгодог бүх нэрийн талбар дахь бүх pods (болон бүх IP) нэрийн талбар дахь дурын pod руу 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

Олон бодлогыг хослуулах

Бодлогуудыг гурван түвшинд логик OR ашиглан нэгтгэдэг; Под тус бүрийн зөвшөөрлийг түүнд нөлөөлөх бүх бодлогын салалтын дагуу тохируулсан:

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-той хослуулдаг

Гэхдээ тэдгээрийг нэгтгэхдээ нэг хязгаарлалт байдаг гэж заажээ Крис Куни: 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

Үүний үр дүнд нэрийн талбар дахь бүх pods default pods-д хандах боломжтой болно postgres нэрийн орон зайд database. Харин хандалтыг нээхийг хүсвэл яах вэ postgres зөвхөн нэрийн талбар дахь тодорхой pods default?

Нэрийн орон зай болон 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-ын оронд БА гэж тайлбарладаг вэ?

тэрийг тэмдэглэ 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

Олон шошго нь I-тэй нэгддэг

Олон объект (хост, сүлжээ, бүлэг) бүхий галт ханын дүрмийг логик OR ашиглан нэгтгэдэг. Пакетийн эх үүсвэр таарч байвал дараах дүрэм ажиллана Host_1 Эсвэл 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

Үүнтэй ижил логик нь бүх төрлийн операторуудад хамаарна: бодлогын зорилтот сонгогч, под сонгогч, нэрийн орон зай сонгогч.

Дэд сүлжээ ба IP хаягууд (IPBlocks)

Галт хана нь сүлжээг сегментлэхийн тулд VLAN, IP хаяг, дэд сүлжээг ашигладаг.

Kubernetes-д IP хаягуудыг pods-д автоматаар хуваарилдаг бөгөөд байнга өөрчлөгдөж байдаг тул сүлжээний бодлого дахь pods болон нэрийн орон зайг сонгоход шошгыг ашигладаг.

Дэд сүлжээ (ipBlocks) нь орж ирж буй (орох) эсвэл гарах (гарах) гадаад (Хойд-Өмнөд) холболтыг удирдахад ашиглагддаг. Жишээлбэл, энэ удирдамж нь нэрийн талбараас бүх 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

Энэ жишээн дээрх хоосон pod сонгогч нь "нэрийн талбар дахь бүх pods сонгох" гэсэн утгатай.

Энэ бодлого нь зөвхөн 8.8.8.8-д хандахыг зөвшөөрдөг; бусад IP руу нэвтрэхийг хориглоно. Тиймээс, үндсэндээ та дотоод Kubernetes DNS үйлчилгээнд хандах хандалтыг хаасан байна. Хэрэв та үүнийг нээхийг хүсч байгаа бол үүнийг тодорхой зааж өгнө үү.

нь ихэвчлэн ipBlocks и podSelectors pods-ийн дотоод IP хаягийг ашигладаггүй тул бие биенээ үгүйсгэдэг ipBlocks. Заалтаар дотоод IP pods, та үнэндээ эдгээр хаягтай подкуудтай холбогдохыг зөвшөөрөх болно. Бодит байдал дээр та аль IP хаягийг ашиглахаа мэдэхгүй байх болно, тиймээс тэдгээрийг pods сонгоход ашиглаж болохгүй.

Үүний эсрэг жишээ болгон дараах бодлого нь бүх 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

Та pods-ийн дотоод 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

Портууд ба протоколууд

Ихэвчлэн 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), энэ нь бүх портуудыг хэлнэ.

Шилдэг туршлага: Өгөгдмөл утгуудад бүү найд, өөрт хэрэгтэй зүйлээ тодорхой зааж өг.

Та үйлчилгээний порт биш харин pod портуудыг ашиглах ёстойг анхаарна уу (дараагийн догол мөрөнд энэ талаар дэлгэрэнгүй).

Бодлого нь үйлчилгээ эсвэл үйлчилгээний талаар тодорхойлогдсон уу?

Ер нь Кубернетес дэх pods нь үйлчилгээгээр дамжуулан бие биедээ ханддаг - энэ үйлчилгээг хэрэгжүүлдэг подкууд руу урсгалыг дахин чиглүүлдэг виртуал ачааллын тэнцвэржүүлэгч. Та сүлжээний бодлого нь үйлчилгээнд хандах хандалтыг хянадаг гэж бодож болох ч энэ нь тийм биш юм. Kubernetes сүлжээний бодлого нь үйлчилгээний порт биш харин под портууд дээр ажилладаг.

Жишээлбэл, хэрэв үйлчилгээ нь 80-р портыг сонсдог боловч траффикийг 8080-р порт руу чиглүүлдэг бол та сүлжээний бодлогод яг 8080-ыг зааж өгөх ёстой.

Ийм механизмыг оновчтой биш гэж үзэх нь зүйтэй: хэрэв үйлчилгээний дотоод бүтэц (подууд нь сонсдог портууд) өөрчлөгдвөл сүлжээний бодлогыг шинэчлэх шаардлагатай болно.

Service Mesh ашиглан архитектурын шинэ хандлага (жишээ нь, Istio-ийн талаар доороос үзнэ үү - ойролцоогоор. орчуул.) Энэ асуудлыг даван туулах боломжийг танд олгоно.

Ingress болон Egress хоёуланг нь бүртгүүлэх шаардлагатай юу?

Богино хариулт нь тийм ээ, А подвол B-тэй холбогдохын тулд гадагш гарах холболт үүсгэхийг зөвшөөрсөн байх ёстой (үүнд та гарах бодлогыг тохируулах шаардлагатай), харин B pod нь ирж буй холболтыг хүлээн авах боломжтой байх ёстой ( Үүний тулд танд нэвтрэх бодлого хэрэгтэй болно). бодлого).

Гэсэн хэдий ч бодит байдал дээр та нэг эсвэл хоёр чиглэлд холболтыг зөвшөөрөхийн тулд анхдагч бодлогод найдаж болно.

Хэрэв зарим нэг под-эх сурвалж нэг буюу хэд хэдэн сонголт хийх болно гарц-Улстөрчид, үүнд тавьсан хязгаарлалтыг тэдний салалтаар тодорхойлно. Энэ тохиолдолд та подтой холболтыг тодорхой зөвшөөрөх хэрэгтэй болно -хаяг хүлээн авагч руу. Хэрэв pod нь ямар нэгэн бодлогоор сонгогдоогүй бол түүний гадагшлах урсгалыг анхдагчаар зөвшөөрнө.

Үүний нэгэн адил хонхорхойн хувь тавилан бийхаяг хүлээн авагч, нэг буюу түүнээс дээш сонгосон оролт-Улстөрчдийг ялгаж салгаснаар тодорхойлогдоно. Энэ тохиолдолд та эх сурвалжаас урсгалыг хүлээн авахыг тодорхой зөвшөөрөх ёстой. Хэрэв ямар нэгэн бодлогоор подвол сонгогдоогүй бол түүний бүх нэвтрэх урсгалыг анхдагчаар зөвшөөрнө.

Доорх Төрийн болон харьяалалгүй гэсэн хэсгийг үзнэ үү.

Бүртгэл

Kubernetes сүлжээний бодлого нь урсгалыг бүртгэх боломжгүй. Энэ нь бодлого төлөвлөсний дагуу ажиллаж байгаа эсэхийг тодорхойлоход хүндрэл учруулж, аюулгүй байдлын шинжилгээг ихээхэн хүндрүүлдэг.

Гадаад үйлчилгээ рүү чиглэсэн урсгалыг хянах

Kubernetes сүлжээний бодлого нь гарах хэсэгт бүрэн хангасан домэйн нэрийг (DNS) зааж өгөхийг зөвшөөрдөггүй. Энэ баримт нь тогтмол IP хаяггүй (aws.com гэх мэт) гадаад чиглэлийн урсгалыг хязгаарлахыг оролдоход ихээхэн эвгүй байдалд хүргэдэг.

Бодлогын шалгалт

Галт хана нь танд анхааруулах эсвэл буруу бодлогыг хүлээн зөвшөөрөхөөс татгалзах болно. Кубернетес мөн зарим баталгаажуулалт хийдэг. kubectl-ээр дамжуулан сүлжээний бодлогыг тогтоохдоо Кубернетес үүнийг буруу гэж мэдэгдэж, хүлээн авахаас татгалзаж магадгүй юм. Бусад тохиолдолд Кубернетес бодлогыг авч, дутуу дэлгэрэнгүй мэдээллээр бөглөнө. Тэдгээрийг дараах тушаалыг ашиглан харж болно.

kubernetes get networkpolicy <policy-name> -o yaml

Kubernetes баталгаажуулалтын систем нь алдаатай биш бөгөөд зарим төрлийн алдааг алдаж магадгүй гэдгийг санаарай.

Гүйцэтгэл

Кубернетес нь сүлжээний бодлогыг өөрөө хэрэгжүүлдэггүй, харин зөвхөн Контейнер Сүлжээний Интерфейс (CNI) хэмээх үндсэн системд хяналтын ачааллыг шилжүүлдэг API гарц юм. Kubernetes кластерт тохирох CNI-г өгөхгүйгээр бодлого тогтоох нь галт ханан дээр суулгахгүйгээр галт ханын удирдлагын сервер дээр бодлого үүсгэхтэй адил юм. Та зохих CNI-тэй эсэх, эсвэл Kubernetes платформын хувьд үүлэн дээр байрлуулсан эсэх нь танаас хамаарна. (та үйлчилгээ үзүүлэгчдийн жагсаалтыг харж болно энд - ойролцоогоор. транс.), танд CNI тохируулах сүлжээний бодлогыг идэвхжүүл.

Хэрэв та тохирох туслах CNIгүйгээр сүлжээний бодлогыг тохируулбал Kubernetes танд анхааруулахгүй гэдгийг анхаарна уу.

Төрийн харьяалалтай эсвэл харьяалалгүй юу?

Миний тааралдсан бүх Kubernetes CNI нь төлөвтэй байна (жишээ нь, Calico нь Linux conntrack ашигладаг). Энэ нь pod-д дахин тохируулах шаардлагагүйгээр эхлүүлсэн TCP холболтын хариуг хүлээн авах боломжийг олгодог. Гэсэн хэдий ч би төлөв байдлыг баталгаажуулах Kubernetes стандартыг мэдэхгүй байна.

Аюулгүй байдлын дэвшилтэт бодлогын менежмент

Kubernetes дахь аюулгүй байдлын бодлогын хэрэгжилтийг сайжруулах зарим арга замууд энд байна:

Service Mesh архитектурын загвар нь үйлчилгээний түвшинд нарийвчилсан телеметр болон замын хөдөлгөөний хяналтыг хангахын тулд хажуугийн савыг ашигладаг. Бид жишээ болгон авч болно Истио.
Зарим CNI борлуулагчид Kubernetes сүлжээний бодлогоос давж гарахын тулд хэрэглүүрээ өргөтгөсөн.
Туфин Орка Kubernetes сүлжээний бодлогын харагдах байдал, автоматжуулалтыг хангадаг.

Tufin Orca багц нь Kubernetes сүлжээний бодлогыг удирддаг (мөн дээрх дэлгэцийн агшингийн эх сурвалж юм).

нэмэлт мэдээлэл

дүгнэлт

Kubernetes сүлжээний бодлого нь кластеруудыг сегментчлэх сайн хэрэгслүүдийг санал болгодог боловч тэдгээр нь ойлгомжтой биш бөгөөд олон нарийн шинж чанартай байдаг. Ийм нарийн төвөгтэй байдлаас болоод одоо байгаа кластерын олон бодлого алдаатай гэдэгт би итгэдэг. Энэ асуудлыг шийдэх боломжит шийдлүүд нь бодлогын тодорхойлолтыг автоматжуулах эсвэл бусад сегментчлэлийн хэрэгслийг ашиглах явдал юм.

Энэхүү гарын авлага нь зарим асуултыг тодруулж, танд тулгарч болзошгүй асуудлуудыг шийдвэрлэхэд тусална гэж найдаж байна.

Орчуулагчийн жич

Мөн манай блог дээрээс уншина уу:

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

Эх сурвалж: www.habr.com

Аюулгүй байдлын мэргэжилтнүүдэд зориулсан Kubernetes сүлжээний бодлогын талаархи танилцуулга