Kubernetes'e võrgupoliitikas tutvumine turvaekspertidele

Märk. tõlge.: Artikli autor Reuven Harrisonil on üle 20 aasta tarkvaraarenduse kogemust ning ta on praegu Tufini tehniline direktor ja kaasasutaja, mis loob turvapoliitikate haldamise lahendusi. Vaadates Kubernetes'e võrgu poliitikaid kui piisavalt võimekat vahendit võrgu segmentimiseks klastris, peab ta samas neid praktikas rakendamiseks keerukateks. Käesolev materjal (päris mahukas) on mõeldud spetsialistide teadlikkuse tõstmiseks selles küsimuses ja aitama neil luua vajalikke konfiguratsioone.

Tänapäeval valivad üha rohkem ettevõtteid Kubernetes'e oma rakenduste käivitamiseks. Huvi selle tarkvara vastu on nii suur, et osa inimesi nimetab Kubernetes'e 'uueks operatsioonisüsteemiks andmekeskustes'. Aja jooksul hakka Kubernetes (või k8s) olema tajutud kui kriitiliselt oluline osa ärist, mis vajab küpsete äri protsesside korraldamist, sealhulgas võrgu turvalisuse tagamist.

Kübergansside spetsialistidele võib Kubernetes'i platvormi vaikimisi poliitika, mis lubab kõike, osutuda tõeliselt avardavaks.

See juhend aitab mõista võrgu poliitikate sisemist toimimist; selgitades, kuidas need erinevad tavaliste tulemüüri reeglitega. Tutvustatakse ka mõningaid lõkse ja antakse soovitusi, mis aitavad kaitsta rakendusi Kubernetes'is.

Kubernetes'i võrgu poliitikad

Kubernetes'i võrgu poliitikate mehhanism võimaldab hallata platvormil tegevuses olevate rakenduste vahelist suhtlemist võrgutasemel (OSi mudeli kolmas tase). Võrgu poliitikad ei paku mõningaid moodsate tulemüüride edasijõudnud funktsioone, nagu seitsmenda OSi tasandi kontroll ja ohu avastamine, kuid need tagavad põhitaseme võrgu turvalisuse, olles hea alguspunkt.

Võrgu poliitikad kontrollivad pod'ide vahelisi sideühendusi.

Kubernetesis jaotatakse koormus pod'ide vahel, mis koosnevad ühest või mitmest konteinerist, mis on koos juurutatud. Kubernetes määrab igale pod'ile IP-aadressi, mis on teiste pod'ide jaoks saadaval. Kubernetes'i võrgu poliitikad määratlevad pääsutingimused pod'ide gruppide jaoks, sarnaselt sellele, kuidas pilves kasutatavad turvagruppide määratakse virtuaalmasinate eksemplaride pääsu haldamiseks.

Võrgu poliitikate määratlemine

Nagu kõik muud Kubernetes'i ressursid, määratakse võrgu poliitikad YAML keeles. Järgnevas näites rakendusele balance antakse 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ärk. tõlge.: see ekraanipilt, nagu ka kõik järgmised sarnased, on loodud mitte Kubernetes'i natiivsete vahenditega, vaid tööriista Tufin Orca abil, mille arendamise taga on ettevõte, kes on originaali autori ning mis mainitakse materjali lõpus.

Oma võrgu poliitika määratlemiseks on vajalik põhiteadmised YAML-ist. See keel põhineb sisu jaotamisel (mille määravad tühikud, mitte tabulaatorid). Idendi tähendusega elemendi alluvus tuleneb lähimast sama taseme elemendist. Uus loendi element algab kriipsuga, kõik teised elemendid on kujul. võti-väärtus.

YAML-is poliitika kirjeldamisel kasutage kubectl, et luua see klusteris:

kubectl create -f policy.yaml

Võrgu poliitika spetsifikatsioon

Kubernetes'i võrgu poliitika spetsifikatsioon hõlmab nelja elementi:

1. podSelector: määratleb pod'id, mida see poliitika mõjutab (objektid) — kohustuslik;
2. policyTypes: näitab, milliseid poliitikate tüüpe see hõlmab: ingress ja/või egress — valikuline, kuid soovitan seda kõigis juhtudel selgelt märgata;
3. ingress: määratleb lubatud sissevoolu liiklus siht-pod'idesse — valikuline;
4. egress: määratleb lubatud väljaminev liiklus siht-pod'ist — valikuline.

