🥇Ievads par Kubernetes tīkla politikām drošības profesionāļiem

Piezīme. tulk.: Raksta autoram Reuvenam Harisonam ir vairāk nekā 20 gadu pieredze programmatūras izstrādē, un šodien viņš ir drošības politikas pārvaldības risinājumu radīšanas uzņēmuma Tufin CTO un līdzdibinātājs. Lai gan viņš uzskata, ka Kubernetes tīkla politikas ir diezgan spēcīgs rīks tīkla segmentēšanai klasterī, viņš arī uzskata, ka tās nav tik viegli ieviest praksē. Šis materiāls (diezgan apjomīgs) ir paredzēts, lai uzlabotu speciālistu izpratni par šo jautājumu un palīdzētu viņiem izveidot nepieciešamās konfigurācijas.

Mūsdienās daudzi uzņēmumi arvien vairāk izvēlas Kubernetes savu lietojumprogrammu palaišanai. Interese par šo programmatūru ir tik liela, ka daži Kubernetes sauc par "jauno operētājsistēmu datu centram". Pamazām Kubernetes (jeb k8s) sāk uztvert kā kritisku biznesa sastāvdaļu, kas prasa nobriedušu biznesa procesu organizēšanu, tostarp tīkla drošību.

Drošības speciālistiem, kuri ir neizpratnē par darbu ar Kubernetes, patiesā atklāsme var būt platformas noklusējuma politika: atļaut visu.

Šī rokasgrāmata palīdzēs izprast tīkla politiku iekšējo struktūru; saprast, kā tie atšķiras no noteikumiem par parastajiem ugunsmūriem. Tas arī aptvers dažas nepilnības un sniegs ieteikumus, lai palīdzētu aizsargāt lietojumprogrammas vietnē Kubernetes.

Kubernetes tīkla politikas

Kubernetes tīkla politikas mehānisms ļauj pārvaldīt platformā izvietoto lietojumprogrammu mijiedarbību tīkla slānī (trešais OSI modelī). Tīkla politikām trūkst dažu moderno ugunsmūru uzlaboto līdzekļu, piemēram, OSI Layer 7 izpildes un draudu noteikšanas, taču tās nodrošina pamata tīkla drošības līmeni, kas ir labs sākumpunkts.

Tīkla politikas kontrolē saziņu starp podiem

Kubernetes darba slodzes ir sadalītas pa podiem, kas sastāv no viena vai vairākiem kopā izvietotiem konteineriem. Kubernetes piešķir katram podam IP adresi, kas ir pieejama no citiem podiem. Kubernetes tīkla politikas nosaka piekļuves tiesības podiņu grupām tādā pašā veidā, kā drošības grupas mākonī tiek izmantotas, lai kontrolētu piekļuvi virtuālās mašīnas gadījumiem.

Tīkla politiku noteikšana

Tāpat kā citi Kubernetes resursi, tīkla politikas ir norādītas YAML. Tālāk esošajā piemērā lietojumprogramma balance piekļuve 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

(Piezīme. tulk.: šis ekrānuzņēmums, tāpat kā visi nākamie līdzīgie, tika izveidots nevis izmantojot vietējos Kubernetes rīkus, bet gan rīku Tufin Orca, kuru izstrādāja oriģinālā raksta autora uzņēmums un kas minēts materiāla beigās.)

Lai definētu savu tīkla politiku, jums būs nepieciešamas pamatzināšanas par YAML. Šīs valodas pamatā ir atkāpe (norāda atstarpes, nevis tabulēšanas zīmes). Atkāpes elements pieder tuvākajam atkāpes elementam virs tā. Jauns saraksta elements sākas ar defisi, visiem pārējiem elementiem ir forma atslēgas vērtība.

Aprakstot politiku YAML, izmantojiet kubectllai to izveidotu klasterī:

kubectl create -f policy.yaml

Tīkla politikas specifikācija

Kubernetes tīkla politikas specifikācijā ir iekļauti četri elementi:

