🥇Uvod v omrežne pravilnike Kubernetes za varnostne strokovnjake

Opomba. prevod: Avtor članka, Reuven Harrison, ima več kot 20 let izkušenj z razvojem programske opreme, danes pa je CTO in soustanovitelj podjetja Tufin, ki ustvarja rešitve za upravljanje varnostnih politik. Medtem ko vidi omrežne politike Kubernetes kot precej močno orodje za segmentacijo omrežja v gruči, je tudi prepričan, da jih v praksi ni tako enostavno implementirati. To gradivo (precej obsežno) je namenjeno izboljšanju zavedanja strokovnjakov o tem vprašanju in jim pomaga ustvariti potrebne konfiguracije.

Danes se mnoga podjetja vse pogosteje odločajo za Kubernetes za izvajanje svojih aplikacij. Zanimanje za to programsko opremo je tako veliko, da nekateri Kubernetes imenujejo "novi operacijski sistem za podatkovne centre." Postopoma se Kubernetes (ali k8s) začenja dojemati kot kritičen del poslovanja, ki zahteva organizacijo zrelih poslovnih procesov, vključno z varnostjo omrežja.

Za varnostne strokovnjake, ki jih delo s Kubernetesom zmede, je lahko pravo razodetje privzeta politika platforme: dovolite vse.

Ta vodnik vam bo pomagal razumeti notranjo strukturo omrežnih politik; razumeti, kako se razlikujejo od pravil za običajne požarne zidove. Zajel bo tudi nekatere pasti in zagotovil priporočila za pomoč pri zaščiti aplikacij v Kubernetesu.

Omrežni pravilniki Kubernetes

Mehanizem omrežne politike Kubernetes vam omogoča upravljanje interakcije aplikacij, nameščenih na platformi, na omrežni plasti (tretji v modelu OSI). Omrežni pravilniki nimajo nekaterih naprednih funkcij sodobnih požarnih zidov, kot sta uveljavljanje OSI Layer 7 in zaznavanje groženj, vendar zagotavljajo osnovno raven varnosti omrežja, ki je dobro izhodišče.

Omrežni pravilniki nadzirajo komunikacijo med enotami

Delovne obremenitve v Kubernetesu so porazdeljene po sklopih, ki so sestavljeni iz enega ali več vsebnikov, nameščenih skupaj. Kubernetes vsakemu podu dodeli naslov IP, ki je dostopen iz drugih podov. Omrežni pravilniki Kubernetes določajo pravice dostopa za skupine podov na enak način, kot se varnostne skupine v oblaku uporabljajo za nadzor dostopa do primerkov navideznega stroja.

Definiranje omrežnih politik

Tako kot drugi viri Kubernetes so omrežni pravilniki določeni v YAML. V spodnjem primeru aplikacija balance dostop do 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

(Opomba. prevod: ta posnetek zaslona, tako kot vsi poznejši podobni, ni bil ustvarjen z domačimi orodji Kubernetes, temveč z orodjem Tufin Orca, ki ga je razvilo podjetje avtorja izvirnega članka in je omenjeno na koncu gradiva.)

Če želite določiti lastno omrežno politiko, boste potrebovali osnovno znanje YAML. Ta jezik temelji na zamiku (določen s presledki in ne z zavihki). Zamaknjen element pripada najbližjem zamaknjenemu elementu nad njim. Nov element seznama se začne z vezajem, vsi ostali elementi imajo obliko ključ-vrednost.

Ko ste pravilnik opisali v YAML, uporabite kubectlda ga ustvarite v gruči:

kubectl create -f policy.yaml

Specifikacija omrežne politike

Specifikacija omrežne politike Kubernetes vključuje štiri elemente:

podSelector: definira sklope, na katere vpliva ta pravilnik (cilji) – obvezno;
policyTypes: označuje, katere vrste pravilnikov so vključene v to: vhod in/ali izstop - neobvezno, vendar priporočam, da ga izrecno navedete v vseh primerih;
ingress: določa dovoljeno dohodni promet do ciljnih blokov – neobvezno;
egress: določa dovoljeno odhodni promet iz ciljnih sklopov ni obvezen.

Primer iz spletne strani Kubernetes (zamenjal sem role o app), prikazuje, kako se uporabljajo vsi štirje 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