Näide, mis on laenatud Kubernetes'i saidilt (ma asendasin role järgnevaga app), näitab, kuidas kasutatakse kõik neli 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õigi nelja elementi kaasamine ei ole kohustuslik. Kohustuslik on ainult podSelector, ülejäänud parameetreid võib kasutada vastavalt soovile.

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

• Eeldatakse, et see määratleb ingress-poole. Kui poliitikas ei ole selgeid juhiseid, loetakse, et kogu liiklus on keelatud.
• Egress-poole käitumist määratakse vastava egress-parameetri olemasolu või puudumisega.

Vigade vältimiseks soovitan alati selgelt näidata policyTypes.

Ülaltoodud loogika kohaselt, kui parameetrid ingress ja/või egress jäetakse välja, keelab poliitika kogu liikluse (vt "Koristamisreeglit" allpool).

Vaikimisi poliitika — lubada

Kui poliitikaid ei ole määratud, Kubernetes lubab vaikimisi kogu liikluse. Kõik pod’id saavad vabalt omavahel teavet jagada. Turvalisuse vaatepunktist võib see tunduda loogikast väljas, kuid pidage meeles, et Kubernetes loodi algselt arendajate poolt rakenduste koostöö tagamiseks. Võrgupoliitikaid lisati hiljem.

Nimekirjad

Nimekirjad (Namespaces) on Kubernetes’i koostöö mehhanism. Need on ette nähtud loogiliste keskkondade üksteisest eristamiseks, samal ajal kui andmevahetus nimekirjade vahel on vaikimisi lubatud.

Nagu enamus Kubernetes’i komponente, elavad võrgupoliitikad teatud nimekirjas. Plokis metadata saab määrata, millisele nimekirjale poliitika kuulub:

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

Kui nimekirja metainformatsioonis ei ole selgelt määratud, kasutab süsteem kubectl’is märgitud nimekirja (vaikimisi namespace=default):

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

Soovitan selgelt määrata nimekirja, kui te ei kirjuta poliitikat, mis on mõeldud kohe mitmele nimede ruumile.

Peamine element podSelector poliitikas valib pod'e sellest nimede ruumist, kuhu poliitika kuulub (tal ei ole juurdepääsu teiste nimede ruumide pod'idele).

Sarnasel moel podSelector'id ingress ja egress plokkides võivad valida pod'e ainult oma nimede ruumist, välja arvatud juhul, kui te ühendate need namespaceSelector'iga (sellest räägitakse jaotises „Filtreerimine nimede ruumide ja pod'ide kaudu“).

Poliitikate nimetamise reeglid

Poliitikate nimed on ühes nimede ruumis ainulaadsed. Kahel poliitikal ei saa olla sama nime ühes ruumis, kuid erinevates ruumides võivad olla poliitikad sama nimega. See on mugav, kui soovite sama poliitikat mitu korda rakendada.

Mulle meeldib eriti üks nimetamisviis. See seisneb nimede ruumi ja sihipäraste pod'ide ühendamises. 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

Sildid

Kubernetesi objektidele, nagu pod-id ja nimed, saab lisada kohandatud silte. Sildid (labels — etiketid) on sarnased päistele pilves. Kubernetesi võrgupoliitikad kasutavad silte valimiseks pod'id, millele need rakendatakse:

podSelector:
  matchLabels:
    role: db

… või nimed, millele need rakendatakse. Antud näites valitakse kõik pod-id nimedes, millel on vastavad sildid:

namespaceSelector:
  matchLabels:
    project: myproject

Üks hoiatus: kasutamisel namespaceSelector'iga veenduge, et valitud nimed sisaldavad vajalikke silte. Pidage meeles, et vaikimisi nimed, nagu default ja kube-system, ei sisalda endas silte.

Nime lisamiseks nimele võite teha järgmist:

kubectl label namespace default namespace=default

Siiski peab nimi jaotises metadata viitama tegelikule nimele, mitte sildile:

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

Allikas ja adressaat

Tulemüüripoliitikad koosnevad reeglitest, millel on allikad ja sihtkohad. Kubernetes'i võrgu poliitikad määratlevad sihtmärkide - pod'ide komplekti, millele need kehtivad, ja seejärel kehtestavad reeglid sissetuleva (ingress) ja/või väljuva (egress) liikluse jaoks. Meie näites on poliitika sihtmärk kõik pod'id nimede ruumis default märgisega, mille võtme app ja väärtusega 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