podSelector: definē aplikumus, uz kuriem attiecas šī politika (mērķi) - nepieciešams;
policyTypes: norāda, kāda veida politikas ir iekļautas šajā: ingress un/vai izeja - pēc izvēles, bet iesaku to skaidri norādīt visos gadījumos;
ingress: definē atļauto ienākošo datplūsma uz mērķa podiem — pēc izvēles;
egress: definē atļauto izejošo datplūsma no mērķa podiem nav obligāta.

Piemērs ņemts no Kubernetes vietnes (es nomainīju role par app), parāda, kā tiek izmantoti visi četri 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

Lūdzu, ņemiet vērā, ka visiem četriem elementiem nav jābūt iekļautiem. Tas ir tikai obligāti podSelector, pēc vēlēšanās var izmantot citus parametrus.

Ja jūs izlaižat policyTypes, politika tiks interpretēta šādi:

Pēc noklusējuma tiek pieņemts, ka tas definē ieejas pusi. Ja politikā tas nav skaidri norādīts, sistēma pieņems, ka visa satiksme ir aizliegta.
Uzvedību izejas pusē noteiks atbilstošā izejas parametra esamība vai neesamība.

Lai izvairītos no kļūdām, es iesaku vienmēr skaidri norādiet policyTypes.

Saskaņā ar iepriekš minēto loģiku, ja parametri ingress un / vai egress izlaist, politika aizliedz visu trafiku (skatiet tālāk sadaļu "Noņemšanas kārtula").

Noklusējuma politika ir Atļaut

Ja nav noteiktas politikas, Kubernetes pēc noklusējuma atļauj visu trafiku. Visas pākstis var brīvi apmainīties ar informāciju savā starpā. No drošības viedokļa tas var šķist pretrunā, taču atcerieties, ka Kubernetes sākotnēji izstrādāja izstrādātāji, lai nodrošinātu lietojumprogrammu savietojamību. Tīkla politikas tika pievienotas vēlāk.

Vārdtelpas

Vārdtelpas ir Kubernetes sadarbības mehānisms. Tie ir paredzēti, lai izolētu loģiskās vides viena no otras, savukārt saziņa starp telpām ir atļauta pēc noklusējuma.

Tāpat kā lielākā daļa Kubernetes komponentu, tīkla politikas atrodas noteiktā nosaukumvietā. Blokā metadata varat norādīt, kurai vietai politika pieder:

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

Ja nosaukumvieta nav skaidri norādīta metadatos, sistēma izmantos kubectl norādīto nosaukumvietu (pēc noklusējuma namespace=default):

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

Iesaku skaidri norādiet nosaukumvietu, ja vien nerakstāt politiku, kuras mērķauditorija ir vairākas nosaukumvietas vienlaikus.

Galvenais elements podSelector politikā atlasīs aplikumus no nosaukumvietas, kurai politika pieder (tai ir liegta piekļuve aplikumiem no citas nosaukumvietas).

Tāpat podSelectors ieejas un izejas blokos var atlasīt aplikumus tikai no savas nosaukumvietas, ja vien jūs tos neapvienojat ar namespaceSelector (par to tiks runāts sadaļā “Filtrēt pēc nosaukumvietām un aplikumiem”).

Politikas nosaukšanas noteikumi

Politiku nosaukumi ir unikāli vienā nosaukumvietā. Vienā vietā nevar būt divas politikas ar vienādu nosaukumu, taču dažādās vietās var būt politikas ar vienādu nosaukumu. Tas ir noderīgi, ja vēlaties atkārtoti piemērot vienu un to pašu politiku vairākās vietās.

Īpaši man patīk viena no nosaukšanas metodēm. Tas sastāv no nosaukumvietas nosaukuma apvienošanas ar mērķa pākstiem. Piemēram:

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

Etiķetes

Varat pievienot pielāgotas etiķetes Kubernetes objektiem, piemēram, aplikumiem un nosaukumvietām. Etiķetes (uzlīmes - tagi) ir līdzvērtīgi tagiem mākonī. Lai atlasītu Kubernetes tīkla politikas, tiek izmantotas etiķetes pākstisuz kuriem tie attiecas:

podSelector:
  matchLabels:
    role: db

… vai nosaukumvietasuz kuriem tie attiecas. Šajā piemērā tiek atlasīti visi aplikumi nosaukumvietās ar atbilstošajām iezīmēm:

namespaceSelector:
  matchLabels:
    project: myproject

Viens piesardzība: lietojot namespaceSelector pārliecinieties, vai atlasītajās nosaukumvietās ir ietverta pareizā etiķete. Ņemiet vērā, ka iebūvētās nosaukumvietas, piemēram, default и kube-system, pēc noklusējuma nesatur etiķetes.

Varat pievienot iezīmi vietai, piemēram:

kubectl label namespace default namespace=default

Tajā pašā laikā sadaļā nosaukumu telpa metadata jāattiecas uz faktisko telpas nosaukumu, nevis etiķeti:

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

Avots un galamērķis

Ugunsmūra politikas sastāv no noteikumiem ar avotiem un galamērķiem. Kubernetes tīkla politikas tiek definētas mērķim — apvidu kopai, uz kuru tās attiecas, un pēc tam tiek iestatīti ieejas un/vai izejas trafika noteikumi. Mūsu piemērā politikas mērķis būs visi nosaukumvietas aplikumi default ar etiķeti ar atslēgu app un nozīme 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

Apakšnodaļa ingress šajā politikā atver ienākošo datplūsmu mērķa podiem. Citiem vārdiem sakot, iekļūšana ir avots, un mērķis ir atbilstošais galamērķis. Tāpat izeja ir galamērķis, un mērķis ir tā avots.

Tas ir līdzvērtīgs diviem ugunsmūra noteikumiem: Ingress → Target; Mērķis → Izeja.

Izeja un DNS (svarīgi!)

Ierobežojot izejošo trafiku, pievērsiet īpašu uzmanību DNS - Kubernetes izmanto šo pakalpojumu, lai kartētu pakalpojumus ar IP adresēm. Piemēram, šī politika nedarbosies, jo neesat atļāvis lietojumprogrammu balance piekļūt 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 var novērst, atverot piekļuvi DNS pakalpojumam:

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

Pēdējais elements to ir tukšs, un tāpēc tas netieši atlasa visas pākstis visās nosaukumvietās, ļaujot balance nosūtiet DNS vaicājumus attiecīgajam Kubernetes pakalpojumam (parasti tas darbojas telpā kube-system).

Šī pieeja darbojas, neskatoties uz to pārāk pieļaujams un nedrošs, jo tas ļauj DNS vaicājumus novirzīt ārpus klastera.

Varat to uzlabot trīs secīgās darbībās.

1. Atļaut tikai DNS vaicājumus laikā klasteri, pievienojot 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. Atļaut DNS vaicājumus tikai nosaukumvietā kube-system.

Lai to izdarītu, nosaukumu telpai jāpievieno etiķete kube-system: kubectl label namespace kube-system namespace=kube-system - un pierakstiet to politikā, izmantojot 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ķi var iet vēl tālāk un ierobežot DNS vaicājumus līdz noteiktam DNS pakalpojumam kube-system. Sadaļā “Filtrēt pēc nosaukumvietām UN aplikumiem” tiks parādīts, kā to panākt.

Vēl viena iespēja ir atrisināt DNS nosaukumvietas līmenī. Šajā gadījumā tas nav jāatver katram pakalpojumam:

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

Tukšs podSelector atlasa visas pākstis nosaukumvietā.

Pirmā spēle un noteikumu secība

Parastos ugunsmūros darbību (Atļaut vai Aizliegt) paketē nosaka pirmais noteikums, kuram tā atbilst. Kubernetes politikā politiku secībai nav nozīmes.

Pēc noklusējuma, ja nav iestatītas politikas, ir atļauta saziņa starp podiem un tie var brīvi apmainīties ar informāciju. Kad sākat formulēt politikas, katra apgrupa, kuru ietekmē vismaz viena no tām, tiek izolēta atbilstoši visu to politiku sadalījumam (loģiski VAI), kas to atlasīja. Aplikācijas, kuras neietekmē neviena politika, paliek atvērtas.

