Kubernetesi võrgupoliitikate sissejuhatus turbespetsialistidele

Märkus tõlke kohta.: Artikli autor Reuven Harrison omab üle 20 aasta tarkvaraarenduse kogemust ning on praegu Tufin'i tehniline direktor ja kaasasutaja, kes loob turvapoliitikate haldamise lahendusi. Kuigi ta peab Kubernetes'e võrgu poliitikaid piisavalt võimsaks, et neist saaks kasutada võrgu segmenteerimist klasteris, arvab ta siiski, et need ei ole praktikas nii lihtsad rakendada. See ulatuslik materjal on mõeldud spetsialistide teadlikkuse tõstmiseks ning nende abistamiseks vajalike konfiguratsioonide loomisel.

Tänapäeval valivad järjest rohkem ettevõtteid Kubernetes'e oma rakenduste käivitamiseks. Huvi selle tarkvara vastu on nii kõrge, et mõned nimetavad Kubernetes'e „uueks operatsioonisüsteemiks andmekeskustes“. Aja jooksul hakatakse Kubernetes'e (või k8s) pidama äri kriitiliselt oluliseks osaks, mis nõuab küpsete äri protsesside korraldamist, sealhulgas võrgu turvalisuse tagamist.

Küberturbe spetsialistidele, kes seisavad silmitsi Kubernetes'e kasutamisega, võib tõeliseks üllatuseks olla selle platvormi vaikimisi poliitika: lubada kõike.

See juhend aitab mõista võrgu poliitikate sisemist ülesehitust ja selles eristumist tavaliste tulemüüride reeglitest. Räägitakse ka mõnest takistustest ning antakse soovitusi, mis aitavad kaitsta rakendusi Kubernetes'es.

Kubernetes'e võrgu poliitikad

Kubernetes'e võrgu poliitikate mehhanism võimaldab hallata rakenduste vahelisi suhteid võrgu tasandil (kolmas tase OSI mudelis). Võrgu poliitikad on ilma mõnede kaasaegsete tulemüüride edasijõudnud omadusteta, nagu seitsmenda taseme OSI kontroll ja ohu tuvastamine, kuid need tagavad põhilise võrgu turvalisuse taseme, mis on hea alguspunkt.

Võrgu poliitikad kontrollivad suhtlemist pod'ide vahel

Kubernetesis jaotatakse töökoormused pod'ide vahel, mis koosnevad ühest või mitmest ühiselt rakendatud konteinerist. Kubernetes määrab igale pod’ile IP-aadressi, mis on teiste pod'ide jaoks ligipääsetav. Kubernetes' võrgupoliitikad määravad juurdepääsuõigused pod'ide rühmadele sarnaselt sellele, kuidas pilveteenused kasutavad turberühmi virtuaalmasinatele juurdepääsu haldamiseks.

Võrgupoliitikate määratlemine

Nagu kõik teised Kubernetes'i ressurssidest, on võrgupoliitikad määratletud YAML keeles. Allolevas näites avatakse rakendusele balance juurdepääs 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

