„Kubernetes“ tinklo politikos įvadas saugos specialistams

Pastaba. vert.: Straipsnio autorius Reuvenas Harrisonas turi daugiau nei 20 metų programinės įrangos kūrimo patirtį, o šiandien yra saugumo politikos valdymo sprendimus kuriančios kompanijos Tufin CTO ir vienas iš įkūrėjų. Nors jis mano, kad „Kubernetes“ tinklo politika yra gana galingas įrankis tinklo segmentavimui klasteryje, jis taip pat mano, kad praktiškai jas įgyvendinti nėra taip paprasta. Ši medžiaga (gana didelė) skirta pagerinti specialistų supratimą šiuo klausimu ir padėti jiems susikurti reikiamas konfigūracijas.

Šiandien daugelis įmonių vis dažniau renkasi Kubernetes savo programoms paleisti. Susidomėjimas šia programine įranga yra toks didelis, kad kai kurie „Kubernetes“ vadina „nauja duomenų centro operacine sistema“. Palaipsniui „Kubernetes“ (arba k8s) pradedama suvokti kaip svarbi verslo dalis, kuriai reikia organizuoti brandžius verslo procesus, įskaitant tinklo saugumą.

Saugumo specialistams, kurie yra suglumę dėl darbo su „Kubernetes“, tikras atradimas gali būti numatytoji platformos politika: leisti viską.

Šis vadovas padės suprasti vidinę tinklo politikos struktūrą; suprasti, kuo jos skiriasi nuo įprastų užkardų taisyklių. Ji taip pat apims kai kuriuos spąstus ir pateiks rekomendacijas, kaip apsaugoti programas „Kubernetes“.

„Kubernetes“ tinklo politika

„Kubernetes“ tinklo politikos mechanizmas leidžia valdyti platformoje įdiegtų programų sąveiką tinklo lygmenyje (trečiasis OSI modelyje). Tinklo politikoje trūksta kai kurių pažangių šiuolaikinių ugniasienių funkcijų, tokių kaip OSI Layer 7 vykdymas ir grėsmių aptikimas, tačiau jos užtikrina pagrindinį tinklo saugumo lygį, kuris yra geras atspirties taškas.

Tinklo politika kontroliuoja ryšį tarp podų

Darbo krūviai „Kubernetes“ paskirstomi po blokus, kuriuos sudaro vienas ar daugiau kartu įdiegtų konteinerių. „Kubernetes“ kiekvienai grupei priskiria IP adresą, kurį galima pasiekti iš kitų blokų. „Kubernetes“ tinklo strategijos nustato prieigos teises prie blokų grupių taip pat, kaip debesyje esančios saugos grupės naudojamos prieigai prie virtualios mašinos egzempliorių valdyti.

Tinklo politikos apibrėžimas

Kaip ir kiti „Kubernetes“ ištekliai, tinklo politika yra nurodyta YAML. Toliau pateiktame pavyzdyje programa balance prieiga prie 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

(Pastaba. vert.: ši ekrano kopija, kaip ir visos vėlesnės panašios, buvo sukurta ne naudojant vietinius Kubernetes įrankius, o naudojant Tufin Orca įrankį, kurį sukūrė originalaus straipsnio autoriaus įmonė ir kuris paminėtas medžiagos pabaigoje.)

Norėdami apibrėžti savo tinklo politiką, jums reikės pagrindinių YAML žinių. Ši kalba yra pagrįsta įtrauka (nurodoma tarpais, o ne tabuliatoriais). Įtrauktas elementas priklauso artimiausiam virš jo esančiam įtrauktam elementui. Naujas sąrašo elementas prasideda brūkšneliu, visi kiti elementai turi formą rakto vertė.

Aprašę politiką YAML, naudokite kubectlNorėdami sukurti jį klasteryje:

kubectl create -f policy.yaml

Tinklo politikos specifikacija

„Kubernetes“ tinklo politikos specifikaciją sudaro keturi elementai:

1. podSelector: apibrėžia šios politikos paveiktus blokus (tikslus) – būtinas;
2. policyTypes: nurodo, kokios politikos rūšys yra įtrauktos į tai: įėjimas ir (arba) išėjimas – neprivaloma, tačiau visais atvejais rekomenduoju tai aiškiai nurodyti;
3. ingress: apibrėžia leistiną gaunamas srautas į tikslines ankštis – neprivaloma;
4. egress: apibrėžia leistiną išeinantis srautas iš tikslinių rinkinių yra neprivalomas.

Pavyzdys paimtas iš Kubernetes svetainės (pakeičiau role apie app), parodo, kaip naudojami visi keturi elementai:

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

Atkreipkite dėmesį, kad visi keturi elementai nebūtinai turi būti įtraukti. Tai tik privaloma podSelector, pagal pageidavimą galima naudoti kitus parametrus.

Jei praleisite policyTypes, politika bus aiškinama taip:

• Pagal numatytuosius nustatymus daroma prielaida, kad ji apibrėžia įėjimo pusę. Jei politikoje tai aiškiai nenurodyta, sistema darys prielaidą, kad visas srautas yra draudžiamas.
• Elgesys išėjimo pusėje bus nustatomas pagal atitinkamo išėjimo parametro buvimą ar nebuvimą.

Kad nebūtų klaidų, rekomenduoju visada padarykite tai aiškiai policyTypes.

Pagal aukščiau pateiktą logiką, jei parametrai ingress ir (arba) egress praleistas, politika uždraus bet kokį srautą (žr. toliau esančią „Pašalinimo taisyklę“).

Numatytoji politika yra Leisti

Jei politika neapibrėžta, Kubernetes leidžia visą srautą pagal numatytuosius nustatymus. Visos ankštys gali laisvai keistis informacija tarpusavyje. Saugumo požiūriu tai gali atrodyti prieštaringa, tačiau atminkite, kad „Kubernetes“ iš pradžių sukūrė kūrėjai, kad įgalintų programų sąveiką. Tinklo politika buvo pridėta vėliau.

Vardų erdvės

Vardų erdvės yra „Kubernetes“ bendradarbiavimo mechanizmas. Jie skirti atskirti loginę aplinką viena nuo kitos, o ryšys tarp erdvių leidžiamas pagal numatytuosius nustatymus.

Kaip ir dauguma „Kubernetes“ komponentų, tinklo politika yra konkrečioje vardų erdvėje. Bloke metadata galite nurodyti, kuriai erdvei politika priklauso:

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

Jei vardų sritis nėra aiškiai nurodyta metaduomenyse, sistema naudos kubectl nurodytą vardų erdvę (pagal numatytuosius nustatymus namespace=default):

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

Aš rekomenduoju aiškiai nurodykite vardų erdvę, nebent rašote politiką, kuri vienu metu taikoma kelioms vardų erdvėms.

Pagrindinis elementas podSelector politikoje pasirinks blokus iš vardų erdvės, kuriai priklauso politika (ji uždrausta prieiga prie grupės iš kitos vardų srities).

Panašiai, podSelectors įėjimo ir išėjimo blokuose gali pasirinkti tik ankštis iš savo vardų srities, nebent, žinoma, derinate juos su namespaceSelector (apie tai bus kalbama skyriuje „Filtruoti pagal vardų sritis ir ankštis“).

Politikos įvardijimo taisyklės

Politikos pavadinimai yra unikalūs toje pačioje vardų erdvėje. Toje pačioje erdvėje negali būti dviejų to paties pavadinimo strategijų, tačiau skirtingose ​​erdvėse gali būti strategijos tuo pačiu pavadinimu. Tai naudinga, kai norite pakartotinai taikyti tą pačią politiką keliose erdvėse.

Man ypač patinka vienas iš įvardijimo būdų. Jį sudaro vardų erdvės pavadinimo sujungimas su tikslinėmis grupėmis. Pavyzdžiui:

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

Etiketės