Varat mainīt šo darbību, izmantojot noņemšanas kārtulu.

Noņemšanas kārtula (“Noliegt”)

Ugunsmūra politikas parasti aizliedz jebkādu trafiku, kas nav skaidri atļauta.

Kubernetes darbību nevar noliegttomēr līdzīgu efektu var panākt ar parastu (atļaujošu) politiku, atlasot tukšu avota aplikumu grupu (iekļūšanu):

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

Šī politika atlasa visus aplikumus nosaukumvietā un atstāj iekļūšanu nedefinētu, liedzot visu ienākošo trafiku.

Līdzīgā veidā varat ierobežot visu izejošo trafiku no nosaukumvietas:

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

Lūdzu, ņemiet vērā, ka jebkurai papildu politikai, kas atļauj trafiku uz aplikumiem nosaukumvietā, būs prioritāte pār šo noteikumu (līdzīgi kā atļaušanas kārtulas pievienošana pirms aizlieguma kārtulas ugunsmūra konfigurācijā).

Atļaut visu (jebkurš-jebkur-atļaut)

Lai izveidotu politiku Atļaut visu, iepriekš minētā politika ir jāpapildina ar tukšu elementu ingress:

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

Tas ļauj piekļūt no visi aplikumi visās nosaukumvietās (un visi IP) uz jebkuru aplikumu nosaukumvietā default. Šī darbība ir iespējota pēc noklusējuma, tāpēc parasti tā nav jādefinē sīkāk. Tomēr dažreiz jums var būt nepieciešams īslaicīgi atspējot dažas īpašas atļaujas, lai diagnosticētu problēmu.

Noteikumu var sašaurināt, lai atļautu piekļuvi tikai īpašs pākstu komplekts (app:balance) nosaukumvietā default:

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

Tālāk norādītā politika atļauj visu ieejas un izejas trafiku, tostarp piekļuvi jebkuram IP ārpus klastera:

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

Vairāku politiku apvienošana

Politikas tiek apvienotas, izmantojot loģisko VAI trīs līmeņos; Katras podziņas atļaujas tiek iestatītas saskaņā ar atšķirību no visām politikām, kas to ietekmē:

1. Laukos from и to Var definēt trīs veidu elementus (visi tiek apvienoti, izmantojot VAI):

namespaceSelector — atlasa visu nosaukumu telpu;
podSelector — atlasa pākstis;
ipBlock — atlasa apakštīklu.

Turklāt elementu skaits (pat identiski) apakšsadaļās from/to nav ierobežots. Visi tie tiks apvienoti ar loģisko VAI.

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. Politikas sadaļā ingress var būt daudz elementu from (kombinēts ar loģisko VAI). Tāpat sadaļa egress var ietvert daudzus elementus to (arī apvienots ar disjunkciju):

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. Dažādas politikas tiek apvienotas arī ar loģisko VAI

Bet, tos apvienojot, ir viens ierobežojums norādīja Kriss Kūnijs: Kubernetes var apvienot tikai politikas ar dažādām policyTypes (Ingress vai Egress). Politikas, kas nosaka ieeju (vai izeju), pārrakstīs viena otru.

Attiecības starp nosaukumu telpām

Pēc noklusējuma informācijas apmaiņa starp nosaukumvietām ir atļauta. To var mainīt, izmantojot aizlieguma politiku, kas ierobežos izejošo un/vai ienākošo trafiku nosaukumvietā (skatiet iepriekš sadaļu “Noņemšanas kārtula”).

Kad esat bloķējis piekļuvi nosaukumvietai (skatiet iepriekš minēto “Noņemšanas kārtulu”), varat veikt izņēmumus noraidīšanas politikai, atļaujot savienojumus no noteiktas nosaukumvietas, izmantojot 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