(Märkus tõlke kohta.: see ekraanipilt, nagu kõik järgnevad sarnased, on loodud mitte Kubernetes'i originaalitootmisvahendite abil, vaid Tufin Orca tööriista kaudu, mille arendust toetab originaali artikli autor ja mis mainitakse materjali lõpus.

Oma võrgupoliitika määratlemiseks on vajalikud põhiteadmised YAML-ist. See keel põhineb sissetõmbeindentatsioonil (mida määravad tühikud, mitte tabulaatorid). Indentatsiooniga element kuulub kõige lähemale indentatsiooniga elemendile, mis on selle kohal. Uus loendi element algab sidekriipsuga, kõik teised elemendid näevad välja võtme-väärtuse paar.

YAML-is poliitika määratlemise järel kasutage kubectl, et luua see klastris:

kubectl create -f policy.yaml

Võrgupoliitika spetsifikatsioon

Kubernetes'i võrgupoliitika spetsifikatsioon sisaldab nelja elementi:

1. podSelector: määratleb pod'id, mida see poliitika mõjutab (eesmärgid) — kohustuslik;
2. policyTypes: näitab, milliseid poliitikate tüüpe see sisaldab: ingress ja/või egress — valikuline, kuid soovitan seda kõigil juhtudel selgelt välja tuua;
3. ingress: määratleb lubatud sisenemine sihtpod'idesse — valikuline;
4. egress: määratleb lubatud väljuv liiklus sihtpod'idest — valikuline.

Näide, mis on saadud Kubernetes'i saidilt (ma vahetasin role . Tundub, et app), näitab, kuidas kasutatakse kõiki nelja elementi:

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

Pange tähele, et kõiki nelja elementi ei pea lisama. Kohustuslik on ainult podSelector, ülejäänud parameetreid saab kasutada soovi korral.

Kui jätta välja policyTypes, tõlgendatakse poliitikat järgmiselt:

• Vaikimisi eeldatakse, et see määratleb ingress-osa. Kui poliitikas ei ole selgeid juhiseid selle kohta, peab süsteem seda tulu keelama.
• Egress-osa käitumine määratakse vastava egress-parameetri olemasolu või puudumise järgi.

Vigade vältimiseks soovitan alati selgelt määrata policyTypes.

Ülaltoodud loogika kohaselt, juhul kui parameetrid ingress ja/or egress on välja jäetud, keelab poliitika kogu liikluse (vt "Puhastamise reegel" allpool).

Vaikimisi poliitika on lubada

Kui poliitikat ei ole määratud, lubab Kubernetes vaikimisi kogu liikluse. Kõik pod’id saavad omavahel vabalt teavet vahetada. Turvalisuse seisukohalt võib see tunduda loogikaväline, kuid pidage meeles, et Kubernetes loodi algselt arendajate poolt rakenduste suhtlemise võimaldamiseks. Võrgupoliitikad lisati hiljem.

Nimi

Nimi (Namespaces) on Kubernetes'i koostöö mehhanism. Neid kasutatakse loogiliste keskkondade üksteisest eristamiseks, samas on andmevahetus nimede vahel vaikimisi lubatud.

Nagu enamik Kubernetes'i komponente, elavad võrgu poliitikad teatud nimes. Plokis metadata võib määrata, kellele poliitika kuulub:

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

Kui nimes ei ole metaandmetes selgelt määratud, kasutab süsteem kubectlis määratud namespace'i (vaikimisi namespace=default):

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

Soovitan selgelt määrata namespace, kui te ei kirjuta poliitikat, mis on mõeldud kohe mitme nimeala jaoks.

Põhi element podSelector poliitikas valitakse pod'id selle nimeala seest, kuhu poliitika kuulub (tal ei ole juurdepääsu pod'idele teistest nimealadest).

Sarnaselt podSelector'itele ingress ja egress plokkides võivad valida pod'e ainult oma nimealast, kui te neid ei ühenda namespaceSelector selle kohta räägitakse peatükis 'Filtreerimine nimealade ja pod'ide järgi'.

Poliitika nimereeglid

Poliitika nimed on unikaalsed ühe nimeala raames. Ühes nimealas ei saa olla kahte sama nimega poliitikat, kuid eri nimealade vahel võivad olla poliitikad sama nimega. See on mugav, kui soovite sama poliitikat mitmetes nimealades uuesti rakendada.

Mulle meeldib eriti üks nimede määramise viis. See seisneb selles, et kombineerida nimeala nimi sihtpod'idega. Näiteks:

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

Märgid

Kubernetes objektidele, nagu pod'id ja nimealad, saab kinnitada kohandatud märgid. Märgid (labels — etiketid) on sarnased pilvemärkmetele. Kubernetes võrgupoliitikad kasutavad märke valiku tegemiseks pod'ide, millele neid rakendatakse:

podSelector:
  matchLabels:
    role: db

… või nimealasid, millele neid rakendatakse. Selles näites valitakse kõik pod'id nimeala, millel on vastavad märgid:

namespaceSelector:
  matchLabels:
    project: myproject