Upoštevajte, da ni nujno, da so vključeni vsi štirje elementi. Samo obvezno je podSelector, po želji lahko uporabite druge parametre.

Če izpustite policyTypes, se pravilnik razlaga tako:

Privzeto se predpostavlja, da definira vstopno stran. Če pravilnik tega izrecno ne določa, bo sistem domneval, da je ves promet prepovedan.
Vedenje na izhodni strani bo določeno s prisotnostjo ali odsotnostjo ustreznega izhodnega parametra.

V izogib napakam priporočam vedno naj bo jasno policyTypes.

V skladu z zgornjo logiko, če parametri ingress in / ali egress izpuščen, bo pravilnik zavrnil ves promet (glejte "Pravilo odstranjevanja" spodaj).

Privzeti pravilnik je Dovoli

Če pravilniki niso definirani, Kubernetes privzeto dovoljuje ves promet. Vsi podi lahko prosto izmenjujejo informacije med seboj. Z varnostnega vidika se to morda zdi protislovno, vendar ne pozabite, da so Kubernetes prvotno zasnovali razvijalci, da bi omogočili interoperabilnost aplikacij. Omrežni pravilniki so bili dodani pozneje.

Imenski prostori

Imenski prostori so mehanizem sodelovanja Kubernetes. Namenjeni so izolaciji logičnih okolij drug od drugega, medtem ko je komunikacija med prostori privzeto dovoljena.

Kot večina komponent Kubernetes, omrežne politike živijo v določenem imenskem prostoru. V bloku metadata lahko določite, kateremu prostoru pravilnik pripada:

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

Če imenski prostor ni izrecno določen v metapodatkih, bo sistem uporabil imenski prostor, določen v kubectl (privzeto namespace=default):

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

priporočam izrecno določite imenski prostor, razen če pišete pravilnik, ki cilja na več imenskih prostorov hkrati.

Glavni element podSelector v pravilniku bo izbral pode iz imenskega prostora, ki mu pravilnik pripada (zavrnjen je dostop do podov iz drugega imenskega prostora).

Podobno podSelectors v vstopnih in izhodnih blokih lahko izbere samo pode iz lastnega imenskega prostora, razen če jih seveda kombiniraš z namespaceSelector (o tem bomo razpravljali v razdelku »Filtriranje po imenskih prostorih in sklopih«).

Pravila za poimenovanje pravilnika

Imena pravilnikov so edinstvena znotraj istega imenskega prostora. V istem prostoru ne moreta obstajati dva pravilnika z enakim imenom, lahko pa obstajajo pravilniki z istim imenom v različnih prostorih. To je uporabno, če želite znova uporabiti isti pravilnik v več prostorih.

Še posebej mi je všeč eden od načinov poimenovanja. Sestavljen je iz kombinacije imena imenskega prostora s ciljnimi sklopi. Na primer:

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

Oznake

Objektom Kubernetes, kot so pods in imenski prostori, lahko pripnete oznake po meri. Oznake (nalepke - oznake) so enakovredne oznakam v oblaku. Omrežni pravilniki Kubernetes za izbiro uporabljajo oznake strokiza katere veljajo:

podSelector:
  matchLabels:
    role: db

… ali imenski prostoriza katere veljajo. Ta primer izbere vse sklope v imenskih prostorih z ustreznimi oznakami:

namespaceSelector:
  matchLabels:
    project: myproject

Eno opozorilo: pri uporabi namespaceSelector poskrbite, da imenski prostori, ki jih izberete, vsebujejo pravilno oznako. Zavedajte se, da vgrajeni imenski prostori, kot je npr default и kube-system, privzeto ne vsebujejo oznak.

Prostoru lahko dodate oznako, kot je ta:

kubectl label namespace default namespace=default

Hkrati imenski prostor v razdelku metadata se mora nanašati na dejansko ime prostora, ne na oznako:

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

Izvor in cilj

Pravilniki požarnega zidu so sestavljeni iz pravil z viri in cilji. Omrežni pravilniki Kubernetes so definirani za cilj – niz podov, za katere veljajo – in nato nastavijo pravila za vhodni in/ali izhodni promet. V našem primeru bodo cilj pravilnika vsi podi v imenskem prostoru default z nalepko s ključem app in vrednost 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

Pododdelek ingress v tem pravilniku odpre dohodni promet do ciljnih blokov. Z drugimi besedami, vstop je vir, cilj pa ustrezni cilj. Podobno je izhod cilj, cilj pa njegov izvor.