Alam ingress selles poliitikas avab sissetulev liiklus sihitud pod'idesse. Teisisõnu, ingress on allikas, samas kui sihtmärk on vastav sihtkoht. Sarnaselt on egress sihtkoht, samas kui sihtmärk on selle allikas.

See on ekvivalent kahe reegliga tulemüürile: Ingress → Sihtmärk; Sihtmärk → Egress.

Egress ja DNS (tähtis!)

Piirates väljuvat liiklust, 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 lubanud rakendusel balance Pöörduda DNS-i poole:

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 seetõttu valib see kaudset kõik pod'id kõigis nimede ruumides, lubades balance saata DNS-päringud vastavasse Kubernetes teenusesse (tavaliselt töötab see ruumis kube-system).

See lähenemine töötab, kuid see on ülemäära lubav ja ebaturvaline, kuna võimaldab suunata DNS-päringud klastrist välja.

Seda saab täiustada kolme järjestikuse sammuga.

1. Lubada DNS-päringud ainult sisemine klastri, lisades namespaceSelector'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
  - to:
    - namespaceSelector: {} # <<<
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

2. Lubage DNS-päringud ainult nimede ruumis kube-system.

Selleks tuleb lisada silt nime ruumi kube-system: kubectl label namespace kube-system namespace=kube-system — ja määrata see poliitikasse kasutades namespaceSelector'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
  - to:
    - namespaceSelector:         # <<<
        matchLabels:             # <<<
          namespace: kube-system # <<<
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

3. Paranoikud võivad minna veelgi kaugemale ja piirata DNS-päringuid konkreetse DNS-teenusega kube-system. Jaotises „Filter nime ruumide ja pod’ide järgi“ räägitakse, kuidas seda saavutada.

Teine võimalus on lubada DNS nime 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 nimede ruumis.

Esimene vastavus ja reeglite järjekord

Tavalistes tulemüürides määrab paketi tegevuse ("Lubada" või "Keelata") esimene reegel, millele see vastab. Kuberneteses ei oma poliitikate järjekord mingit tähtsust.

Vaikimisi, kui poliitikad pole määratud, on pod'ide vaheline suhtlus lubatud ja nad saavad vabalt teavet vahetada. Kui hakkate poliitikaid koostama, muutub iga pod, mida mõjutab vähemalt üks neist, isoleerituks vastavalt nende valitud poliitikate disjunktsioonile (loogiline VÕI). Pod'id, mida ei mõjuta ükski poliitika, jäävad avatuks.

Sarnast käitumist saab muuta puhastamisreegliga.

Puhastamisreegel ("Keelata")

Tulemüüride poliitikad keelavad tavaliselt iga asjaolu, mis ei ole selgelt lubatud.

Kuberneteses ei ole "keelata" (deny) tegevust, kuid sarnast mõju saab saavutada tavalise (lubava) poliitika abil, valides tühi pod'ide-allika (ingress) rühma:

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

See policy valib kõik pod'id nimede ruumis ja jätab ingress määratlemata, keelates kogu sissetuleva liikluse.

Sarnasel moel saab piirata kogu väljaminevat liiklust nimede ruumist:

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

Pange tähele, et igal täiendaval poliitikal, mis lubab liiklust pod'idesse nimede ruumis, on prioriteet selle reegli ees (sarnane lubava reegli lisamisega enne keelavat reeglit tulemüüris).

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

Kuna luua poliitika «Luba kõik», on soovitatav täiendada ülaltoodud keelu poliitikat tühja elemendiga ingress:

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

See avab ligipääsu kõigist pod'idest kõigis nimede ruumides (ja kõik IP) mistahes pod'idele nimede ruumis default. Sarnane käitumine on vaikimisi sisse lülitatud, seega tavaliselt ei ole seda vaja veelkord määratleda. Siiski võib mõnikord olla vajalik ajutine teatud lubade keelamine probleemi tõrkeotsimiseks.

Reegelit saab kitsendada ja lubada juurdepääsu ainult teatud hulgale pod'idele (app:balance) nimede ruumis default:

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

Järgmine poliiitika lubab kogu sissetulevat (ingress) ja väljaminevat (egress) liiklust, sealhulgas juurdepääsu mis tahes IP-le klastrist väljaspool:

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