Galite pridėti pasirinktines etiketes prie „Kubernetes“ objektų, pvz., rinkinių ir vardų erdvių. Etiketės (etiketės - žymos) yra debesyje esančių žymų atitikmuo. „Kubernetes“ tinklo strategijose pasirenkamos etiketės ankštyskuriems jie taikomi:

podSelector:
  matchLabels:
    role: db

… arba vardų erdvėskuriems jie taikomi. Šiame pavyzdyje parenkamos visos ankšties vardų erdvėse su atitinkamomis etiketėmis:

namespaceSelector:
  matchLabels:
    project: myproject

Vienas įspėjimas: naudojant namespaceSelector įsitikinkite, kad pasirinktose vardų srityse yra tinkama etiketė. Atminkite, kad įtaisytosios vardų erdvės, pvz default и kube-system, pagal numatytuosius nustatymus juose nėra etikečių.

Galite pridėti etiketę prie tokios vietos:

kubectl label namespace default namespace=default

Tuo pačiu metu vardų sritis skyriuje metadata turėtų nurodyti tikrąjį erdvės pavadinimą, o ne etiketę:

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

Šaltinis ir paskirties vieta

Ugniasienės politiką sudaro taisyklės su šaltiniais ir paskirties vietomis. „Kubernetes“ tinklo taisyklės apibrėžiamos taikiniui – rinkinių, kuriems jos taikomos, rinkiniui, o tada nustatomos įėjimo ir (arba) išėjimo srauto taisyklės. Mūsų pavyzdyje politikos tikslas bus visos vardų erdvės grupės default su etikete su raktu app ir prasmė 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

Poskyris ingress pagal šią politiką atidaro įeinantį srautą į tikslinius blokus. Kitaip tariant, įėjimas yra šaltinis, o tikslas yra atitinkama paskirties vieta. Taip pat išėjimas yra tikslas, o tikslas yra jo šaltinis.

Tai atitinka dvi ugniasienės taisykles: Ingress → Target; Tikslas → Išėjimas.

Išėjimas ir DNS (svarbu!)

Apribojant išeinantį srautą, atkreipkite ypatingą dėmesį į DNS - Kubernetes naudoja šią paslaugą, kad susietų paslaugas su IP adresais. Pavyzdžiui, ši politika neveiks, nes neleidote programos balance pasiekti 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

Galite tai išspręsti atidarę prieigą prie DNS paslaugos:

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

Paskutinis elementas to yra tuščias, todėl netiesiogiai pasirenka visos ankštys visose vardų srityse, leidžiantis balance siųsti DNS užklausas į atitinkamą Kubernetes paslaugą (paprastai veikiančią erdvėje kube-system).

Šis metodas veikia, kad ir kaip būtų pernelyg leistinas ir nesaugus, nes leidžia DNS užklausas nukreipti už klasterio ribų.

Jį galite patobulinti atlikdami tris iš eilės veiksmus.

1. Leisti tik DNS užklausas per sugrupuoti pridedant 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. Leisti DNS užklausas tik vardų erdvėje kube-system.

Norėdami tai padaryti, prie vardų srities turite pridėti etiketę kube-system: kubectl label namespace kube-system namespace=kube-system - ir užsirašykite tai naudodami politiką 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. Paranojiški žmonės gali eiti dar toliau ir apriboti DNS užklausas iki konkrečios DNS paslaugos kube-system. Skyriuje „Filtruoti pagal vardų sritis IR ankštis“ bus paaiškinta, kaip tai pasiekti.

Kita galimybė yra išspręsti DNS vardų erdvės lygiu. Tokiu atveju jo nereikės atidaryti kiekvienai paslaugai:

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

Tuščia podSelector pasirenka visas ankštis vardų srityje.

Pirmosios rungtynės ir taisyklių tvarka

Įprastose ugniasienėse veiksmas (Leisti arba Neleisti) paketui nustatomas pagal pirmą taisyklę, kurią jis tenkina. „Kubernetes“ politikos tvarka neturi reikšmės.