To je enakovredno dvema praviloma požarnega zidu: Ingress → Target; Cilj → Izhod.

Egress in DNS (pomembno!)

Z omejevanjem odhodnega prometa, bodite posebno pozorni na DNS - Kubernetes uporablja to storitev za preslikavo storitev v naslove IP. Naslednji pravilnik na primer ne bo deloval, ker aplikaciji niste dovolili balance dostop do 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

To lahko popravite tako, da odprete dostop do storitve DNS:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:               # <<<
    ports:            # <<<
    - protocol: UDP   # <<<
      port: 53        # <<<
  policyTypes:
  - Egress

Zadnji element to je prazna in zato posredno izbira vsi podi v vseh imenskih prostorih, ki omogoča balance pošljite poizvedbe DNS ustrezni storitvi Kubernetes (ki se običajno izvaja v prostoru kube-system).

Vendar ta pristop deluje pretirano permisiven in negotov, ker omogoča, da so poizvedbe DNS usmerjene izven gruče.

Izboljšate ga lahko v treh zaporednih korakih.

1. Dovoli samo poizvedbe DNS znotraj grozd z dodajanjem 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. Dovolite poizvedbe DNS samo znotraj imenskega prostora kube-system.

Če želite to narediti, morate v imenski prostor dodati oznako kube-system: kubectl label namespace kube-system namespace=kube-system - in to zapišite v politiko uporabe 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. Paranoični ljudje lahko gredo še dlje in omejijo poizvedbe DNS na določeno storitev DNS v kube-system. Razdelek »Filtriranje po imenskih prostorih IN sklopih« vam bo povedal, kako to doseči.

Druga možnost je razrešitev DNS na ravni imenskega prostora. V tem primeru ga ne bo treba odpreti za vsako storitev:

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

Prazno podSelector izbere vse pode v imenskem prostoru.

Prva tekma in vrstni red pravil

Pri običajnih požarnih zidovih je dejanje (Dovoli ali Zavrni) na paketu določeno s prvim pravilom, ki mu zadosti. V Kubernetesu vrstni red politik ni pomemben.

Privzeto, ko ni nastavljen noben pravilnik, je komunikacija med sklopi dovoljena in si lahko prosto izmenjujejo informacije. Ko začnete oblikovati pravilnike, postane vsak sklop, na katerega vpliva vsaj eden od njih, izoliran glede na disjunkcijo (logični ALI) vseh pravilnikov, ki so ga izbrali. Podi, na katere ne vpliva noben pravilnik, ostanejo odprti.

To vedenje lahko spremenite z uporabo pravila za odstranjevanje.

Pravilo odstranjevanja (»Zavrni«)

Politike požarnega zidu običajno zavrnejo promet, ki ni izrecno dovoljen.

V Kubernetesu ni dejanj zavrnitve, vendar je podoben učinek mogoče doseči z običajnim (permisivnim) pravilnikom z izbiro prazne skupine izvornih sklopov (ingress):

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

Ta pravilnik izbere vse sklope v imenskem prostoru in pusti vhod nedefiniran ter zavrne ves dohodni promet.

Na podoben način lahko omejite ves odhodni promet iz imenskega prostora:

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

Upoštevajte to vsi dodatni pravilniki, ki dovoljujejo promet podom v imenskem prostoru, bodo imeli prednost pred tem pravilom (podobno dodajanju dovoljenega pravila pred zavrnitvenim pravilom v konfiguraciji požarnega zidu).

Dovoli vse (karkoli-karkoli-karkoli-dovoli)

Če želite ustvariti pravilnik Dovoli vse, morate zgornji pravilnik Zavrni dopolniti s praznim elementom ingress:

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

Omogoča dostop iz vsi podi v vseh imenskih prostorih (in vsi IP) v kateri koli pod v imenskem prostoru default. To vedenje je privzeto omogočeno, zato ga običajno ni treba dodatno definirati. Vendar boste včasih morda morali začasno onemogočiti nekatera posebna dovoljenja, da diagnosticirate težavo.

Pravilo je mogoče zožiti in dovoliti dostop samo do določen niz strokov (app:balance) v imenskem prostoru default:

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

