🥇Uvod u mrežna pravila Kubernetes za sigurnosne stručnjake

Bilješka. prev.: Autor članka, Reuven Harrison, ima više od 20 godina iskustva u razvoju softvera, a danas je CTO i suosnivač tvrtke Tufin koja kreira rješenja za upravljanje sigurnosnom politikom. Iako mrežne politike Kubernetesa smatra prilično moćnim alatom za segmentaciju mreže u klasteru, također vjeruje da ih nije tako jednostavno implementirati u praksi. Ovaj materijal (prilično opsežan) namijenjen je poboljšanju svijesti stručnjaka o ovom problemu i pomoći im u stvaranju potrebnih konfiguracija.

Danas mnoge tvrtke sve više biraju Kubernetes za pokretanje svojih aplikacija. Zanimanje za ovaj softver toliko je veliko da neki Kubernetes nazivaju "novim operativnim sustavom za podatkovne centre". Postupno se Kubernetes (ili k8s) počinje doživljavati kao kritičan dio poslovanja koji zahtijeva organizaciju zrelih poslovnih procesa, uključujući i mrežnu sigurnost.

Za sigurnosne profesionalce koji su zbunjeni radom s Kubernetesom, pravo otkriće može biti zadana politika platforme: dopustiti sve.

Ovaj će vam vodič pomoći razumjeti unutarnju strukturu mrežnih pravila; razumjeti kako se razlikuju od pravila za obične vatrozide. Također će pokriti neke zamke i dati preporuke za pomoć sigurnim aplikacijama na Kubernetesu.

Kubernetes mrežna pravila

Mehanizam mrežne politike Kubernetes omogućuje vam upravljanje interakcijom aplikacija postavljenih na platformi na mrežnom sloju (treći u OSI modelu). Mrežnim politikama nedostaju neke od naprednih značajki modernih vatrozida, kao što je provedba OSI Layer 7 i otkrivanje prijetnji, ali pružaju osnovnu razinu mrežne sigurnosti koja je dobra polazna točka.

Mrežna pravila kontroliraju komunikaciju između jedinica

Radna opterećenja u Kubernetesu raspoređena su po podovima koji se sastoje od jednog ili više spremnika raspoređenih zajedno. Kubernetes svakom podu dodjeljuje IP adresu kojoj se može pristupiti s drugih podova. Mrežna pravila Kubernetesa postavljaju prava pristupa za grupe mahuna na isti način na koji se sigurnosne grupe u oblaku koriste za kontrolu pristupa instancama virtualnog stroja.

Definiranje mrežnih pravila

Kao i drugi Kubernetes resursi, mrežna pravila navedena su u YAML-u. U donjem primjeru aplikacija balance pristup 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

(Bilješka. prev.: ova snimka zaslona, kao i sve naredne slične, nije stvorena korištenjem izvornih alata Kubernetes, već pomoću alata Tufin Orca, koji je razvila tvrtka autora izvornog članka i koji se spominje na kraju materijala.)

Za definiranje vlastite mrežne politike trebat će vam osnovno poznavanje YAML-a. Ovaj se jezik temelji na uvlačenju (određenom razmacima, a ne tabulatorima). Uvučeni element pripada najbližem uvučenom elementu iznad njega. Novi element liste počinje crticom, svi ostali elementi imaju oblik ključ-vrijednost.

Nakon što ste opisali politiku u YAML-u, koristite kubectlda ga stvorite u klasteru:

kubectl create -f policy.yaml

Specifikacija mrežne politike

Specifikacija Kubernetes mrežne politike uključuje četiri elementa:

podSelector: definira mahune na koje utječe ovo pravilo (ciljevi) - obavezno;
policyTypes: označava koje su vrste pravila uključene u ovo: ulaz i/ili izlaz - opcionalno, ali preporučujem da to eksplicitno navedete u svim slučajevima;
ingress: definira dopušteno dolazni promet do ciljnih grupa - izborno;
egress: definira dopušteno odlazni promet iz ciljnih grupa nije obavezan.

Primjer preuzet s web stranice Kubernetes (zamijenio sam role na app), pokazuje kako se koriste sva četiri elementa:

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

