🥇Xavfsizlik bo'yicha mutaxassislar uchun Kubernetes tarmoq siyosatiga kirish

Eslatma. tarjima.: Maqola muallifi Reuven Xarrison dasturiy ta'minotni ishlab chiqishda 20 yildan ortiq tajribaga ega va bugungi kunda xavfsizlik siyosatini boshqarish yechimlarini yaratuvchi Tufin kompaniyasining CTO va hammuassisi hisoblanadi. U Kubernetes tarmoq siyosatini klasterda tarmoq segmentatsiyasi uchun juda kuchli vosita deb hisoblasa-da, amalda ularni amalga oshirish unchalik oson emasligiga ishonadi. Ushbu material (juda hajmli) mutaxassislarning ushbu masala bo'yicha xabardorligini oshirish va kerakli konfiguratsiyalarni yaratishga yordam berish uchun mo'ljallangan.

Bugungi kunda ko'plab kompaniyalar o'z ilovalarini ishga tushirish uchun Kubernetes-ni tobora ko'proq tanlamoqda. Ushbu dasturiy ta'minotga qiziqish shunchalik yuqoriki, ba'zilar Kubernetesni "ma'lumotlar markazi uchun yangi operatsion tizim" deb atashadi. Asta-sekin Kubernetes (yoki k8s) biznesning muhim qismi sifatida qabul qilina boshlaydi, bu esa etuk biznes jarayonlarini, shu jumladan tarmoq xavfsizligini tashkil qilishni talab qiladi.

Kubernetes bilan ishlashdan hayratda qolgan xavfsizlik mutaxassislari uchun haqiqiy vahiy platformaning standart siyosati bo'lishi mumkin: hamma narsaga ruxsat bering.

Ushbu qo'llanma tarmoq siyosatining ichki tuzilishini tushunishga yordam beradi; oddiy xavfsizlik devorlari qoidalaridan qanday farq qilishini tushuning. Shuningdek, u ba'zi tuzoqlarni qamrab oladi va Kubernetes-dagi ilovalarni himoya qilishga yordam beradigan tavsiyalar beradi.

Kubernetes tarmoq siyosati

Kubernetes tarmoq siyosati mexanizmi tarmoq darajasida (OSI modelida uchinchi) platformada joylashtirilgan ilovalarning o'zaro ta'sirini boshqarishga imkon beradi. Tarmoq siyosatlarida zamonaviy xavfsizlik devorlarining ba'zi ilg'or xususiyatlari, masalan, OSI Layer 7-ni qo'llash va tahdidlarni aniqlash mavjud emas, lekin ular yaxshi boshlanish nuqtasi bo'lgan tarmoq xavfsizligining asosiy darajasini ta'minlaydi.

Tarmoq siyosati podlar orasidagi aloqani nazorat qiladi

Kubernetes-dagi ish yuklari birgalikda joylashtirilgan bir yoki bir nechta konteynerlardan iborat bo'lgan podlar bo'ylab taqsimlanadi. Kubernetes har bir podkastga boshqa podlardan kirish mumkin bo'lgan IP manzilini tayinlaydi. Kubernetes tarmoq siyosatlari bulutdagi xavfsizlik guruhlari virtual mashina misollariga kirishni boshqarish uchun foydalanilganidek podalar guruhlari uchun kirish huquqlarini o‘rnatadi.

Tarmoq siyosatini aniqlash

Boshqa Kubernetes resurslari singari, tarmoq siyosatlari YAMLda ko'rsatilgan. Quyidagi misolda dastur balance kirish 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

(Eslatma. tarjima.: ushbu skrinshot, keyingi barcha shunga o'xshashlar singari, mahalliy Kubernetes vositalaridan foydalangan holda emas, balki asl maqola muallifi kompaniyasi tomonidan ishlab chiqilgan va materialning oxirida eslatib o'tilgan Tufin Orca vositasi yordamida yaratilgan.)