Naslednji pravilnik dovoljuje ves vhodni in izhodni promet, vključno z dostopom do katerega koli IP-ja zunaj gruče:

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

Združevanje več pravilnikov

Politike so združene z uporabo logičnega ALI na treh ravneh; Dovoljenja vsakega sklopa so nastavljena v skladu z disjunkcijo vseh pravilnikov, ki nanj vplivajo:

1. Na poljih from и to Določiti je mogoče tri vrste elementov (vsi so kombinirani z ALI):

namespaceSelector — izbere celoten imenski prostor;
podSelector — izbira stroke;
ipBlock — izbere podomrežje.

Poleg tega število elementov (tudi enakih) v pododdelkih from/to ni omejeno. Vsi bodo združeni z logičnim ALI.

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. Znotraj razdelka pravilnika ingress ima lahko veliko elementov from (združeno z logičnim ALI). Podobno oddelek egress lahko vključuje veliko elementov to (tudi združeno z disjunkcijo):

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. Različne politike so kombinirane tudi z logičnim ALI

Toda pri njihovem združevanju obstaja ena omejitev poudaril Chris Cooney: Kubernetes lahko združuje samo politike z različnimi policyTypes (Ingress ali Egress). Politike, ki opredeljujejo vhod (ali izstop), bodo prepisale druga drugo.

Odnos med imenskimi prostori

Privzeto je dovoljena izmenjava informacij med imenskimi prostori. To je mogoče spremeniti z uporabo politike zavrnitve, ki bo omejila odhodni in/ali dohodni promet v imenski prostor (glejte »Pravilo za odstranjevanje« zgoraj).

Ko ste blokirali dostop do imenskega prostora (glejte "Pravilo za odstranjevanje" zgoraj), lahko naredite izjeme od pravilnika o zavrnitvi tako, da dovolite povezave iz določenega imenskega prostora z 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

Posledično so vsi podi v imenskem prostoru default bo imel dostop do pods postgres v imenskem prostoru database. Kaj pa, če želite odpreti dostop do postgres samo določeni podi v imenskem prostoru default?

Filtrirajte po imenskih prostorih in sklopih

Različica Kubernetes 1.11 in novejše vam omogočajo kombiniranje operaterjev namespaceSelector и podSelector z uporabo logičnega IN. Videti je takole:

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

Zakaj se to razlaga kot IN namesto običajnega ALI?

Prosimo, upoštevajte, da se podSelector se ne začne z vezajem. V YAML to pomeni to podSelector in stoji pred njim namespaceSelector nanašajo na isti element seznama. Zato so kombinirani z logičnim IN.

Dodajanje vezaja pred podSelector bo povzročil nastanek novega elementa seznama, ki bo združen s prejšnjim namespaceSelector z uporabo logičnega ALI.

Če želite izbrati stroke z določeno oznako v vseh imenskih prostorih, vnesite prazno 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

Več založb se združuje z I

Pravila za požarni zid z več objekti (gostitelji, omrežja, skupine) so združena z uporabo logičnega ALI. Naslednje pravilo bo delovalo, če se vir paketa ujema Host_1 ALI Host_2:

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

Nasprotno, v Kubernetesu različne oznake v podSelector ali namespaceSelector so združeni z logičnim IN. Naslednje pravilo bo na primer izbralo sklope, ki imajo obe oznaki, role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

Enaka logika velja za vse vrste operaterjev: izbirnike ciljev pravilnika, izbirnike podov in izbirnike imenskega prostora.

Podomrežja in naslovi IP (IPBlocks)

Požarni zidovi za segmentacijo omrežja uporabljajo omrežja VLAN, naslove IP in podomrežja.

V Kubernetesu so naslovi IP podom samodejno dodeljeni in se lahko pogosto spreminjajo, zato se oznake uporabljajo za izbiro podov in imenskih prostorov v omrežnih pravilnikih.

Podomrežja (ipBlocks) se uporabljajo pri upravljanju dohodnih (ingress) ali odhodnih (egress) zunanjih (sever-jug) povezav. Na primer, ta pravilnik se odpre za vse sklope iz imenskega prostora default dostop do storitve Google DNS:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-dns
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 8.8.8.8/32
    ports:
    - protocol: UDP
      port: 53

Prazen izbirnik podov v tem primeru pomeni »izberi vse pode v imenskem prostoru«.