Pagal numatytuosius nustatymus, kai nenustatytos jokios strategijos, ryšiai tarp podų yra leidžiami ir jie gali laisvai keistis informacija. Pradėjus formuoti strategijas, kiekviena grupė, paveikta bent vienos iš jų, tampa izoliuota pagal visų ją pasirinkusių strategijų disjunkciją (loginį ARBA). Pods, kuriam netaikoma jokia politika, lieka atviri.

Šį elgesį galite pakeisti naudodami pašalinimo taisyklę.

Pašalinimo taisyklė („Atmesti“)

Užkardos politika paprastai neleidžia bet kokiam srautui, kuris nėra aiškiai leidžiamas.

„Kubernetes“ veiksmas neneigiamastačiau panašų efektą galima pasiekti naudojant įprastą (leistiną) politiką, pasirinkus tuščią šaltinio rinkinių (įėjimo) grupę:

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

Taikant šią politiką parenkamos visos vardų erdvėje esančios grupės ir įėjimas paliekamas neapibrėžtas, užkertant kelią įeinančiam srautui.

Panašiu būdu galite apriboti visą iš vardų srities išeinantį srautą:

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

Atkreipkite dėmesį, kad bet kokia papildoma politika, leidžianti srautą į grupes vardų srityje, bus viršesnė už šią taisyklę (panašiai kaip pridėti leidimo taisyklę prieš užkardos konfigūracijoje uždraudimo taisyklę).

Leisti viską (Bet-Bet-Bet-Leisti)

Norėdami sukurti strategiją „Leisti viską“, aukščiau pateiktą Neleisti politiką turite papildyti tuščiu elementu ingress:

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

Tai leidžia pasiekti iš visos grupės visose vardų srityse (ir visi IP) į bet kurią vardų srities grupę default. Šis elgesys įjungtas pagal numatytuosius nustatymus, todėl paprastai jo daugiau apibrėžti nereikia. Tačiau kartais gali tekti laikinai išjungti kai kuriuos konkrečius leidimus, kad nustatytumėte problemą.

Taisyklę galima susiaurinti, kad būtų galima pasiekti tik konkretus ankščių rinkinys (app:balance) vardų srityje default:

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

Ši politika leidžia visam įėjimo ir išėjimo srautui, įskaitant prieigą prie bet kurio IP už klasterio ribų:

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

Kelių strategijų derinimas

Politikos derinamos naudojant loginį ARBA trimis lygiais; Kiekvienos grupės leidimai nustatomi atsižvelgiant į visas jai įtakos turinčias politikos nuostatas:

1. Laukuose from и to Galima apibrėžti trijų tipų elementus (visi jie derinami naudojant OR):

• namespaceSelector — pasirenka visą vardų sritį;
• podSelector — parenka ankštis;
• ipBlock – pasirenka potinklį.

Be to, elementų (net identiškų) skaičius poskyriuose from/to neribota. Visi jie bus sujungti loginiu ARBA.

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. Politikos skiltyje ingress gali turėti daug elementų from (sujungtas loginiu ARBA). Panašiai, skyrius egress gali apimti daug elementų to (taip pat kartu su disjunkcija):

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. Skirtingos politikos kryptys taip pat derinamos su loginiu ARBA

Tačiau juos derinant yra vienas apribojimas nurodė Chrisas Cooney: „Kubernetes“ gali derinti tik politiką su skirtingomis policyTypes (Ingress arba Egress). Įėjimą (arba išėjimą) apibrėžiančios strategijos viena kitą perrašys.

Santykis tarp vardų erdvių

Pagal numatytuosius nustatymus dalijimasis informacija tarp vardų erdvių leidžiamas. Tai gali būti pakeista naudojant atmetimo politiką, kuri apribos išeinantį ir (arba) įeinantį srautą į vardų erdvę (žr. aukščiau esančią „Nutraukimo taisyklę“).

Užblokavę prieigą prie vardų erdvės (žr. aukščiau esančią „Ištrinimo taisyklę“), galite padaryti atsisakymo politikos išimtis, leisdami prisijungti iš konkrečios vardų erdvės naudodami 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