O'z tarmoq siyosatingizni aniqlash uchun sizga YAML bo'yicha asosiy bilim kerak bo'ladi. Bu til chekinishga asoslangan (yorliqlar emas, boʻshliqlar bilan koʻrsatilgan). Chekilgan element uning ustidagi eng yaqin chuqurlashtirilgan elementga tegishli. Ro'yxatning yangi elementi tire bilan boshlanadi, qolgan barcha elementlar shaklga ega kalit-qiymat.

YAML-da siyosatni tavsiflab, foydalaning kubectluni klasterda yaratish uchun:

kubectl create -f policy.yaml

Tarmoq siyosati spetsifikatsiyasi

Kubernetes tarmoq siyosati spetsifikatsiyasi to'rtta elementni o'z ichiga oladi:

podSelector: ushbu siyosat (maqsadlar) ta'sir qiladigan podslarni belgilaydi - talab qilinadi;
policyTypes: bunga qanday turdagi siyosatlar kiritilganligini ko'rsatadi: kirish va/yoki chiqish - ixtiyoriy, lekin barcha holatlarda uni aniq ko'rsatishni tavsiya etaman;
ingress: ruxsat etilganligini belgilaydi kirish maqsadli podslarga trafik - ixtiyoriy;
egress: ruxsat etilganligini belgilaydi chiquvchi maqsadli podlardan trafik ixtiyoriy.

Misol Kubernetes veb-saytidan olingan (men o'zgartirdim role haqida app), barcha to'rtta element qanday ishlatilishini ko'rsatadi:

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

Iltimos, to'rtta elementni kiritish shart emasligini unutmang. Bu faqat majburiydir podSelector, boshqa parametrlardan hohlagancha foydalanish mumkin.

Agar o'tkazib yuborsangiz policyTypes, siyosat quyidagicha talqin qilinadi:

Odatiy bo'lib, u kirish tomonini belgilaydi deb taxmin qilinadi. Agar siyosatda bu aniq ko'rsatilmagan bo'lsa, tizim barcha trafik taqiqlangan deb hisoblaydi.
Chiqish tomonidagi xatti-harakatlar tegishli chiqish parametrining mavjudligi yoki yo'qligi bilan belgilanadi.

Xatolarga yo'l qo'ymaslik uchun men tavsiya qilaman har doim aniq qilib qo'ying policyTypes.

Yuqoridagi mantiqqa ko'ra, agar parametrlar ingress va / yoki egress o'tkazib yuborilgan bo'lsa, siyosat barcha trafikni rad etadi (quyidagi "O'chirish qoidasi"ga qarang).

Birlamchi siyosat Ruxsat berish

Hech qanday siyosat aniqlanmagan bo'lsa, Kubernetes sukut bo'yicha barcha trafikga ruxsat beradi. Barcha podlar o'zaro erkin ma'lumot almashishlari mumkin. Bu xavfsizlik nuqtai nazaridan qarama-qarshi bo'lib tuyulishi mumkin, lekin esda tutingki, Kubernetes dastlab ishlab chiquvchilar tomonidan ilovalarning o'zaro ishlashini ta'minlash uchun ishlab chiqilgan. Tarmoq siyosatlari keyinroq qo'shildi.

Nom maydonlari

Nom maydonlari Kubernetes hamkorlik mexanizmidir. Ular mantiqiy muhitlarni bir-biridan ajratish uchun mo'ljallangan, sukut bo'yicha bo'shliqlar orasidagi aloqaga ruxsat beriladi.

Ko'pgina Kubernetes komponentlari singari, tarmoq siyosatlari ham ma'lum bir nom maydonida yashaydi. Blokda metadata siyosat qaysi maydonga tegishli ekanligini belgilashingiz mumkin:

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

Agar nom maydoni metadatada aniq ko'rsatilmagan bo'lsa, tizim kubectl da ko'rsatilgan nom maydonidan foydalanadi (sukut bo'yicha namespace=default):

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

Men Tavsiya qilaman nom maydonini aniq belgilang, agar siz bir vaqtning o'zida bir nechta nom maydoniga mo'ljallangan siyosat yozmasangiz.

Основной element podSelector siyosatda siyosat tegishli bo'lgan nomlar maydonidan podlarni tanlaydi (boshqa nom maydonidan podslarga kirish taqiqlangan).