Ta pravilnik dovoljuje samo dostop do 8.8.8.8; dostop do katerega koli drugega IP-ja je prepovedan. Torej ste v bistvu blokirali dostop do notranje storitve DNS Kubernetes. Če ga še vedno želite odpreti, to izrecno označite.

Običajno ipBlocks и podSelectors se medsebojno izključujeta, saj se notranji naslovi IP podov ne uporabljajo v ipBlocks. Z navedbo notranji IP pods, boste dejansko dovolili povezave do/iz podov s temi naslovi. V praksi ne boste vedeli, kateri naslov IP uporabiti, zato jih ne bi smeli uporabljati za izbiro podov.

Kot nasprotni primer naslednji pravilnik vključuje vse IP-je in zato dovoljuje dostop do vseh drugih sklopov:

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

Dostop lahko odprete samo do zunanjih naslovov IP, razen notranjih naslovov IP podov. Na primer, če je podomrežje vašega sklopa 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

Vrata in protokoli

Običajno enote poslušajo ena vrata. To pomeni, da v pravilnikih preprosto ne morete določiti številk vrat in vse pustiti privzeto. Vendar je priporočljivo, da so pravilniki čim bolj restriktivni, tako da lahko v nekaterih primerih še vedno določite vrata:

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

Upoštevajte, da je izbirnik ports velja za vse elemente v bloku to ali from, ki vsebuje. Če želite določiti različna vrata za različne nize elementov, razdelite ingress ali egress na več pododdelkov s to ali from in v vsakem registru svoja vrata:

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

Privzeto delovanje vrat:

Če popolnoma izpustite definicijo vrat (ports), to pomeni vse protokole in vsa vrata;
Če izpustite definicijo protokola (protocol), to pomeni TCP;
Če izpustite definicijo vrat (port), to pomeni vsa vrata.

Najboljša praksa: Ne zanašajte se na privzete vrednosti, izrecno navedite, kaj potrebujete.

Upoštevajte, da morate uporabljati vrata pod, ne servisnih (več o tem v naslednjem odstavku).

Ali so pravilniki določeni za sklope ali storitve?

Običajno podi v Kubernetesu dostopajo drug do drugega prek storitve – navideznega izravnalnika obremenitve, ki preusmeri promet na pode, ki izvajajo storitev. Morda mislite, da omrežne politike nadzorujejo dostop do storitev, vendar ni tako. Omrežni pravilniki Kubernetes delujejo na vratih pod, ne na servisnih vratih.

Na primer, če storitev posluša vrata 80, vendar preusmeri promet na vrata 8080 svojih podov, morate v omrežnem pravilniku določiti natančno 8080.

Takšen mehanizem je treba obravnavati kot neoptimalnega: če se notranja struktura storitve (pristanišča, katerih moduli poslušajo) spremeni, bo treba posodobiti omrežne politike.

Nov arhitekturni pristop z uporabo storitvenega omrežja (na primer glej o Istio spodaj - pribl. prevod.) vam omogoča, da se spopadete s to težavo.

Ali je treba registrirati tako Ingress kot Egress?

Kratek odgovor je pritrdilen, da lahko pod A komunicira s podom B, mora imeti dovoljenje za ustvarjanje odhodne povezave (za to morate konfigurirati izhodno politiko), pod B pa mora biti sposoben sprejeti dohodno povezavo ( za to torej potrebujete vstopno politiko).

Vendar se v praksi lahko zanesete na privzeto politiko, ki omogoča povezave v eno ali obe smeri.

Če nekaj pod-Vir bo izbral eden ali več izstop-politiki, bodo omejitve, ki so mu naložene, določene z njihovo disjunkcijo. V tem primeru boste morali izrecno dovoliti povezavo s podom -naslovniku. Če pod ni izbran z nobenim pravilnikom, je njegov odhodni (izhodni) promet privzeto dovoljen.

Podobna je usoda strokanaslovnik, ki jih izbere eden ali več vdor-politiki, bo določena z njihovo disjunkcijo. V tem primeru mu morate izrecno dovoliti prejemanje prometa iz izvornega bloka. Če pod ni izbran z nobenim pravilnikom, je ves vhodni promet zanj privzeto dovoljen.

Glejte Stateful ali Stateless spodaj.

Dnevniki

Omrežni pravilniki Kubernetes ne morejo beležiti prometa. Zaradi tega je težko ugotoviti, ali politika deluje, kot je predvideno, in močno oteži varnostno analizo.