Rezultātā visas pākstis nosaukumvietā default būs piekļuve pākstīm postgres vārdu telpā database. Bet ko darīt, ja vēlaties atvērt piekļuvi postgres tikai noteiktas pākstis nosaukumvietā default?

Filtrējiet pēc nosaukumvietām un aplikumiem

Kubernetes versija 1.11 un jaunāka versija ļauj apvienot operatorus namespaceSelector и podSelector izmantojot loģisko UN. Tas izskatās šādi:

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

Kāpēc tas tiek interpretēts kā UN, nevis parastā VAI?

Lūdzu, ņemiet vērā, ka podSelector nesākas ar defisi. YAML tas nozīmē to podSelector un stāvot viņam priekšā namespaceSelector atsaukties uz to pašu saraksta elementu. Tāpēc tie tiek apvienoti ar loģisko UN.

Pirms tam pievieno defisi podSelector rezultātā parādīsies jauns saraksta elements, kas tiks apvienots ar iepriekšējo namespaceSelector izmantojot loģisko VAI.

Lai atlasītu pākstis ar noteiktu etiķeti visās nosaukumvietās, ievadiet tukšu 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

Vairākas etiķetes sadarbojas ar I

Noteikumi ugunsmūrim ar vairākiem objektiem (resursdatoriem, tīkliem, grupām) tiek apvienoti, izmantojot loģisko VAI. Šis noteikums darbosies, ja pakešu avots sakrīt Host_1 VAI Host_2:

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

Gluži pretēji, Kubernetes dažādās etiķetes iekšā podSelector vai namespaceSelector ir apvienoti ar loģisko UN. Piemēram, šī kārtula atlasīs aplikumus, kuriem ir abas etiķetes, role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

Tāda pati loģika attiecas uz visu veidu operatoriem: politikas mērķa atlasītājiem, pod atlasītājiem un nosaukumvietas atlasītājiem.

Apakštīkli un IP adreses (IPBlocks)

Ugunsmūri izmanto VLAN, IP adreses un apakštīklus, lai segmentētu tīklu.

Programmā Kubernetes IP adreses aplikācijām tiek piešķirtas automātiski, un tās var bieži mainīties, tāpēc etiķetes tiek izmantotas, lai tīkla politikās atlasītu aplikumus un nosaukumvietas.

Apakštīkli (ipBlocks) tiek izmantoti, pārvaldot ienākošos (ieejas) vai izejošos (izejas) ārējos (ziemeļu-dienvidu) savienojumus. Piemēram, šī politika tiek atvērta visiem aplikumiem no nosaukumvietas default piekļuve Google DNS pakalpojumam:

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

Tukšais aplikumu atlasītājs šajā piemērā nozīmē “atlasīt visus aplikumus nosaukumvietā”.

Šī politika ļauj piekļūt tikai 8.8.8.8; piekļuve jebkurai citai IP ir aizliegta. Tātad būtībā jūs esat bloķējis piekļuvi iekšējam Kubernetes DNS pakalpojumam. Ja joprojām vēlaties to atvērt, skaidri norādiet to.

Parasti ipBlocks и podSelectors ir savstarpēji izslēdzošas, jo netiek izmantotas podziņu iekšējās IP adreses ipBlocks. Norādot iekšējie IP podi, jūs faktiski atļausiet savienojumus uz/no podiem ar šīm adresēm. Praksē jūs nezināt, kuru IP adresi izmantot, tāpēc tās nevajadzētu izmantot, lai atlasītu pākstis.

Pretpiemērs: tālāk norādītā politika ietver visus IP un tādējādi ļauj piekļūt visiem citiem aplikumiem.

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

Varat atvērt piekļuvi tikai ārējiem IP adresēm, izņemot podziņu iekšējās IP adreses. Piemēram, ja jūsu apakštīkla apakštīkls ir 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

Porti un protokoli

Parasti podi klausās vienu portu. Tas nozīmē, ka politikās var vienkārši nenorādīt portu numurus un atstāt visu pēc noklusējuma. Tomēr ir ieteicams padarīt politikas pēc iespējas ierobežojošākas, tāpēc dažos gadījumos joprojām varat norādīt portus:

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