Xuddi shunday, podSelectors kirish va chiqish bloklarida Agar siz ularni birlashtirmasangiz, faqat o'z nom maydonidan podlarni tanlashi mumkin namespaceSelector (bu "Ismlar va podalar bo'yicha filtrlash" bo'limida muhokama qilinadi).

Siyosat nomlash qoidalari

Siyosat nomlari bir xil nomlar maydonida noyobdir. Bitta maydonda bir xil nomli ikkita siyosat bo'lishi mumkin emas, lekin turli joylarda bir xil nomdagi siyosatlar bo'lishi mumkin. Bu bir xil siyosatni bir nechta bo'shliqlarda qayta qo'llamoqchi bo'lsangiz foydali bo'ladi.

Menga, ayniqsa, nom berish usullaridan biri yoqadi. U nom maydoni nomini maqsadli pods bilan birlashtirishdan iborat. Masalan:

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

Yorliqlar

Siz Kubernetes obyektlariga, masalan, podlar va nomlar boʻshliqlari kabi maxsus teglarni biriktirishingiz mumkin. Yorliqlar (yorliqlar - teglar) bulutdagi teglarning ekvivalentidir. Kubernetes tarmoq siyosati tanlash uchun teglardan foydalanadi podalarular qo'llaniladigan:

podSelector:
  matchLabels:
    role: db

… yoki nom maydonlariular tegishli bo'lgan. Ushbu misol nom bo'shliqlaridagi barcha podslarni tegishli teglar bilan tanlaydi:

namespaceSelector:
  matchLabels:
    project: myproject

Bitta ogohlantirish: foydalanilganda namespaceSelector siz tanlagan nom maydonlarida to'g'ri yorliq borligiga ishonch hosil qiling. kabi o'rnatilgan nom maydonlari mavjudligini yodda tuting default и kube-system, sukut bo'yicha yorliqlarni o'z ichiga olmaydi.

Bo'sh joyga yorliq qo'shishingiz mumkin:

kubectl label namespace default namespace=default

Shu bilan birga, bo'limdagi nomlar maydoni metadata yorlig'iga emas, balki haqiqiy fazo nomiga murojaat qilishi kerak:

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

Manba va maqsad

Xavfsizlik devori siyosatlari manbalar va maqsadli qoidalardan iborat. Kubernetes tarmoq siyosatlari maqsad uchun belgilanadi - ular qo'llaniladigan podlar to'plami - va keyin kirish va/yoki chiqish trafiki uchun qoidalarni o'rnatadi. Bizning misolimizda siyosatning maqsadi nomlar maydonidagi barcha pods bo'ladi default kalit bilan yorliq bilan app va ma'nosi 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

Pastki qism ingress ushbu siyosatda kiruvchi trafikni maqsadli podslarga ochadi. Boshqacha qilib aytganda, kirish manba, maqsad esa mos keladigan manzildir. Xuddi shunday, chiqish - maqsad va maqsad uning manbai.

Bu ikkita xavfsizlik devori qoidalariga teng: Ingress → Target; Maqsad → Chiqish.

Chiqish va DNS (muhim!)

Chiquvchi trafikni cheklash orqali, DNS-ga alohida e'tibor bering - Kubernetes ushbu xizmatdan xizmatlarni IP manzillarga xaritalash uchun foydalanadi. Masalan, quyidagi siyosat ishlamaydi, chunki siz ilovaga ruxsat bermagansiz balance DNS-ga kirish:

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 xizmatiga kirishni ochish orqali uni tuzatishingiz mumkin:

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