Dėl to visos vardų erdvės ankštys default turės prieigą prie ankščių postgres vardų erdvėje database. Bet ką daryti, jei norite atidaryti prieigą prie postgres tik tam tikros ankštys vardų erdvėje default?

Filtruokite pagal vardų sritis ir ankštis

Kubernetes 1.11 ir naujesnė versija leidžia derinti operatorius namespaceSelector и podSelector naudojant loginį AND. Tai atrodo taip:

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

Kodėl tai interpretuojama kaip IR vietoj įprasto ARBA?

Atkreipkite dėmesį, kad podSelector neprasideda brūkšneliu. YAML tai reiškia, kad podSelector ir stovėjo priešais jį namespaceSelector nurodyti tą patį sąrašo elementą. Todėl jie derinami su loginiu AND.

Prieš pridedant brūkšnelį podSelector atsiras naujas sąrašo elementas, kuris bus sujungtas su ankstesniu namespaceSelector naudojant loginį ARBA.

Norėdami pasirinkti ankštis su konkrečia etikete visose vardų srityse, įveskite tuščią 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

Kelios etiketės susivienija su I

Taisyklės ugniasienei su keliais objektais (šeimomis, tinklais, grupėmis) derinamos naudojant loginį ARBA. Ši taisyklė veiks, jei paketo šaltinis sutaps Host_1 ARBA Host_2:

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

Priešingai, „Kubernetes“ įvairios etiketės podSelector arba namespaceSelector yra derinami su loginiu AND. Pavyzdžiui, pagal šią taisyklę bus pasirinktos ankštys, turinčios abi etiketes, role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

Ta pati logika taikoma visų tipų operatoriams: politikos tikslo parinktuvams, podelių parinktuvams ir vardų srities parinktuvams.

Potinkliai ir IP adresai (IPBlocks)

Užkardos tinklui segmentuoti naudoja VLAN, IP adresus ir potinklius.

„Kubernetes“ IP adresai grupėms priskiriami automatiškai ir gali dažnai keistis, todėl etiketės naudojamos tinklo politikoje rinkiniams ir vardų erdvėms pasirinkti.

Potinkliai (ipBlocks) naudojami valdant įeinančius (įėjimo) arba išeinančius (išeinančius) išorinius (šiaurės-pietų) ryšius. Pavyzdžiui, ši politika atidaroma visoms vardų erdvės grupėms default prieiga prie Google DNS paslaugos:

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

Tuščias ankšties parinkiklis šiame pavyzdyje reiškia „pasirinkti visas vardų srities ankštis“.

Ši politika leidžia pasiekti tik 8.8.8.8; prieiga prie bet kokio kito IP yra draudžiama. Taigi iš esmės užblokavote prieigą prie vidinės Kubernetes DNS paslaugos. Jei vis tiek norite jį atidaryti, nurodykite tai aiškiai.

Paprastai ipBlocks и podSelectors yra vienas kitą paneigiantys, nes vidiniai ankšties IP adresai nenaudojami ipBlocks. Nurodant vidinių IP lizdų, jūs iš tikrųjų leisite jungtis į/iš ankšties su šiais adresais. Praktiškai jūs nežinote, kurį IP adresą naudoti, todėl jie neturėtų būti naudojami renkantis ankštis.

Kaip priešingas pavyzdys: ši politika apima visus IP, todėl suteikiama prieiga prie visų kitų blokų:

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

Galite atidaryti prieigą tik prie išorinių IP adresų, išskyrus vidinius podėlių IP adresus. Pavyzdžiui, jei jūsų bloko potinklis yra 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

Prievadai ir protokolai

Paprastai ankštys klauso vieno prievado. Tai reiškia, kad galite tiesiog nenurodyti prievadų numerių strategijose ir palikti viską kaip numatytuosius. Tačiau rekomenduojama politiką nustatyti kiek įmanoma ribojančią, todėl kai kuriais atvejais vis tiek galite nurodyti prievadus:

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

Atkreipkite dėmesį, kad parinkiklis ports taikoma visiems bloko elementams to arba from, kuriame yra. Norėdami nurodyti skirtingus prievadus skirtingiems elementų rinkiniams, padalinkite ingress arba egress į keletą poskyrių su to arba from ir kiekviename registruokite savo prievadus:

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