Ņemiet vērā, ka atlasītājs ports attiecas uz visiem bloka elementiem to vai from, kas satur. Lai dažādām elementu kopām norādītu dažādus portus, sadaliet ingress vai egress vairākās apakšsadaļās ar to vai from un katrā reģistrējiet savas ostas:

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

Noklusējuma porta darbība:

Ja pilnībā izlaižat porta definīciju (ports), tas nozīmē visus protokolus un visus portus;
Ja izlaižat protokola definīciju (protocol), tas nozīmē TCP;
Ja izlaižat porta definīciju (port), tas nozīmē visas ostas.

Labākā prakse: nepaļaujieties uz noklusējuma vērtībām, skaidri norādiet, kas jums nepieciešams.

Lūdzu, ņemiet vērā, ka jums ir jāizmanto pod porti, nevis apkalpošanas porti (vairāk par to nākamajā rindkopā).

Vai aplikācijām vai pakalpojumiem ir noteiktas politikas?

Parasti Kubernetes podi piekļūst viens otram, izmantojot pakalpojumu — virtuālo slodzes balansētāju, kas novirza trafiku uz aplikācijām, kas ievieš pakalpojumu. Varētu domāt, ka tīkla politikas kontrolē piekļuvi pakalpojumiem, taču tas tā nav. Kubernetes tīkla politikas darbojas uz pod portiem, nevis pakalpojumu portiem.

Piemēram, ja pakalpojums klausās 80. portu, bet novirza datplūsmu uz 8080. portu, tīkla politikā ir jānorāda tieši 8080.

Šāds mehānisms jāuzskata par neoptimālu: ja pakalpojuma iekšējā struktūra (kuru porti klausās) mainās, tīkla politikas būs jāatjaunina.

Jauna arhitektūras pieeja, izmantojot Service Mesh (piemēram, par Istio skatīt zemāk - apm. tulk.) ļauj tikt galā ar šo problēmu.

Vai ir jāreģistrē gan Ingress, gan Egress?

Īsā atbilde ir jā, lai pods A varētu sazināties ar pod B, tam ir jāļauj izveidot izejošo savienojumu (šim nolūkam ir jākonfigurē izejas politika), un podam B ir jāspēj pieņemt ienākošo savienojumu ( šim, attiecīgi, ir nepieciešama ieejas politika). politika).

Tomēr praksē varat paļauties uz noklusējuma politiku, lai atļautu savienojumus vienā vai abos virzienos.

Ja daži pod-avots tiks atlasīti viens vai vairāki izeja-politiķi, tam uzliktos ierobežojumus noteiks viņu disjunkcija. Šajā gadījumā jums būs skaidri jāatļauj savienojums ar pod -adresātam. Ja pods nav atlasīts nevienā politikā, tā izejošā (izejas) trafika ir atļauta pēc noklusējuma.

Tāpat arī pāksts liktenis iradresāts, ko atlasījis viens vai vairāki iekļūšana-politiķi, noteiks viņu nesaskaņas. Šajā gadījumā jums ir skaidri jāļauj tai saņemt trafiku no avota apkopa. Ja podziņa nav atlasīta nevienā politikā, visa tā ieejas datplūsma ir atļauta pēc noklusējuma.

Skatiet zemāk.

Baļķi

Kubernetes tīkla politikas nevar reģistrēt trafiku. Tas apgrūtina noteikt, vai politika darbojas, kā paredzēts, un ievērojami sarežģī drošības analīzi.

Trafika kontrole uz ārējiem pakalpojumiem

Kubernetes tīkla politikas neļauj norādīt pilnībā kvalificētu domēna nosaukumu (DNS) izejas sadaļās. Šis fakts rada ievērojamas neērtības, mēģinot ierobežot trafiku uz ārējiem galamērķiem, kuriem nav fiksētas IP adreses (piemēram, aws.com).

Politikas pārbaude