Oxirgi element to bo'sh, shuning uchun u bilvosita tanlaydi barcha nomlar maydonidagi barcha pods, ruxsat berish balance DNS so'rovlarini tegishli Kubernetes xizmatiga yuboring (odatda bo'sh joyda ishlaydi kube-system).

Biroq, bu yondashuv ishlaydi haddan tashqari ruxsat beruvchi va ishonchsiz, chunki u DNS so'rovlarini klasterdan tashqariga yo'naltirishga imkon beradi.

Siz uni uchta ketma-ket bosqichda yaxshilashingiz mumkin.

1. Faqat DNS so'rovlariga ruxsat bering ichida qo'shish orqali klaster 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 so'rovlariga faqat nomlar maydonida ruxsat bering kube-system.

Buni amalga oshirish uchun siz nomlar maydoniga yorliq qo'shishingiz kerak kube-system: kubectl label namespace kube-system namespace=kube-system - va uni siyosatga yozib qo'ying 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. Paranoyak odamlar yanada uzoqroqqa borishlari va DNS so'rovlarini ma'lum bir DNS xizmatiga cheklashlari mumkin kube-system. "Ismlar bo'shliqlari VA podlar bo'yicha filtrlash" bo'limi sizga bunga qanday erishish mumkinligini aytib beradi.

Yana bir variant - DNS-ni nom maydoni darajasida hal qilish. Bunday holda, uni har bir xizmat uchun ochish shart emas:

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

Bo'sh podSelector nomlar maydonidagi barcha podslarni tanlaydi.

Birinchi o'yin va qoida tartibi

An'anaviy xavfsizlik devorlarida paketdagi harakat (Ruxsat berish yoki rad etish) u qanoatlantiradigan birinchi qoida bilan belgilanadi. Kubernetesda siyosat tartibi muhim emas.

Odatiy bo'lib, hech qanday siyosat o'rnatilmaganda, podlar o'rtasidagi aloqaga ruxsat beriladi va ular erkin ma'lumot almashishlari mumkin. Siyosatlarni shakllantirishni boshlaganingizdan so'ng, ulardan kamida bittasi ta'sir ko'rsatadigan har bir bo'lak uni tanlagan barcha siyosatlarning ajratilishiga (mantiqiy OR) muvofiq ajratiladi. Hech qanday siyosat ta'sir qilmagan podalar ochiq qoladi.

Ushbu xatti-harakatni o'chirish qoidasi yordamida o'zgartirishingiz mumkin.

Olib tashlash qoidasi (“Rad etish”)

Xavfsizlik devori siyosati odatda ruxsat etilmagan har qanday trafikni rad etadi.

Kubernetesda rad etish harakati yo'q, ammo shunga o'xshash ta'sirga oddiy (ruxsat beruvchi) siyosat bilan bo'sh manba pods (kirish) guruhini tanlash orqali erishish mumkin:

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

Bu siyosat nomlar maydonidagi barcha podlarni tanlaydi va kirishni aniqlanmagan holda qoldiradi va barcha kiruvchi trafikni rad etadi.

Xuddi shunday, siz nom maydonidan barcha chiquvchi trafikni cheklashingiz mumkin:

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

Iltimos, unutmang nomlar maydonidagi podslarga trafikni ruxsat beruvchi har qanday qo'shimcha siyosatlar ushbu qoidadan ustun bo'ladi (xavfsizlik devori konfiguratsiyasida rad etish qoidasidan oldin ruxsat berish qoidasini qo'shishga o'xshash).

Hamma narsaga ruxsat berish (Har qanday-har qanday-ruxsat berish)

Hammasiga ruxsat berish siyosatini yaratish uchun yuqoridagi Rad etish siyosatini bo‘sh element bilan to‘ldirishingiz kerak ingress:

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

dan kirish imkonini beradi barcha nomlar maydonidagi barcha pods (va barcha IP) nomlar maydonidagi istalgan podga default. Ushbu xatti-harakatlar sukut bo'yicha yoqilgan, shuning uchun odatda uni qo'shimcha aniqlash kerak emas. Biroq, ba'zida muammoni aniqlash uchun ba'zi maxsus ruxsatnomalarni vaqtincha o'chirib qo'yishingiz kerak bo'lishi mumkin.

Qoida faqat kirishga ruxsat berish uchun qisqartirilishi mumkin ma'lum bir to'plam (app:balance) nomlar maydonida default:

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

Quyidagi siyosat barcha kirish va chiqish trafigiga, shu jumladan klasterdan tashqari har qanday IP-ga kirishga ruxsat beradi:

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

Bir nechta siyosatlarni birlashtirish

Siyosatlar mantiqiy OR yordamida uchta darajada birlashtiriladi; Har bir podning ruxsatlari unga ta'sir qiluvchi barcha siyosatlarning ajratilishiga muvofiq o'rnatiladi:

1. Maydonlarda from и to Uch turdagi elementlarni aniqlash mumkin (ularning barchasi OR yordamida birlashtirilgan):

namespaceSelector — butun nomlar maydonini tanlaydi;
podSelector — podlarni tanlaydi;
ipBlock — pastki tarmoqni tanlaydi.

Bundan tashqari, kichik bo'limlardagi elementlar soni (hatto bir xil bo'lsa ham). from/to cheklanmagan. Ularning barchasi mantiqiy OR tomonidan birlashtiriladi.

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. Siyosat bo'limi ichida ingress ko'p elementlarga ega bo'lishi mumkin from (mantiqiy OR bilan birlashtirilgan). Xuddi shunday, bo'lim egress ko‘plab elementlarni o‘z ichiga olishi mumkin to (shuningdek, disjunksiya bilan birlashtirilgan):

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. Turli xil siyosatlar ham mantiqiy OR bilan birlashtiriladi