Napominjemo da sva četiri elementa ne moraju biti uključena. To je samo obavezno podSelector, drugi parametri se mogu koristiti po želji.

Ako izostavite policyTypes, politika će se tumačiti na sljedeći način:

Prema zadanim postavkama, pretpostavlja se da definira ulaznu stranu. Ako politika to izričito ne navodi, sustav će pretpostaviti da je sav promet zabranjen.
Ponašanje na izlaznoj strani bit će određeno prisutnošću ili odsutnošću odgovarajućeg izlaznog parametra.

Da biste izbjegli greške preporučujem uvijek neka bude eksplicitna policyTypes.

Prema gornjoj logici, ako parametri ingress i / ili egress izostavljeno, pravilo će odbiti sav promet (pogledajte "Pravilo uklanjanja" u nastavku).

Zadana politika je Dopusti

Ako nisu definirana pravila, Kubernetes dopušta sav promet prema zadanim postavkama. Sve mahune mogu slobodno razmjenjivati informacije među sobom. Ovo se može činiti kontraintuitivnim iz sigurnosne perspektive, ali zapamtite da su Kubernetes izvorno dizajnirali programeri kako bi omogućili međuoperabilnost aplikacija. Mrežna pravila dodana su kasnije.

Imenski prostori

Prostori imena su Kubernetesov mehanizam suradnje. Osmišljeni su za međusobno izoliranje logičkih okruženja, dok je komunikacija između prostora dopuštena prema zadanim postavkama.

Kao i većina komponenti Kubernetesa, mrežna pravila žive u određenom prostoru naziva. U bloku metadata možete odrediti kojem prostoru politika pripada:

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

Ako prostor imena nije eksplicitno naveden u metapodacima, sustav će koristiti prostor imena naveden u kubectl (prema zadanim postavkama namespace=default):

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

Preporučujem eksplicitno navedite imenski prostor, osim ako ne pišete pravilo koje cilja na više imenskih prostora odjednom.

Glavni element podSelector u pravilu će odabrati podove iz prostora imena kojem pravilo pripada (zabranjuje se pristup podovima iz drugog prostora imena).

Slično, podSelectors u ulaznim i izlaznim blokovima mogu odabrati mahune samo iz vlastitog imenskog prostora, osim ako ih naravno ne kombinirate s namespaceSelector (o tome će biti riječi u odjeljku "Filtriranje po imenskim prostorima i podovima").

Pravila imenovanja politike

Nazivi pravila jedinstveni su unutar istog prostora naziva. Ne mogu postojati dvije politike s istim nazivom u istom prostoru, ali mogu postojati politike s istim nazivom u različitim prostorima. Ovo je korisno kada želite ponovno primijeniti isto pravilo na više prostora.

Posebno mi se sviđa jedan od načina imenovanja. Sastoji se od kombiniranja imena prostora imena s ciljnim podovima. Na primjer:

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

Kubernetes objektima, kao što su podovi i prostori imena, možete pridružiti prilagođene oznake. Oznake (Oznake - oznake) su ekvivalent oznakama u oblaku. Pravila mreže Kubernetes koriste oznake za odabir mahunena koje se odnose:

podSelector:
  matchLabels:
    role: db

… ili imenski prostorina koje se odnose. Ovaj primjer odabire sve mahune u prostorima imena s odgovarajućim oznakama:

namespaceSelector:
  matchLabels:
    project: myproject

Jedan oprez: pri korištenju namespaceSelector provjerite sadrže li prostori imena koje odaberete ispravnu oznaku. Imajte na umu da ugrađeni prostori imena kao što su default и kube-system, prema zadanim postavkama ne sadrže oznake.

Možete dodati oznaku prostoru poput ovog:

kubectl label namespace default namespace=default

U isto vrijeme, imenski prostor u odjeljku metadata treba se odnositi na stvarni naziv prostora, a ne na oznaku:

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

Izvor i odredište

Pravila vatrozida sastoje se od pravila s izvorima i odredištima. Mrežna pravila Kubernetes definirana su za cilj - skup podova na koje se primjenjuju - a zatim postavljaju pravila za ulazni i/ili izlazni promet. U našem primjeru, cilj pravila bit će sve mahunarke u prostoru imena default s naljepnicom s ključem app i značenje 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