Numatytasis prievado veikimas:

• Jei visiškai praleisite prievado apibrėžimą (ports), tai reiškia visus protokolus ir visus prievadus;
• Jei praleisite protokolo apibrėžimą (protocol), tai reiškia TCP;
• Jei praleisite prievado apibrėžimą (port), tai reiškia visus prievadus.

Geriausia praktika: nepasikliaukite numatytosiomis reikšmėmis, aiškiai nurodykite, ko jums reikia.

Atkreipkite dėmesį, kad turite naudoti prievadus, o ne aptarnavimo prievadus (daugiau apie tai kitoje pastraipoje).

Ar politika yra apibrėžta ankštims ar paslaugoms?

Paprastai „Kubernetes“ blokai vienas kitą pasiekia naudodami paslaugą – virtualų apkrovos balansavimo priemonę, kuri nukreipia srautą į šią paslaugą įgyvendinančius blokus. Galbūt manote, kad tinklo politika kontroliuoja prieigą prie paslaugų, tačiau taip nėra. „Kubernetes“ tinklo taisyklės veikia „pod“ prievaduose, o ne su aptarnavimo prievadais.

Pavyzdžiui, jei paslauga klauso 80 prievado, bet nukreipia srautą į 8080 prievadą, tinklo politikoje turi būti nurodyta tiksliai 8080.

Toks mechanizmas turėtų būti laikomas neoptimaliu: pasikeitus tarnybos vidinei struktūrai (kurių prievadai klausosi), tinklo strategijas teks atnaujinti.

Naujas architektūrinis požiūris naudojant Service Mesh (pavyzdžiui, žr. apie Istio žemiau – apytikslis vertimas) leidžia susidoroti su šia problema.

Ar reikia registruoti ir Ingress, ir Egress?

Trumpas atsakymas yra taip, kad pod A galėtų susisiekti su pod B, jam turi būti leista sukurti išeinantį ryšį (tam reikia sukonfigūruoti išėjimo politiką), o pod B turi priimti įeinantį ryšį ( tam, atitinkamai, reikia įėjimo politikos). politika).

Tačiau praktiškai galite pasikliauti numatytąja politika, kad būtų galima prisijungti viena arba abiem kryptimis.

Jei koks nors ankštis-šaltinis bus pasirinktas vienas ar keli išėjimas-politikų, jai taikomus apribojimus lems jų disjunkcija. Tokiu atveju turėsite aiškiai leisti prisijungti prie pod -adresatui. Jei grupė nepasirinkta pagal jokią politiką, pagal numatytuosius nustatymus leidžiamas jo išeinantis (išėjimo) srautas.

Panašiai yra ir ankšties likimasadresatas, kurį pasirinko vienas ar daugiau patekimas-politikų, lems jų atskirtis. Tokiu atveju turite aiškiai leisti jam priimti srautą iš šaltinio grupės. Jei grupė nepasirinkta pagal jokią politiką, pagal numatytuosius nustatymus leidžiamas visas jo srautas.

Žr. toliau.

Rąstai

„Kubernetes“ tinklo politika negali registruoti srauto. Dėl to sunku nustatyti, ar politika veikia taip, kaip numatyta, ir labai apsunkina saugumo analizę.

Srauto į išorines paslaugas kontrolė

Kubernetes tinklo politika neleidžia nurodyti visiškai kvalifikuoto domeno vardo (DNS) išėjimo skyriuose. Šis faktas sukelia didelių nepatogumų bandant apriboti srautą į išorines paskirties vietas, kurios neturi fiksuoto IP adreso (pvz., aws.com).

Politikos patikrinimas

Ugniasienės jus įspės arba net atsisakys priimti neteisingą politiką. „Kubernetes“ taip pat atlieka tam tikrą patikrinimą. Nustatydama tinklo politiką per kubectl, Kubernetes gali paskelbti, kad ji neteisinga, ir atsisakyti ją priimti. Kitais atvejais „Kubernetes“ paims politiką ir užpildys trūkstamą informaciją. Juos galima pamatyti naudojant komandą:

kubernetes get networkpolicy <policy-name> -o yaml

Atminkite, kad „Kubernetes“ patvirtinimo sistema nėra neklysta ir gali praleisti kai kurių tipų klaidas.

Vykdymas

„Kubernetes“ pati neįgyvendina tinklo politikos, o yra tik API šliuzai, perduodantys valdymo naštą pagrindinei sistemai, vadinamai „Container Networking Interface“ (CNI). Politikos nustatymas Kubernetes klasteryje nepriskiriant atitinkamo CNI yra tas pats, kaip kurti strategijas ugniasienės valdymo serveryje jų neįdiegus ugniasienėse. Jūs turite įsitikinti, kad turite tinkamą CNI arba, Kubernetes platformų atveju, priglobtą debesyje (galite pamatyti tiekėjų sąrašą čia - apytiksliai vertimas), įgalinkite tinklo politiką, kuri už jus nustatys CNI.

Atminkite, kad „Kubernetes“ neįspės, jei nustatysite tinklo politiką be atitinkamo pagalbinio CNI.

Valstybinis ar be pilietybės?

Visi Kubernetes CNI, su kuriais susidūriau, yra būsenos (pavyzdžiui, Calico naudoja Linux conntrack). Tai leidžia podeliui gauti atsakymus į pradėtą ​​TCP ryšį, jo nereikės atkurti. Tačiau aš nežinau Kubernetes standarto, kuris garantuotų valstybingumą.

Išplėstinis saugos politikos valdymas

Štai keletas būdų, kaip pagerinti saugumo politikos vykdymą Kubernetes:

1. „Service Mesh“ architektūriniame modelyje naudojami šoninių priekabų konteineriai, kad būtų galima teikti išsamią telemetriją ir eismo kontrolę aptarnavimo lygiu. Kaip pavyzdį galime paimti Tas pats.
2. Kai kurie CNI pardavėjai išplėtė savo įrankius, kad neapsiribotų „Kubernetes“ tinklo politika.
3. Tufinas Orka Suteikia Kubernetes tinklo politikos matomumą ir automatizavimą.

„Tufin Orca“ paketas valdo „Kubernetes“ tinklo politiką (ir yra aukščiau pateiktų ekrano kopijų šaltinis).

Papildoma informacija

• Tinklo politikos pavyzdžiai, kuriuos parengė Ahmetas Alp Balkan iš GKE;
• Dokumentai iš oficialios Kubernetes svetainės;
• „Kubernetes“ tinklo modelio vadovas;
• Tinklo politikos tikrinimo scenarijus.

išvada

„Kubernetes“ tinklo strategijos siūlo gerą įrankių rinkinį klasterių segmentavimui, tačiau jie nėra intuityvi ir turi daug subtilybių. Dėl šio sudėtingumo manau, kad daugelis esamų grupių politikos yra klaidingos. Galimi šios problemos sprendimai yra automatizuoti politikos apibrėžimus arba naudoti kitus segmentavimo įrankius.

Tikiuosi, kad šis vadovas padės išsiaiškinti kai kuriuos klausimus ir išspręsti problemas, su kuriomis galite susidurti.

PS iš vertėjo

Taip pat skaitykite mūsų tinklaraštyje:

• "Atgal į mikropaslaugas su Istio": 1 dalis (įvadas į pagrindines savybes), 2 dalis (maršruto parinkimas, eismo kontrolė), 3 dalis (saugumas);
• „Iliustruotas „Kubernetes“ tinklo vadovas“: 1 ir 2 dalys (tinklo modelis, perdangos tinklai), 3 dalis (paslaugos ir srauto apdorojimas);
• «„Docker“ ir „Kubernetes“ saugumui jautriose aplinkose»;
• «9 geriausios Kubernetes saugos praktikos»;
• «11 būdų (ne)tapti Kubernetes įsilaužimo auka".

Šaltinis: www.habr.com