Ammo ularni birlashtirganda, bitta cheklov mavjud ishora qildi Kris Kuni: Kubernetes siyosatlarni faqat boshqasi bilan birlashtira oladi policyTypes (Ingress yoki Egress). Kirish (yoki chiqish) ni belgilovchi siyosatlar bir-birining ustiga yoziladi.

Nom maydonlari o'rtasidagi munosabat

Odatiy bo'lib, nomlar o'rtasida ma'lumot almashishga ruxsat beriladi. Buni nomlar maydoniga chiquvchi va/yoki kiruvchi trafikni cheklaydigan rad etish siyosati yordamida oʻzgartirish mumkin (yuqoridagi “Oʻchirish qoidasi”ga qarang).

Nom maydoniga kirishni bloklaganingizdan so'ng (yuqoridagi "O'chirish qoidasiga" qarang), ma'lum bir nom maydonidan ulanishga ruxsat berish orqali rad etish siyosatidan istisno qilishingiz mumkin. 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

Natijada, nomlar maydonidagi barcha pods default podlarga kirish imkoniga ega bo'ladi postgres nom maydonida database. Ammo agar siz kirishni ochmoqchi bo'lsangiz nima bo'ladi postgres faqat nomlar maydonidagi maxsus podlar default?

Nom maydonlari va bo'shliqlar bo'yicha filtrlang

Kubernetesning 1.11 va undan yuqori versiyalari operatorlarni birlashtirish imkonini beradi namespaceSelector и podSelector mantiqiy AND yordamida. Bu shunday ko'rinadi:

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

Nima uchun bu odatiy OR o'rniga VA deb talqin qilinadi?

E'tibor bering podSelector defis bilan boshlanmaydi. YAMLda bu shuni anglatadi podSelector va uning oldida turib namespaceSelector xuddi shu ro'yxat elementiga murojaat qiling. Shuning uchun ular mantiqiy AND bilan birlashtiriladi.

Oldinga defis qo'yish podSelector oldingi bilan birlashtiriladigan yangi ro'yxat elementining paydo bo'lishiga olib keladi namespaceSelector mantiqiy OR dan foydalanish.

Muayyan yorliqli podlarni tanlash uchun barcha nom maydonlarida, bo'sh kiriting 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

Bir nechta teglar I bilan birlashadi

Bir nechta ob'ektlar (xostlar, tarmoqlar, guruhlar) bilan xavfsizlik devori qoidalari mantiqiy OR yordamida birlashtiriladi. Agar paket manbasi mos kelsa, quyidagi qoida ishlaydi Host_1 YoKI Host_2:

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

Aksincha, Kubernetesda turli teglar mavjud podSelector yoki namespaceSelector mantiqiy AND bilan birlashtiriladi. Masalan, quyidagi qoida ikkala tegga ega boʻlgan podlarni tanlaydi, role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