Üks ettevaatusabinõu: kui kasutate namespaceSelector , veenduge, et valitud nimealad sisaldavad soovitud märki. Pidage meeles, et sisseehitatud nimealad, nagu Seejärel käivitame exec käsu ja ootame 5000 sekundit, et jätkata jälgimist: ja kubectl -n kube-system edit cm kubelet-config-1.16, ei sisalda vaikimisi märke.

Nimele saab lisada märgi järgmiselt:

kubectl label namespace default namespace=default

Sel juhul peab nimeala jaotises metadata viitama tegelikule nimeala nimetusele, mitte märgile:

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

Allikas ja adressaat

Firewall'i poliitikad koosnevad reeglitest, millel on allikad ja sihtkohad. Kubernetes'e võrgupoliitikad määratletakse eesmärgi jaoks - pod’ide kogum, millele need kehtivad, ja seejärel kehtestatakse reeglid sissetuleva (ingress) ja/või väljamineva (egress) liikluse jaoks. Meie näites on poliitika eesmärgiks kõik pod'id kubernetes'e nimede vahel. Seejärel käivitame exec käsu ja ootame 5000 sekundit, et jätkata jälgimist: märgiga, millel on võti app ja väärtusega . Teenuse võrgud lahendavad sarnaseid probleeme tavaliselt mTLS-i kaudu: sertifikaadid on antud juhul olulise identifikaatorina.:

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

Alam ingress selles poliitikas avab sissetuleva liikluse sihtpod'idele. Teisisõnu, ingress on allikas ning siht on sobiv adressaat. Sarnaselt on egress adressaat ja siht tema allikas.

See on ekvivalent kahe firewall'i reegli jaoks: Ingress → Eesmärk; Eesmärk → Egress.

Egress ja DNS (tähtis!)

Väljamineva liikluse piiramisel, pöörake erilist tähelepanu DNS-ile — Kubernetes kasutab seda teenust teenuste sidumiseks IP-aadressidega. Näiteks järgmine poliitika ei tööta, kuna te ei ole rakendusele lubanud balance suhelda DNS-iga:

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

Seda saab parandada, avades juurdepääsu DNS-teenusele:

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

Viimane element to — tühi, ja seega valib see kaudselt kõik pod'id kõigis nimede vahel, võimaldades balance saata DNS-päringud vastavale Kubernetes teenusele (see töötab tavaliselt nimede vahel) kubectl -n kube-system edit cm kubelet-config-1.16).

See lähenemine toimib, however it on liiga lubav ja ebaturvaline, kuna see võimaldab suunata DNS-päringud klastrist väljapoole.

Seda saab paranda kolme järjestikuse sammuga.

1. Lubage DNS-päringud ainult sees klastri, lisades 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. Lubage DNS-päringute tegemiseks ainult nimetuste ruumis kubectl -n kube-system edit cm kubelet-config-1.16.

Selleks tuleb lisada silt nimetuste ruumi kubectl -n kube-system edit cm kubelet-config-1.16: kubectl label namespace kube-system namespace=kube-system — ja määrata see poliitika kaudu 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. Paranoikud võivad minna veelgi kaugemale ja piirata DNS-päringute tegemist kindla DNS-teenusega kubectl -n kube-system edit cm kubelet-config-1.16. Jaotises "Filtreeri nimetuste ruumide ja podide järgi" räägitakse, kuidas seda saavutada.

Teine variant on lubada DNS nimetuste ruumi tasemel. Sel juhul ei pea seda avama iga teenuse jaoks:

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

Tühi podSelector valib kõik pod'id nimetuste ruumis.

Esimene vastavus ja reeglite järjekord

Tavapärastel tulemüüridel määratakse paketi suhtes tegevus ("Luba" või "Keela") esimesele reeglile, millele see vastab. Kuberneteses pole poliitikate järjekorral mingit tähendust.

Vaikimisi, kui poliitikaid pole määratud, on suhtlemine pod'ide vahel lubatud ja nad saavad vabalt teavet vahetada. Niipea, kui hakkate poliitikaid formuleerima, muutub iga pod, mida mõjutab vähemalt üks neist, eraldatuks vastavalt kõigi juurde valitud poliitikate disjunktsioonile (loogiline V). Pod'id, mis ei ole ühegi poliitikaga seotud, jäävad avatuks.