Pododjeljak ingress u ovom pravilu, otvara dolazni promet do ciljnih grupa. Drugim riječima, ulaz je izvor, a cilj je odgovarajuće odredište. Isto tako, izlaz je odredište, a cilj je njegov izvor.

Ovo je ekvivalentno dvama pravilima vatrozida: Ingress → Target; Cilj → Izlaz.

Egress i DNS (važno!)

Ograničavanjem odlaznog prometa, obratite posebnu pozornost na DNS - Kubernetes koristi ovu uslugu za mapiranje usluga u IP adrese. Na primjer, sljedeća pravila neće raditi jer niste dopustili aplikaciju balance pristup DNS-u:

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 možete popraviti otvaranjem pristupa DNS servisu:

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 i stoga neizravno odabire sve mahune u svim imenskim prostorima, dopuštajući balance pošaljite DNS upite odgovarajućem Kubernetes servisu (obično se izvodi u prostoru kube-system).

Ovaj pristup funkcionira, međutim pretjerano popustljiv i nesiguran, jer omogućuje usmjeravanje DNS upita izvan klastera.

Možete ga poboljšati u tri uzastopna koraka.

1. Dopusti samo DNS upite u klaster dodavanjem 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. Dopustite DNS upite samo unutar prostora imena kube-system.

Da biste to učinili, morate dodati oznaku u imenski prostor kube-system: kubectl label namespace kube-system namespace=kube-system - i to zapišite u politiku korištenja 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 ljudi mogu ići i dalje i ograničiti DNS upite na određenu DNS uslugu u kube-system. Odjeljak "Filtriranje po imenskim prostorima I podovima" reći će vam kako to postići.

Druga je mogućnost razriješiti DNS na razini imenskog prostora. U ovom slučaju neće se morati otvarati za svaku uslugu:

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

Prazan podSelector odabire sve mahune u prostoru imena.

Prva utakmica i redoslijed pravila

U konvencionalnim vatrozidima, akcija (Dopusti ili Zabrani) na paketu određena je prvim pravilom koje on zadovoljava. U Kubernetesu redoslijed politika nije bitan.

Prema zadanim postavkama, kada nisu postavljena pravila, komunikacija između modula je dopuštena i oni mogu slobodno razmjenjivati informacije. Jednom kada počnete formulirati politike, svaka grupa na koju utječe barem jedna od njih postaje izolirana prema disjunkciji (logičko ILI) svih politika koje su je odabrale. Podovi na koje ne utječe nikakvo pravilo ostaju otvoreni.

Ovo ponašanje možete promijeniti pomoću pravila za skidanje.

Pravilo skidanja ("Zabrani")

Pravila vatrozida obično odbijaju svaki promet koji nije izričito dopušten.

U Kubernetesu nema akcije odbijanja, međutim, sličan se učinak može postići s redovnom (permisivnom) politikom odabirom prazne grupe izvornih modula (ingress):

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

Ovo pravilo odabire sve podove u prostoru imena i ostavlja ulaz nedefiniranim, odbijajući sav dolazni promet.

Na sličan način možete ograničiti sav odlazni promet iz imenskog prostora:

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

Imajte na umu da sva dodatna pravila koja dopuštaju promet podovima u prostoru imena imat će prednost nad ovim pravilom (slično dodavanju pravila dopuštanja prije pravila odbijanja u konfiguraciji vatrozida).

Dopusti sve (Sve-Sve-Sve-Dopusti)

Da biste kreirali pravilo Dopusti sve, morate gornje pravilo Odbiti dopuniti praznim elementom ingress:

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

Omogućuje pristup iz sve podove u svim imenskim prostorima (i sve IP) na bilo koji pod u imenskom prostoru default. Ovo je ponašanje omogućeno prema zadanim postavkama, pa ga obično nije potrebno dodatno definirati. Međutim, ponekad ćete možda trebati privremeno onemogućiti neka određena dopuštenja da biste dijagnosticirali problem.

Pravilo se može suziti kako bi se omogućio pristup samo određeni skup mahuna (app:balance) u imenskom 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

Sljedeća pravila dopuštaju sav ulazni i izlazni promet, uključujući pristup bilo kojem IP-u izvan klastera:

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