Xuddi shu mantiq barcha turdagi operatorlar uchun qo'llaniladi: siyosat maqsadli selektorlari, pod selektorlari va nom maydoni selektorlari.

Subnets va IP manzillar (IPBlocks)

Tarmoqni segmentlash uchun xavfsizlik devorlari VLAN, IP manzillar va pastki tarmoqlardan foydalanadi.

Kubernetes-da IP-manzillar podkalarga avtomatik ravishda tayinlanadi va tez-tez o'zgarishi mumkin, shuning uchun teglar tarmoq siyosatlarida podalar va nomlar bo'shliqlarini tanlash uchun ishlatiladi.

Quyi tarmoqlar (ipBlocks) kiruvchi (kirish) yoki chiquvchi (chiqish) tashqi (Shimoliy-Janubiy) ulanishlarni boshqarishda ishlatiladi. Masalan, ushbu siyosat nomlar maydonidagi barcha podslarga ochiladi default Google DNS xizmatiga kirish:

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

Ushbu misoldagi bo'sh pod selektori "nomlar maydonidagi barcha podlarni tanlash" degan ma'noni anglatadi.

Bu siyosat faqat 8.8.8.8 ga kirishga ruxsat beradi; boshqa har qanday IP-ga kirish taqiqlanadi. Shunday qilib, aslida siz ichki Kubernetes DNS xizmatiga kirishni blokladingiz. Agar siz hali ham uni ochmoqchi bo'lsangiz, buni aniq ko'rsating.

odatda ipBlocks и podSelectors bir-birini istisno qiladi, chunki podkastlarning ichki IP manzillari ishlatilmaydi ipBlocks. Ko'rsatish orqali ichki IP pods, siz aslida ushbu manzillar bilan podkalarga/ulanishlarga ruxsat berasiz. Amalda siz qaysi IP-manzildan foydalanishni bilmay qolasiz, shuning uchun ularni podkastlarni tanlashda ishlatmaslik kerak.

Bunga qarshi misol sifatida quyidagi siyosat barcha IP-larni o'z ichiga oladi va shuning uchun boshqa barcha podkastlarga kirishga ruxsat beradi:

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

Podlarning ichki IP manzillaridan tashqari faqat tashqi IP-larga kirishni ochishingiz mumkin. Masalan, agar podkastingizning quyi tarmog'i 10.16.0.0/14 bo'lsa:

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

Portlar va protokollar

Odatda podlar bitta portni tinglaydi. Bu shuni anglatadiki, siz port raqamlarini siyosatlarda ko'rsata olmaysiz va hamma narsani sukut bo'yicha qoldira olmaysiz. Biroq, siyosatlarni iloji boricha cheklash tavsiya etiladi, shuning uchun ba'zi hollarda siz hali ham portlarni belgilashingiz mumkin:

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

E'tibor bering, selektor ports blokdagi barcha elementlar uchun amal qiladi to yoki from, o'z ichiga oladi. Turli xil elementlar to'plami uchun turli portlarni belgilash uchun ajrating ingress yoki egress bilan bir nechta kichik bo'limlarga to yoki from va har birida portlaringizni ro'yxatdan o'tkazing:

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

Standart port ishlashi:

Agar siz port ta'rifini butunlay o'tkazib yuborsangiz (ports), bu barcha protokollar va barcha portlarni anglatadi;
Agar siz protokol ta'rifini o'tkazib yuborsangiz (protocol), bu TCP degan ma'noni anglatadi;
Agar siz port ta'rifini o'tkazib yuborsangiz (port), bu barcha portlarni bildiradi.

Eng yaxshi amaliyot: standart qiymatlarga tayanmang, kerakli narsani aniq belgilang.

E'tibor bering, siz xizmat ko'rsatish portlaridan emas, balki pod portlaridan foydalanishingiz kerak (bu haqda keyingi xatboshida).

Qoidalar yoki xizmatlar uchun siyosatlar belgilanganmi?