Nadzor prometa do zunanjih storitev

Omrežni pravilniki Kubernetes ne dovoljujejo podajanja popolnoma kvalificiranega imena domene (DNS) v izhodnih razdelkih. To dejstvo povzroča znatne nevšečnosti pri poskusu omejitve prometa na zunanje cilje, ki nimajo fiksnega naslova IP (kot je aws.com).

Preverjanje pravilnika

Požarni zidovi vas bodo opozorili ali celo zavrnili sprejetje napačne politike. Kubernetes izvaja tudi nekaj preverjanja. Pri nastavljanju omrežnega pravilnika prek kubectl lahko Kubernetes razglasi, da je napačen, in ga zavrne. V drugih primerih bo Kubernetes prevzel pravilnik in ga dopolnil z manjkajočimi podrobnostmi. Ogledate si jih lahko z ukazom:

kubernetes get networkpolicy <policy-name> -o yaml

Ne pozabite, da sistem preverjanja Kubernetes ni nezmotljiv in lahko spregleda nekatere vrste napak.

Izvedba

Kubernetes sam ne izvaja omrežnih politik, ampak je le prehod API, ki breme nadzora prenese na osnovni sistem, imenovan Container Networking Interface (CNI). Nastavitev pravilnikov v gruči Kubernetes brez dodelitve ustreznega CNI je enaka ustvarjanju pravilnikov na strežniku za upravljanje požarnega zidu, ne da bi jih nato namestili na požarne zidove. Na vas je, da zagotovite spodoben CNI ali, v primeru platform Kubernetes, gostovanje v oblaku (seznam ponudnikov si lahko ogledate tukaj — pribl. prev.), omogočite omrežne pravilnike, ki vam bodo nastavili CNI.

Upoštevajte, da vas Kubernetes ne bo opozoril, če nastavite omrežni pravilnik brez ustreznega pomožnega CNI.

Državni ali brez državljanstva?

Vsi Kubernetes CNI-ji, ki sem jih srečal, so s stanjem (na primer, Calico uporablja Linux conntrack). To omogoča podu, da prejme odgovore na povezavo TCP, ki jo je sprožil, ne da bi jo bilo treba znova vzpostaviti. Vendar pa ne poznam standarda Kubernetes, ki bi zagotavljal statusnost.

Napredno upravljanje varnostne politike

Tukaj je nekaj načinov za izboljšanje uveljavljanja varnostne politike v Kubernetesu:

Arhitekturni vzorec Service Mesh uporablja vsebnike stranske prikolice za zagotavljanje podrobne telemetrije in nadzora prometa na ravni storitve. Kot primer lahko vzamemo Istio.
Nekateri prodajalci CNI so razširili svoja orodja, da presežejo omrežne politike Kubernetes.
Tufin Orca Zagotavlja vidnost in avtomatizacijo omrežnih pravilnikov Kubernetes.

Paket Tufin Orca upravlja omrežne pravilnike Kubernetes (in je vir zgornjih posnetkov zaslona).

dodatne informacije

Zaključek

Omrežni pravilniki Kubernetes ponujajo dober nabor orodij za segmentiranje gruč, vendar niso intuitivni in imajo veliko razlik. Zaradi te zapletenosti menim, da so številne obstoječe politike gruč napačne. Možne rešitve te težave vključujejo avtomatizacijo definicij politik ali uporabo drugih orodij za segmentacijo.

Upam, da vam bo ta vodnik pomagal razjasniti nekaj vprašanj in odpraviti težave, na katere lahko naletite.

PS od prevajalca

Preberite tudi na našem blogu:

"Nazaj k mikrostoritvam z Istio": 1. del (uvod v glavne značilnosti), del 2 (usmerjanje, nadzor prometa), del 3 (varnost);
"Ilustriran vodnik za mreženje v Kubernetesu": 1. in 2. del (omrežni model, prekrivna omrežja), del 3 (storitve in obdelava prometa);
«Docker in Kubernetes v varnostno občutljivih okoljih»;
«9 najboljših praks varnosti Kubernetes»;
«11 načinov, kako (ne)postati žrtev vdora v Kubernetes".

Vir: www.habr.com

Uvod v omrežne pravilnike Kubernetes za varnostne strokovnjake