Mitmete poliitikate ühendamine

Poliitikad ühendatakse loogiliste OR abil kolme taseme kaudu; iga pod'i lubamine määratakse kõigi poliitikate disjunktsiooni alusel, mis seda mõjutavad:

1. Valdkondades from ja to saab määrata kolme tüüpi elemente (kõik need kombineeritakse loogilise OR abil):

• namespaceSelector'iga — valib nimede ruumi täielikult;
• podSelector — valib pod'id;
• ipBlock — valib alamvõrgu.

Sellega on elementide arv (isegi samade) osade hulgas from/to piiratud. Kõik need ühendatakse loogilise OR abil.

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. Poliitika sees ingress võib sisaldada mitmeid elemente from (need ühendatakse loogilise VÕI-tega). Sarnaselt võib osa egress sisaldada mitmeid elemente to (need ühendatakse samuti 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. Erinevad poliitikad ühendatakse samuti loogilise VÕI-tega

Ent nende ühendamise puhul on üks piirang, millele et Chris Cooney: Kubernetes suudab kombineerida poliitikaid ainult erinevate policyTypes (Ingress või Egress). Poliitikad, mis määratlevad ingress (või egress), kirjutavad üksteist üle.

Nimekiri ruumide vahel

Vaikimisi on teabevahetus nimekiri ruumide vahel lubatud. Seda saab muuta piirava poliitikaga, mis piirab väljaminevat ja/ või sisenevat liiklust nimekirja ruumis (vt "Puhastusreegel" ülal).

Blokeerides juurdepääsu nimeserverisse (vt „Korrigeerimise reegel“ üleval), saate teha erandeid keelu poliitikas, lubades ühendusi kindlast nimeserverist. namespaceSelector'iga:

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 see, et kõik pod'id nimeserveris default saavad juurdepääsu pod'idele postgres nimeserveris database. Aga mis siis, kui soovite avada juurdepääsu postgres ainult konkreetsetele pod'idele nimeserveris default?

Filtreerimine nimeserverite ja pod'ide järgi

Kubernetes versioonis 1.11 ja kõrgem võimaldab kombineerida operaatorid namespaceSelector'iga ja podSelector kasutades loogilist JA. See näeb välja nii:

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 tavapäraseks VÕI?

Pange tähele, et podSelector ei alga kriipsust. YAML-is tähendab see, et podSelector ja selle ees namespaceSelector'iga kuuluvad samasse listi elementi. Seetõttu liidetakse need loogilise JA-ga.

Kriipsu lisamine enne podSelector toob endaga kaasa uue loendi elementi, mis kombineeritakse eelnevaga namespaceSelector'iga loogilise VÕI abil.

Kuna valida pod'e kindla sildi järgi kõigis nimede ruumides, jätke tühjaks namespaceSelector'iga:

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 sillad ühendatakse VÕI-ga

Tulekahjusüsteemi reeglid mitme objekti (hostide, võrkude, rühmade) jaoks kombineeritakse loogilise VÕI abil. Järgmine reegel rakendub, kui paketi allikas vastab Host_1 VÕI Host_2:

| Allikas | Sihtkoht | Teenus | Tegevus |
| ----------------------------------------|
| Host_1 | Alamsüsteem_A | HTTPS | Luba |
| Host_2 |             |         |        |
| ----------------------------------------|

Teiseks, Kubernetesis erinevad sillad podSelector või namespaceSelector'iga kombineeritakse loogilise JA abil. Näiteks järgmine reegel valib pod'e, millel on mõlemad sillad, role=db JA version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

Sama loogika kehtib kõigi operaatorite tüüpide kohta: poliitika sihiselektsioonide, pod'i valikute ja nimede ruumide valikute puhul.

Alamsüsteemid ja IP-aadressid (IPBlocks)

VLAN-e, IP-aadresse ja alamvõrgud on brankdüüsi kasutamiseks võrgu segmentimiseks.

Kubernetesis määratakse IP-aadressid pod'idele automaatselt ja need võivad sageli muutuda, seetõttu kasutatakse pod'ide ja nimede ruumide valimiseks võrgu poliitikates silte.

Alamvõrgud (ipBlocks) kasutatakse sisenemise (ingress) või väljumise (egress) välise (Põhja-Lõuna) ühenduste haldamiseks. Näiteks avab see poliitika kõigile pod'idele nimede ruumis default 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

Käesoleval näitel tähistab tühi pod'ide valija "vali kõik pod'id nimede ruumis".

See poliitika avab pääsu ainult 8.8.8.8; juurdepääs mistahes muule IP-le on keelatud. Seega olete sisuliselt blokeerinud juurdepääsu Kubernetes'e sisemisele DNS-teenusele. Kui soovite selle avada, tehke seda selgelt.

Tavaliselt ipBlocks ja podSelectors on vastastikku välistavad, kuna sisemisi IP-aadresse pod'ide kohta ei kasutata ipBlocks. Määrates sisemised IP pod'ide, te факtiivselt lubate ühendusi pod'ide ja nende aadresside vahel. Praktiliselt ei tea te, millist IP-aadressi kasutada, seetõttu ei tasu neid pod'ide valimiseks kasutada.

Näiteks sisaldab järgmine poliitika kõiki IP-aadresse ja seega lubab ligipääsu kõigile teistele 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õimalik on avada ligipääs ainult välistele IP-dele, jättes välja pod'ide sisemised 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 portide numbreid ei pea poliitikates lihtsalt määrama ja saab jätta kõik vaikeseadetele. Siiski on soovitatav poliitikad teha võimalikult piiravad, seega võib mõnel juhul portide täpsustamine olla vajalik:

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

Märge, et valija ports kõikidele elementidele plokis to või from, kus see asub. Erinevate elementide koguste jaoks erinevate portide määramiseks jagage ingress või egress mitmeks alajaoks koos to või from ja igas määrake oma pordid:

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 jätate pordi määratlemise täielikult välja (ports), tähendab see kõiki protokolle ja kõiki porte;
• Kui jätate protokolli määratlemise välja (protocol), tähendab see TCP;
• Kui jätate pordi (port) määratlemise välja, tähendab see kõiki porte.

Parim praktika: ärge toetuge vaikeväärtustele, määrake vajalikud väärtused selgelt.

Pange tähele, et tuleb kasutada pod'ide porte, mitte teenuste omi (täiendav teave järgmises lõigus).

Kas poliitikad on määratletud pod'ide või teenuste jaoks?

Tavaliselt suhtlevad pod'id Kubernetes'es omavahel teenuste kaudu — virtuaalse koormuse tasakaalustaja, mis suunab liiklust pod'idele, mis teenust rakendavad. Võib arvata, et võrgupoliitikad kontrollivad juurdepääsu teenustele, kuid see pole nii. Kubernetes'e võrgupoliitikad töötavad pod'ide portidega, mitte teenuste portidega.

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

Sarnast mehhanismi tuleks pidada mitteoptimaalseks: teenuse sisemiste seadete muutumisel (mille porti kuulavad pod'id) tuleb võrgupoliitikaid uuendada.

Uus arhitektuuriline lähenemine Service Mesh'i kasutamisega (näiteks vaadake Istio kohta allpool — tõlkija märkus) lahendab selle probleemi.

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

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

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

Kui mõni pod-allikas valitakse ühe või mitme egress-poliitika kaudu, siis sellele kehtestatud piirangud määravad nende disjunktsioon. Sellisel juhul tuleb selgesõnaliselt lubada ühendus pod-adressaat. Kui pod ei ole valitud ühegi poliitika tõttu, on tema väljuv (egress) liiklus vaikimisi lubatud.

Sarnaselt sõltub pod-adressaat, mille on valinud ühe või mitme ingress-poliitika, nende disjunktsioonist. Sellisel juhul tuleb selgesõnaliselt lubada tal vastu võtta liiklust pod-ennetlest. Kui pod ei ole valitud ühegi poliitika tõttu, on kogu sissetulev (ingress) liiklus talle vaikimisi lubatud.

Vaata allpool punkti "Stateful või Stateless".

Logid

Kubenetide poliitikad ei suuda liiklust logida. See raskendab poliitika tõhususe määratlemist ja takistab oluliselt turvauuringute tegemist.

Liikluse kontroll välistesse teenustesse

Kubenetide poliitikad ei võimalda määrata täisvormingus domeeninime (DNS) väljumiste (egress) osades. See põhjustab märkimisväärset ebamugavust, kui püütakse piirata liiklust välistele adressaatidele, kellel puudub staatiline IP-aadress (näiteks aws.com).

Poliitika kontrollimine

Tulemüüri seadmed teavitavad teid või isegi keelduvad vale poliitika vastuvõtmisest. Kubernetes viib samuti läbi teatavaid kontrollimisi. Kui seadistada võrgupoliitika läbi kubectl, võib Kubernetes väita, et see on vale ja keelduda selle vastuvõtmisest. Teistes olukordades võtab Kubernetes poliitika vastu ja täidab puuduvaid andmeid. Neid saab vaadata järgmise käsu abil:

kubernetes get networkpolicy  -o yaml

Pange tähele, et Kubernetes kontrollimisprotsess ei ole eksimustest vaba ja võib jätta tähelepanuta mõned tüübid vigu.

Teostus

Kubernetes ei rakenda võrgu poliitikaid iseseisvalt, vaid toimib vaid API-lüüsina, jättes koormava kontrollitöö allolevale süsteemile, mida tuntakse kui Container Networking Interface (CNI). Poliitikate seadmine Kubernetes klastris ilma vastava CNI määramiseta on sarnane poliitikate loomisega tulemüüride juhtimisse, ilma et need hiljem tulemüüridesse installitaks. Te peate ise veenduma, et teil on sobiv CNI või, juhul kui Kubernetes platvormi pakutakse pilves, (võite tutvuda teenusepakkujate nimekirjaga siit — tõlkija märkus.), rakendama võrgu poliitikaid, mis seadistavad CNI teie eest.

Pange tähele, et Kubernetes ei hoiatada teid, kui määrate võrgu poliitika, ilma et vastav toimetav CNI oleks olemas.

Stateful või Stateless?

Kõik CNI-d, millega olen kokku puutunud, salvestavad olekuid (näiteks Calico kasutab Linuxi conntrack). See võimaldab pod'il saada vastuseid tema alustatud TCP-ühendusele, ilma et oleks vaja seda uuesti kehtestada. Samas ei ole mulle teada Kubernetes'e standardit, mis garanteeriks olekute säilitamise (statefulness).

Edasiarenenud turvapoliitika haldamine

Siin on mõned viisid, kuidas tõsta turvapoliitika täitmise efektiivsust Kuberneteses:

1. Teenuse Meshi arhitektuurimuster kasutab sidecar-konteinereid, et tagada põhjalik telemeetrija ning liikluse kontroll teenuste tasemel. Näiteks võib tuua Istio.
2. Mõned CNI pakkujad on täiendanud oma tööriistu nii, et need ületavad Kubernetes'e võrgu poliitikaid.
3. Tufin Orca tagab Kubernetes'e võrgu poliitikate läbipaistvuse ja automatiseerimise.

Tufin Orca pakett haldab Kubernetes'e võrgu poliitikaid (ja toimib eespool toodud ekraanipiltide allikana).

Lisainformatsioon

• Võrgu poliitikad, mille on valmistanud Ahmet Alp Balkan GKE-st;
• Dokumentatsioon Kubernetes'e ametlikul veebisaidil;
• Kubernetes'e võrgu mudeli juhend;
• Võrgu poliitikate kontrollimise skript.

Kokkuvõte

Kubernetesi võrgupoliitikad pakuvad head tööriistade kogumit klastrite segmenteerimiseks, kuid need on intuitsioonilt keerulised ja neil on palju nüansse. Arvan, et selle keerukuse tõttu sisaldavad paljude olemasolevate klastrite poliitikad vigu. Selle probleemi võimalikud lahendused on poliitikate määratlemise automatiseerimine või teiste segmenteerimisvahendite rakendamine.

Loodan, et see juhend aitab selgitada mõned küsimused ja lahendada probleemid, millega võite kokku puutuda.

P.S. tõlkija märkused

Lugege ka meie blogist:

• „Tagasi mikroteenuste juurde koos Istio’ga“: osa 1 (tutvumine põhifunktsioonidega), osa 2 (suunamine, liikluse haldamine), osa 3 (turvalisus);
• „Illustreeritud juhend Kuberneteses olevate võrkude seadistamiseks“: osad 1 ja 2 (võrgumudel, overlay-võrgud), osa 3 (teenused ja liikluse töötlemine);
• «Docker ja Kubernetes turvafookusega keskkondades»;
• «9 parimat praktikat Kubernetes'e turvamiseks»;
• «11 viisi, kuidas (mitte) sattuda Kubernetes'e häkkimise ohvriks».

Allikas: habr.com