Odatda, Kubernetesdagi podlar bir-biriga xizmat orqali kirishadi - trafikni xizmatni amalga oshiradigan podslarga yo'naltiruvchi virtual yuk balansi. Siz tarmoq siyosati xizmatlarga kirishni nazorat qiladi deb o'ylashingiz mumkin, ammo bu unday emas. Kubernetes tarmoq siyosatlari xizmat portlarida emas, pod portlarida ishlaydi.

Misol uchun, agar xizmat 80-portni tinglasa, lekin trafikni o'z podslarining 8080-portiga yo'naltirsa, siz tarmoq siyosatida aniq 8080-ni ko'rsatishingiz kerak.

Bunday mexanizm suboptimal deb hisoblanishi kerak: agar xizmatning ichki tuzilishi (podlar tinglaydigan portlari) o'zgarsa, tarmoq siyosatini yangilash kerak bo'ladi.

Service Mesh-dan foydalangan holda yangi arxitektura yondashuvi (masalan, quyida Istio haqida qarang - taxminan. tarjima.) bu muammoni engishga imkon beradi.

Kirish va chiqishni ro'yxatdan o'tkazish kerakmi?

Qisqa javob ha, A podasi B podkasi bilan bog'lanishi uchun unga chiquvchi ulanishni yaratishga ruxsat berilishi kerak (buning uchun siz chiqish siyosatini sozlashingiz kerak) va B podkasi kiruvchi ulanishni qabul qila olishi kerak ( Buning uchun sizga kirish siyosati kerak).

Biroq, amalda siz bir yoki ikkala yo'nalishda ulanishga ruxsat berish uchun standart siyosatga tayanishingiz mumkin.

Agar ba'zi pod-manba bir yoki bir nechta tomonidan tanlanadi chiqish-siyosatchilar, unga qo'yilgan cheklovlar ularning diszyunksiyasi bilan belgilanadi. Bunday holda, siz podkastga ulanishga aniq ruxsat berishingiz kerak bo'ladi -adresatga. Agar pod hech qanday siyosat bilan tanlanmagan bo'lsa, uning chiquvchi (chiqish) trafigiga sukut bo'yicha ruxsat beriladi.

Xuddi shunday, podaning taqdiri hamqabul qiluvchi, bir yoki bir nechta tomonidan tanlangan kirish-siyosatchilar, ularning ajratilishi bilan belgilanadi. Bunday holda, siz unga manba pod'zidan trafikni qabul qilishiga aniq ruxsat berishingiz kerak. Agar pod hech qanday siyosat bilan tanlanmagan bo'lsa, u uchun barcha kirish trafigi sukut bo'yicha ruxsat etiladi.

Quyida Davlat yoki fuqaroligi yoʻq.

Jurnallar

Kubernetes tarmoq siyosati trafikni qayd qila olmaydi. Bu siyosatning maqsadga muvofiq ishlayotganligini aniqlashni qiyinlashtiradi va xavfsizlik tahlilini ancha murakkablashtiradi.

Tashqi xizmatlarga trafikni nazorat qilish

Kubernetes tarmoq siyosatlari chiqish bo'limlarida to'liq malakali domen nomini (DNS) ko'rsatishga ruxsat bermaydi. Bu fakt qat'iy IP-manzilga ega bo'lmagan tashqi yo'nalishlarga (masalan, aws.com) trafikni cheklashga urinishda sezilarli noqulayliklarga olib keladi.

Siyosat tekshiruvi

Xavfsizlik devorlari sizni ogohlantiradi yoki hatto noto'g'ri siyosatni qabul qilishni rad etadi. Kubernetes ham ba'zi tekshiruvlarni amalga oshiradi. Kubernetes kubectl orqali tarmoq siyosatini o'rnatishda uni noto'g'ri deb e'lon qilishi va uni qabul qilishdan bosh tortishi mumkin. Boshqa hollarda, Kubernetes siyosatni oladi va uni etishmayotgan tafsilotlar bilan to'ldiradi. Ularni buyruq yordamida ko'rish mumkin:

kubernetes get networkpolicy <policy-name> -o yaml