Kombiniranje višestrukih pravila

Politike se kombiniraju korištenjem logičkog ILI na tri razine; Dopuštenja svake grupe postavljena su u skladu s disjunkcijom svih pravila koja na nju utječu:

1. Na poljima from и to Mogu se definirati tri vrste elemenata (svi se kombiniraju pomoću ILI):

namespaceSelector — odabire cijeli imenski prostor;
podSelector — bira mahune;
ipBlock — odabire podmrežu.

Štoviše, broj elemenata (čak i identičnih) u pododjeljcima from/to nije ograničeno. Svi će oni biti kombinirani logičkim ILI.

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. Unutar odjeljka pravila ingress može imati mnogo elemenata from (kombinirano logičkim ILI). Slično, odjeljak egress može uključivati mnoge elemente to (također kombinirano disjunkcijom):

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čite politike također se kombiniraju s logičkim ILI

Ali kada ih kombinirate, postoji jedno ograničenje na koje istaknuo Chris Cooney: Kubernetes može kombinirati samo pravila s različitim policyTypes (Ingress ili Egress). Politike koje definiraju ulaz (ili izlaz) prebrisat će jedna drugu.

Odnos između imenskih prostora

Prema zadanim postavkama dopušteno je dijeljenje informacija između imenskih prostora. Ovo se može promijeniti korištenjem pravila zabrane koje će ograničiti odlazni i/ili dolazni promet u imenski prostor (pogledajte "Pravilo uklanjanja" gore).

Nakon što ste blokirali pristup prostoru imena (pogledajte "Pravilo uklanjanja" gore), možete napraviti iznimke od pravila odbijanja dopuštajući veze iz određenog prostora imena korištenjem 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

Kao rezultat toga, sve mahune u prostoru imena default imat će pristup pods postgres u imenskom prostoru database. Ali što ako želite otvoriti pristup postgres samo određene mahune u prostoru imena default?

Filtrirajte po imenskim prostorima i grupama

Kubernetes verzija 1.11 i novije vam omogućuju kombiniranje operatora namespaceSelector и podSelector koristeći logički I. To izgleda ovako:

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

Zašto se ovo tumači kao I umjesto uobičajenog ILI?

Imajte na umu da podSelector ne počinje crticom. U YAML-u to znači podSelector i stojeći pred njim namespaceSelector odnose se na isti element popisa. Stoga se kombiniraju s logičkim I.

Dodavanje crtice prije podSelector rezultirat će pojavom novog elementa popisa, koji će se kombinirati s prethodnim namespaceSelector pomoću logičkog ILI.

Za odabir mahuna s određenom oznakom u svim imenskim prostorima, unesite 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

Više etiketa udružuje se s I

Pravila za vatrozid s višestrukim objektima (domaćini, mreže, grupe) kombiniraju se pomoću logičkog ILI. Sljedeće pravilo će raditi ako se izvor paketa podudara Host_1 ILI Host_2:

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

Naprotiv, u Kubernetesu razne oznake u podSelector ili namespaceSelector kombiniraju se s logičkim I. Na primjer, sljedeće pravilo odabrat će mahune koje imaju obje oznake, role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

Ista se logika primjenjuje na sve vrste operatora: selektore cilja politike, selektore podova i selektore prostora imena.

Podmreže i IP adrese (IPBlocks)

Vatrozidi koriste VLAN-ove, IP adrese i podmreže za segmentiranje mreže.

U Kubernetesu, IP adrese se automatski dodjeljuju podovima i mogu se često mijenjati, tako da se oznake koriste za odabir podova i imenskih prostora u mrežnim pravilima.

Podmreže (ipBlocks) koriste se pri upravljanju dolaznim (ingress) ili odlaznim (egress) vanjskim (sjever-jug) vezama. Na primjer, ova se politika otvara svim podovima iz prostora imena default pristup Google DNS servisu:

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

Prazan birač mahuna u ovom primjeru znači "odaberi sve mahune u prostoru imena."

Ovo pravilo dopušta pristup samo 8.8.8.8; pristup bilo kojoj drugoj IP je zabranjen. Dakle, u biti ste blokirali pristup internom Kubernetes DNS servisu. Ako ga ipak želite otvoriti, to izričito naznačite.