Sarnast käitumist saab muuta puhastusreegli abil.

Puhastusreegel ("Keela")

Tulemüüride poliitikad keelavad tavaliselt kõik selgelt mitte lubatud liikluse.

Kuberneteses ei ole "keela" tegevust, kuid sarnase efekti saab saavutada tavapärase (lubava) poliitika kaudu, valides tühja pod'ide allika grupi (ingress):

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

See kasutuspoliitika valib kõik pod'id nimesse ja jätab ingress'i määratlemata, keelates kogu sissetuleva liikluse.

Sarnasel viisil on võimalik piirata kogu väljuvat liiklust nimestikus:

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

Pange tähele, et kõik täiendavad poliitikad, mis lubavad liiklust pod'idele nimestikus, saavad selle reegli üle prioriteedi (sarnane lubava reegli lisamisega keelu reegli ette tulemüüris).

Luba kõik (Any-Any-Any-Allow)

Selleks, et luua "Luba kõik" poliitika, on vaja täiendavalt lisada ülaltoodud keelu poliitikale tühi element ingress:

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

See avab juurdepääsu kõikidest pod'idest kõigis nimestikes (ja kõikidest IP-dest) igale pod'ile nimestikus . Selline käitumine on vaikimisi lubatud, seega ei pea seda tavaliselt täiendavalt määratlema. Siiski võib mõnikord osutuda vajalikuks mõne spetsiifilise loa ajutine keelamine probleemi diagnostika jaoks. Seejärel käivitame exec käsu ja ootame 5000 sekundit, et jätkata jälgimist:Reeglit saab kitsendada ja lubada juurdepääs ainult

mõningatele määratud pod'idele app:balance () nimestikusapiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all-to-balance namespace: default spec: podSelector: matchLabels: app: balance ingress: - {} policyTypes: - Ingress Seejärel käivitame exec käsu ja ootame 5000 sekundit, et jätkata jälgimist::

Järgmine poliitika lubab kogu sissetuleva (ingress) ja väljuva (egress) liikluse, sealhulgas juurdepääsu igale IP-le klastrist väljas:

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

Mitme poliitika ühendamine

Poliitikad ühendatakse loogilise VÕI abil kolmel tasemel; iga pod'i loakombinatsioon määratakse kõigi poliitikate düsjunksiooni põhjal, mis sellele mõjuvad:

1. Väli

saab määrata kolme tüübi elemente (kõik need on kombineeritud VÕI abil): from ja to — valib nimesse tervikuna;

• namespaceSelector — valib pod'id;
• podSelector ipBlock
• — valib alamvõrgu. Kuid elementide (isegi sama) arv alampunktides

ei ole piiratud. Kõik need ühendatakse loogilise VÕI abil. from/to piiramatu. Kõik need ühendatakse loogilise VÕI-operatsiooniga.

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. Jagamise poliitika sees ingress võib sisaldada mitmeid elemente from (kookonduvad loogilise VÕI abil). Samamoodi võib jagamise osa egress ka sisaldada mitmeid elemente to (samuti kookonduvad disjunktsiooniga):

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. Erinevaid poliitikaid ühendatakse samuti loogilise VÕI abil

Kuid nende ühendamisel on üks piirang, millele mainis Chris Cooney: Kubernetes võib poliitikad kombineerida ainult erinevatega policyTypes (Ingress või Väljaminev). Poliitikad, mis määratlevad sisendi (või väljundi), kirjutavad üksteist üle.

Ruumi vahel

Vaikimisi on teabe vahetamine ruumide vahel lubatud. Seda saab muuta piirava poliitikaga, mis piirab väljaminevat ja/või sisenevat liiklust ruumi (vt 'Puhastamise reegel' eespool).

Piirates juurdepääsu ruumile (vt 'Puhastamise reegel' eespool), saate teha erandeid piiravas poliitikas, lubades ühendusi kindlast ruumist kaudu 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