Shuni yodda tutingki, Kubernetes tekshirish tizimi xato emas va ba'zi turdagi xatolarni o'tkazib yuborishi mumkin.

Ijroiya

Kubernetes tarmoq siyosatini o'zi amalga oshirmaydi, balki faqat konteyner tarmog'i interfeysi (CNI) deb nomlangan asosiy tizimga nazorat yukini topshiradigan API shlyuzidir. Kubernetes klasterida tegishli CNI-ni tayinlamasdan siyosatlarni o'rnatish, xavfsizlik devoriga o'rnatmasdan xavfsizlik devorini boshqarish serverida siyosat yaratish bilan bir xil. Sizda munosib CNI yoki Kubernetes platformalarida bulutda joylashtirilganligiga ishonch hosil qilish sizga bog'liq. (siz provayderlar ro'yxatini ko'rishingiz mumkin shu yerda - taxminan. trans.), siz uchun CNI o'rnatadigan tarmoq siyosatlarini yoqing.

E'tibor bering, agar siz tarmoq siyosatini tegishli yordamchi CNIsiz o'rnatsangiz, Kubernetes sizni ogohlantirmaydi.

Davlatmi yoki fuqaroligi yoʻqmi?

Men duch kelgan barcha Kubernetes CNIs holatlari mavjud (masalan, Calico Linux conntrack-dan foydalanadi). Bu podka qayta o'rnatmasdan turib, ishga tushirilgan TCP ulanishi bo'yicha javoblarni olish imkonini beradi. Biroq, men davlat mavjudligini kafolatlaydigan Kubernetes standartidan xabardor emasman.

Kengaytirilgan xavfsizlik siyosatini boshqarish

Kubernetes-da xavfsizlik siyosatining bajarilishini yaxshilashning ba'zi usullari:

Service Mesh arxitektura namunasi xizmat darajasida batafsil telemetriya va transport nazoratini ta'minlash uchun yonbosh konteynerlaridan foydalanadi. Misol tariqasida olishimiz mumkin Istio.
Ba'zi CNI sotuvchilari o'zlarining vositalarini Kubernetes tarmoq siyosatlaridan tashqariga chiqish uchun kengaytirdilar.
Tufin Orca Kubernetes tarmoq siyosatlarining ko'rinishi va avtomatlashtirilishini ta'minlaydi.

Tufin Orca paketi Kubernetes tarmoq siyosatlarini boshqaradi (va yuqoridagi skrinshotlarning manbai).

qo'shimcha ma'lumot

xulosa

Kubernetes tarmoq siyosati klasterlarni segmentlash uchun yaxshi vositalar to'plamini taklif qiladi, ammo ular intuitiv emas va juda ko'p nozikliklarga ega. Ushbu murakkablik tufayli, ko'plab mavjud klaster siyosatlari noto'g'ri ekanligiga ishonaman. Ushbu muammoning mumkin bo'lgan yechimlari siyosat ta'riflarini avtomatlashtirish yoki boshqa segmentatsiya vositalaridan foydalanishni o'z ichiga oladi.

Umid qilamanki, ushbu qo'llanma ba'zi savollarni hal qilishga va duch keladigan muammolarni hal qilishga yordam beradi.

Tarjimondan PS

Shuningdek, bizning blogimizda o'qing:

"Istio bilan mikroservislarga qaytish": 1-qism (asosiy xususiyatlar bilan tanishish), 2-qism (marshrutlash, harakatni boshqarish), 3-qism (xavfsizlik);
"Kubernetesda tarmoqqa ulanish bo'yicha tasvirlangan qo'llanma": 1 va 2-qismlar (tarmoq modeli, qatlamli tarmoqlar), 3-qism (xizmatlar va trafikni qayta ishlash);
«Xavfsizlikka sezgir muhitlarda Docker va Kubernetes";
«9 Kubernetes xavfsizlikning eng yaxshi amaliyoti";
«Kubernetes xakerining qurboni bo'lmaslikning 11 usuli".

Manba: www.habr.com

Xavfsizlik mutaxassislari uchun Kubernetes tarmoq siyosatiga kirish