Obično ipBlocks и podSelectors međusobno se isključuju jer se interne IP adrese mahuna ne koriste u ipBlocks. Ukazivanjem unutarnje IP jedinice, zapravo ćete omogućiti veze do/od mahuna s ovim adresama. U praksi nećete znati koju IP adresu koristiti, zbog čega se ne bi smjele koristiti za odabir podova.

Kao protuprimjer, sljedeća politika uključuje sve IP-ove i stoga dopušta pristup svim ostalim podovima:

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

Možete otvoriti pristup samo vanjskim IP adresama, isključujući interne IP adrese mahuna. Na primjer, ako je podmreža vašeg modula 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

Portovi i protokoli

Mahune obično slušaju jedan priključak. To znači da jednostavno ne možete navesti brojeve priključaka u pravilima i ostaviti sve kao zadano. Međutim, preporuča se da politike budu što je moguće restriktivnije, tako da u nekim slučajevima ipak možete navesti priključke:

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

Imajte na umu da selektor ports odnosi se na sve elemente u bloku to ili from, koji sadrži. Za navođenje različitih priključaka za različite skupove elemenata, split ingress ili egress u nekoliko pododjeljaka sa to ili from i u svakom registru svoje luke:

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

Zadana operacija priključka:

Ako potpuno izostavite definiciju priključka (ports), to znači sve protokole i sve priključke;
Ako izostavite definiciju protokola (protocol), to znači TCP;
Ako izostavite definiciju priključka (port), to znači sve priključke.

Najbolja praksa: nemojte se oslanjati na zadane vrijednosti, eksplicitno navedite što trebate.

Imajte na umu da morate koristiti pod portove, a ne servisne portove (više o tome u sljedećem odlomku).

Jesu li pravila definirana za module ili usluge?

Obično podovi u Kubernetesu pristupaju jedni drugima putem usluge - virtualnog balansera opterećenja koji preusmjerava promet na podove koji implementiraju uslugu. Možda mislite da mrežna pravila kontroliraju pristup uslugama, ali to nije slučaj. Mrežna pravila Kubernetesa rade na pod portovima, a ne na servisnim portovima.

Na primjer, ako usluga sluša priključak 80, ali preusmjerava promet na priključak 8080 svojih modula, točno 8080 mora biti naveden u mrežnim pravilima.

Takav bi se mehanizam trebao smatrati neoptimalnim: ako se unutarnja struktura usluge (priključci čiji moduli slušaju) promijeni, mrežna pravila morat će se ažurirati.

Novi arhitektonski pristup koji koristi Service Mesh (na primjer, vidi dolje o Istio - pribl. prijevod) omogućuje vam da se nosite s ovim problemom.

Je li potrebno registrirati i Ingress i Egress?

Kratak odgovor je da, kako bi jedinica A mogla komunicirati s jedinicom B, mora joj biti dopušteno stvaranje odlazne veze (za ovo morate konfigurirati izlaznu politiku), a grupa B mora moći prihvatiti dolaznu vezu ( za to vam je, prema tome, potrebna ulazna politika).

Međutim, u praksi se možete osloniti na zadanu politiku koja dopušta veze u jednom ili oba smjera.

Ako neki pod-izvor odabrat će jedan ili više njih izlazak-političari, ograničenja koja su joj nametnuta bit će određena njihovom disjunkcijom. U tom slučaju morat ćete izričito dopustiti povezivanje s modulom -adresatu. Ako pod nije odabran nijednom politikom, njegov odlazni (izlazni) promet dopušten je prema zadanim postavkama.

Slično je i sudbina mahuneadresat, koje je odabrao jedan ili više njih ulazak-političari, odredit će njihova disjunkcija. U tom slučaju, morate mu izričito dopustiti primanje prometa od izvorne jedinice. Ako pod nije odabran nijednim pravilom, sav ulazni promet za njega dopušten je prema zadanim postavkama.

U nastavku pogledajte Stateful ili Stateless.

Dnevnici

Kubernetes mrežna pravila ne mogu bilježiti promet. To otežava određivanje radi li politika kako je predviđeno i uvelike komplicira sigurnosnu analizu.