Tulemuseks on, et kõik pod'id ruumis Seejärel käivitame exec käsu ja ootame 5000 sekundit, et jätkata jälgimist: saavad juurdepääsu pod'idele postgres nimede ruumis database. Aga mis siis, kui soovite avada juurdepääsu postgres ainult konkreetsetele pod'idele ruumis Seejärel käivitame exec käsu ja ootame 5000 sekundit, et jätkata jälgimist:?

Filtreerimine ruumide ja pod'ide järgi

Kubernetes versioon 1.11 ja ühe rohkem võimaldab operaatorite kombineerimist namespaceSelector ja podSelector loogilise JA abil. See näeb välja järgmine:

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

Miks see tõlgendatakse kui JA, mitte tavalise VÕI-ga?

Pange tähele, et podSelector ei alga sidekriipsuga. YAML-is tähendab see, et podSelector ja selle ees namespaceSelector kuuluvad sama loendi elemendile. Seega nad kookonduvad loogilise JA abil.

Sidekriipsu lisamine ette podSelector toob viib uue nimekirja elemendi tekkimiseni, mis kombineeritakse eelnevaga namespaceSelector loogilise VÕI abil.

Kuidas valida pod’e kindla sildiga kõigis nimespettides, sisestage tühi 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

Mitmed sildid kombineeritakse ja.

Mitme objekti (hostide, võrkude, rühmade) tulemüürireeglid kombineeritakse loogilise VÕI abil. Järgmine reegel kehtib, kui paketi allikas vastab Host_1 VÕI Host_2:

| Allikas | Sihtkoht | Teenus | Tegevus |
| ----------------------------------------|
| Host_1 | Subnet_A    | HTTPS   | Luba  |
| Host_2 |             |         |        |
| ----------------------------------------|

Seevastu Kuberneteses kombineeritakse erinevad sildid podSelector või namespaceSelector loogilise ja abil. Näiteks järgnev reegel valib pod’e, millel on mõlemad sildid, role=db ma saan kasutada version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

Sama loogika kehtib kõigi operaatorite tüüpide kohta: poliitika sihiselektorid, pod’i selektorid ja nimespatsi selektorid.

Alamsuunad ja IP-aadressid (IPBlocks)

Võrgusegmentimiseks kasutavad tulemüürid VLAN-i, IP-aadresse ja alamsuundi.

Kuberneteses määratakse pod’idele IP-aadressid automaatselt ja need võivad sageli muutuda, seega kasutatakse võrgu poliitikates pod’ide ja nimespatside valimiseks silte.

Alamsuunad (ipBlocks) kasutatakse sisse- (ingress) või väljaminevate (egress) välistooted (North-South) ühenduste haldamiseks. Näiteks avab see poliitika kõikidele pod’idele nimespatsis Seejärel käivitame exec käsu ja ootame 5000 sekundit, et jätkata jälgimist: juurdepääsu Google'i DNS teenusele:

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

Tühi pod’i selektor näitab selles näites "valida kõik pod’id nimespatsis".

See poliitika avab juurdepääsu ainult 8.8.8.8; juurdepääs igale teisele IP-le on keelatud. Niisiis, olete sisuliselt DNS teenusele Kubernetes blokeerinud. Kui soovite seda siiski avada, märkige see selgelt.

Tavaliselt ipBlocks ja podSelectors on vastastikku välistavad, kuna pod’ide sisemised IP-aadressid ei ole ipBlocks. Märkides pod’ide sisemised IP-aadressid, te ühendate nende aadressidega pod’ide vahel. Praktikas ei tea te, millist IP-aadressi kasutada, seetõttu ei tohiks neid pod’ide valimiseks kasutada.

Vastupidise näitena hõlmab järgmine poliitika kõiki IP-sid ja seega lubab juurdepääsu kõikidele muudele pod’idele:

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

Võite lubada juurdepääsu ainult välistele IP-dele, jättes välja pod’ide sise-IP-aadressid. Näiteks kui teie pod’i alamvõrk on 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

Pordid ja protokollid

Tavaliselt kuulavad pod’id ühte porti. See tähendab, et porta numbreid ei pea poliitikates lihtsalt märkima ja kõik võib jätta eelvaadeks. Kuid poliitikaid on soovitatav teha võimalikult piiravaks, seetõttu on mõnel juhul siiski võimalik porte märkida:

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