Ugunsmūri jūs brīdinās vai pat atteiksies pieņemt nepareizu politiku. Kubernetes veic arī dažas pārbaudes. Iestatot tīkla politiku, izmantojot kubectl, Kubernetes var paziņot, ka tā ir nepareiza, un atteikties to pieņemt. Citos gadījumos Kubernetes paņems politiku un aizpildīs to ar trūkstošo informāciju. Tos var redzēt, izmantojot komandu:

kubernetes get networkpolicy <policy-name> -o yaml

Ņemiet vērā, ka Kubernetes validācijas sistēma nav nekļūdīga un var palaist garām dažus kļūdu veidus.

Izpildīšana

Kubernetes pati neievieš tīkla politikas, bet ir tikai API vārteja, kas deleģē kontroles slogu pamatā esošajai sistēmai, ko sauc par konteineru tīkla saskarni (CNI). Politiku iestatīšana Kubernetes klasterī, nepiešķirot atbilstošo CNI, ir tāda pati kā politiku izveide ugunsmūra pārvaldības serverī, pēc tam tās neinstalējot ugunsmūros. Jūsu ziņā ir nodrošināt pienācīgu CNI vai, Kubernetes platformu gadījumā, mitināt mākonī. (jūs varat redzēt pakalpojumu sniedzēju sarakstu šeit — apm. trans.), iespējojiet tīkla politikas, kas iestatīs CNI jūsu vietā.

Ņemiet vērā, ka Kubernetes nebrīdinās, ja iestatīsiet tīkla politiku bez atbilstoša palīga CNI.

Pavalstnieks vai bezvalstnieks?

Visi Kubernetes CNI, ar kuriem esmu saskārusies, ir statusa (piemēram, Calico izmanto Linux conntrack). Tas ļauj podam saņemt atbildes uz uzsākto TCP savienojumu, to neizveidojot no jauna. Taču man nav zināms Kubernetes standarts, kas garantētu valstiskumu.

Uzlabota drošības politikas pārvaldība

Šeit ir daži veidi, kā uzlabot drošības politikas izpildi Kubernetes:

Service Mesh arhitektūras modelis izmanto blakusvāģu konteinerus, lai sniegtu detalizētu telemetriju un satiksmes kontroli servisa līmenī. Kā piemēru varam ņemt Istio.
Daži CNI pārdevēji ir paplašinājuši savus rīkus, lai pārsniegtu Kubernetes tīkla politikas.
Tufins Orka Nodrošina Kubernetes tīkla politiku redzamību un automatizāciju.

Tufin Orca pakotne pārvalda Kubernetes tīkla politikas (un ir iepriekš minēto ekrānuzņēmumu avots).

papildu informācija

Secinājums

Kubernetes tīkla politikas piedāvā labu rīku komplektu klasteru segmentēšanai, taču tās nav intuitīvas un tām ir daudz smalkumu. Šīs sarežģītības dēļ es uzskatu, ka daudzas esošās klasteru politikas ir kļūdainas. Iespējamie šīs problēmas risinājumi ietver politikas definīciju automatizāciju vai citu segmentācijas rīku izmantošanu.

Ceru, ka šī rokasgrāmata palīdzēs noskaidrot dažus jautājumus un atrisināt iespējamās problēmas.

PS no tulka

Lasi arī mūsu emuārā:

"Atpakaļ uz mikropakalpojumiem ar Istio": 1. daļa (ievads galvenajās iezīmēs), 2. daļa (maršrutēšana, satiksmes kontrole), 3. daļa (drošība);
"Ilustrēts ceļvedis tīkla izveidei Kubernetes": 1. un 2. daļa (tīkla modelis, pārklājuma tīkli), 3. daļa (pakalpojumi un satiksmes apstrāde);
«Docker un Kubernetes drošības ziņā jutīgās vidēs";
«9 Kubernetes drošības paraugprakse";
«11 veidi, kā (ne) kļūt par Kubernetes uzlaušanas upuri'.

Avots: www.habr.com

Ievads par Kubernetes tīkla politikām drošības profesionāļiem