Kontrola prometa prema vanjskim servisima

Kubernetes mrežna pravila ne dopuštaju vam da navedete potpuno kvalificirani naziv domene (DNS) u izlaznim odjeljcima. Ova činjenica dovodi do značajnih neugodnosti kada se pokušava ograničiti promet na vanjska odredišta koja nemaju fiksnu IP adresu (kao što je aws.com).

Provjera pravila

Vatrozidi će vas upozoriti ili čak odbiti prihvatiti pogrešnu politiku. Kubernetes također provodi određene provjere. Prilikom postavljanja mrežne politike putem kubectla, Kubernetes može izjaviti da je netočna i odbiti je prihvatiti. U drugim slučajevima, Kubernetes će preuzeti politiku i ispuniti je detaljima koji nedostaju. Mogu se vidjeti pomoću naredbe:

kubernetes get networkpolicy <policy-name> -o yaml

Imajte na umu da sustav provjere valjanosti Kubernetes nije nepogrešiv i može propustiti neke vrste pogrešaka.

Izvršenje

Kubernetes sam ne implementira mrežna pravila, već je samo API pristupnik koji delegira teret kontrole temeljnom sustavu koji se zove Container Networking Interface (CNI). Postavljanje pravila na Kubernetes klasteru bez dodjele odgovarajućeg CNI-ja isto je kao i stvaranje pravila na poslužitelju za upravljanje vatrozidom bez njihovog instaliranja na vatrozid. Na vama je da osigurate pristojan CNI ili, u slučaju Kubernetes platformi, hostiran u oblaku (možete vidjeti popis pružatelja usluga здесь - cca. trans.), omogućite mrežna pravila koja će postaviti CNI za vas.

Imajte na umu da vas Kubernetes neće upozoriti ako postavite mrežnu politiku bez odgovarajućeg pomoćnog CNI-ja.

Državljanstvo ili apatrid?

Svi Kubernetes CNI-ovi na koje sam naišao imaju status (na primjer, Calico koristi Linux conntrack). To omogućuje modulu primanje odgovora na TCP vezu koju je pokrenuo bez ponovnog uspostavljanja. Međutim, ne znam za Kubernetes standard koji bi jamčio državnost.

Napredno upravljanje sigurnosnom politikom

Evo nekoliko načina za poboljšanje provedbe sigurnosnih pravila u Kubernetesu:

Arhitektonski uzorak Service Mesh koristi bočne kontejnere za pružanje detaljne telemetrije i kontrole prometa na razini usluge. Kao primjer možemo uzeti Istio.
Neki od dobavljača CNI-ja proširili su svoje alate kako bi nadišli mrežna pravila Kubernetesa.
Tufin Orca Pruža vidljivost i automatizaciju Kubernetes mrežnih pravila.

Paket Tufin Orca upravlja mrežnim pravilima Kubernetesa (i izvor je gornjih snimaka zaslona).

dodatne informacije

Zaključak

Mrežna pravila Kubernetesa nude dobar skup alata za segmentiranje klastera, ali nisu intuitivna i imaju mnogo suptilnosti. Zbog ove složenosti, vjerujem da su mnoge postojeće politike klastera pogrešne. Moguća rješenja ovog problema uključuju automatiziranje definicija pravila ili korištenje drugih alata za segmentaciju.

Nadam se da će vam ovaj vodič pomoći razjasniti neka pitanja i riješiti probleme na koje biste mogli naići.

PS od prevoditelja

Pročitajte i na našem blogu:

"Povratak na mikrousluge s Istiom": dio 1 (uvod u glavne značajke), dio 2 (usmjeravanje, kontrola prometa), dio 3 (sigurnost);
"Ilustrirani vodič za umrežavanje u Kubernetesu": dijelovi 1 i 2 (mrežni model, preklapanje mreža), dio 3 (usluge i obrada prometa);
«Docker i Kubernetes u sigurnosno zahtjevnim okruženjima»;
«9 Kubernetes najboljih praksi za sigurnost»;
«11 načina da (ne) postanete žrtva hakiranja Kubernetesa".

Izvor: www.habr.com

Uvod u mrežna pravila Kubernetes za sigurnosne stručnjake