Pange tähele, et valija ports kehtib kõikidele elementidele plokis to või from, milles see asub. Erinevate portide määramiseks erinevate elementide kogumite jaoks jagage ingress või egress mitmete alamjaotuste vahel, kus to või from ja kirjeldage igas oma porte:

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

Portide vaikimisi töö:

• Kui te jätate portide määratlemise täielikult välja (ports), tähendab see kõiki protokolle ja kõiki porte;
• Kui te jätate protokolli määratlemise välja (protocol), tähendab see TCP;
• Kui te jätate porta määratlemise välja (port), tähendab see kõiki porte.

Parim praktika: ärge toetuge vaikimisi väärtustele, määrake see, mida vajate, selgelt.

Pange tähele, et tuleb kasutada pod'ide porte, mitte teenuste porte (selle kohta rohkem järgmises lõigus).

Kas poliitikad on määratud pod'idele või teenustele?

Tavaliselt suhtlevad Kubernetes’e pod'id omavahel teenuse kaudu — virtuaalne koormuse jagaja, mis suunab liikluse pod'ide juurde, mis teenust rakendavad. Võib arvata, et võrgupoliitikad kontrollivad juurdepääsu teenustele, kuid see ei vasta tõele. Kubernetes’e võrgupoliitikad töötavad pod'ide portidega, mitte teenuste portidega.

Näiteks, kui teenus kuulab 80. porti, kuid suunab liikluse oma pod'ide 8080. porti, tuleb võrgupoliitikas märkida just 8080.

Sarnast mehhanismi tuleb tunnustada mitteoptimaalsena: teenuse sisemise struktuuri muutes (mille portidele pod'id välja kuulavad) tuleb samas uuendada ka võrgupoliitikaid.

Uus arhitektuuriline lähenemine Service Mesh’i kasutuselevõtuga (näiteks vaata allpool Istio kohta — toimetaja märkus.) lahendab selle probleemi.

Kas on vajalik määrata nii Ingress kui Egress?

Lühike vastus — jah, et pod A saaks pod B-ga suhelda, peab tal olema lubatud luua väljaminev ühendus (selleks tuleb seadistada egress-poliitika) ja pod B-l peab olema võimalus vastu võtta sisenemist (seega on vajalik ingress-poliitika).

Praktikas võib aga toetuda vaikimisi poliitikale, mis lubab ühendusi ühes või mõlemas suunas.

Kui mõni pod-allikas valitakse ühe või mitme egress-poliitika poolt, siis tema suhtes kehtivad piirangud määratakse nende disjunktiooniga. Sellisel juhul tuleb selgelt lubada ühendust pod'-iga-sihtpunkt. Kui pod'i ei ole valitud ühegi poliitikaga, on tema väljaminev (egress) liiklus vaikimisi lubatud.

Sarnasel viisil määratakse pod'i-sihtpunkti, mille on valinud ühe või mitme ingress-poliitika, saatus nende disjunktiooniga. Sellisel juhul tuleb selgelt lubada saada liiklust pod'ilt-allikalt. Kui pod'i ei ole valitud ühegi poliitikaga, on kogu sissetulev (ingress) liiklus tema jaoks vaikimisi lubatud.

Vaata punkti "Stateful või Stateless" allpool.

Logid

Kubernetes’e võrgupoliitikad ei oska logida liiklust. See muudab keeruliseks kindlaks teha, kas poliitika töötab korrektselt, ja raskendab oluliselt turvavaldkonna analüüsi.

Kontroll liikluse üle väliste teenuste suunas.

Kubernetesi võrgupoliitikad ei võimalda määrata täielikku domeeninime (DNS) egressi sektsioonides. See tekitab märkimisväärset ebamugavust, kui üritatakse piirata liiklust välistesse sihtkohtadesse, mis ei oma staatilist IP-aadressi (nt aws.com).

Politika kontrollimine

Tulekahjusüsteemid teavitavad teid või keelduda isegi vale poliitika kinnitamist. Kubernetes viib samuti läbi teatud valideerimise. Kui määrate võrgupoliitika läbi kubectl, võib Kubernetes väita, et see on vale ja keelduda selle aktsepteerimisest. Teistes olukordades aktsepteerib Kubernetes poliitikat ja täiendab puuduvate detailidega. Need on nähtavad järgmisel käsklusel:

kubernetes get networkpolicy  -o yaml

Pange tähele, et Kubernetes kontrollimisseade ei ole infallible ja võib mõningaid tüüpe vigu mööda lasta.

Teostus

Kubernetes ei teosta võrgupoliitikaid iseseisvalt, vaid on lihtsalt API-lüli, mis asetab kontrollimise koorma alumisele süsteemile, mida nimetatakse Container Networking Interface (CNI). Politike määramine Kubernetes klastris ilma vastava CNI määramata on sarnane politikumireeglite loomisele tulekahjusüsteemi haldussüsteemis nende hilisema seadistamise puudumisega. Te peate ise veenduma, et teil on piisav CNI või, kui tegemist on pilves baseeruva Kubernetes platvormiga, (teenusepakkujate nimekirjaga saab tutvuda siin — tõlkija märkus), rakendama võrgupoliitikaid, mis seadistavad CNI teie jaoks.

Pange tähele, et Kubernetes ei teavita teid, kui määrate võrgupoliitika ilma vastava abistava CNI-ta.

Stateful või Stateless?

Kõik Kubernetes CNI-d, millega olen kokku puutunud, säilitavad olekut (näiteks Calico kasutab Linuxi conntrack'i). See võimaldab pod'il saada vastuseid algatatud TCP-ühendusele ilma selle uuesti loomise vajaduseta. Siiski ei ole mulle teada, et eksisteeriks Kubernetes'e standard, mis garantiib oleku säilitamise (statefulness).

Edasijõudnud turvapostustamise haldamine

Siin on mõned viisid, kuidas tõsta turvapostustamise täitmise efektiivsust Kubernetes'is:

1. Teenusevõrgu arhitektuurimuster kasutab sidecar konteinerite abil üksikasjalikku telemeetriat ja liikluse juhtimist teenuste tasandil. Näitena võib tuua Istio.
2. Mõned CNI teenusepakkujad on täiendanud oma tööriistu, et need ületaksid Kubernetes'i võrgupoliitikat.
3. Tufin Orca tagab Kubernetes'i võrgupoliitikate läbipaistvuse ja automatiseerimise.

Tufin Orca paketiga hallatakse Kubernetes'i võrgupoliitikaid (ja see teenib allikana ülaltoodud ekraanipilte).

Lisainformatsioon

• Näited võrgupoliitikatest, mille on koostanud Ahmet Alp Balkan GKE-st;
• Kubernetes'i ametliku veebisaidi dokumentatsioon;
• Kubernetes'i võrgu mudeli juhend;
• Skript võrgupoliitikate kontrollimiseks.

Kokkuvõte

Kubernetes'i võrgupoliitikad pakuvad korralikku tööriistakomplekti klastrite segmentimiseks, kuid need on intuitiivselt mitte arusaadavad ja sisaldavad palju nüansse. Arvan, et nende keerukuse tõttu paljudes olemasolevates klastrites on vigu. Probleemi lahenduste hulka kuulub poliitikate määratlemise automatiseerimine või muude segmentimisvahendite rakendamine.

Loodan, et see juhend aitab selgitada mõningaid küsimusi ja lahendada probleeme, millega võite silmitsi seista.

P.S. tõlkijalt

Lugege ka meie blogist:

• "Tagasi mikroteenustele koos Istio": osa 1 (tutvumine põhifunktsioonidega), osa 2 (marsruutimine, liikluse haldamine), osa 3 (turvalisus);
• «Kubernetese võrgu ülesehituse illustreeritud juhend»: osa 1 ja 2 (võrgu mudel, ülekandevõrgud), osa 3 (teenused ja liikluse käsitlemine);
• «Docker ja Kubernetes turvalisust nõudvates keskkondades»;
• «9 parimat praktikat Kubernetes'e turvalisuse tagamiseks»;
• «11 viisi (mitte) saada Kubernetes'i häkkimise ohvriks».

Allikas: habr.com