'n Inleiding tot Kubernetes-netwerkbeleide vir sekuriteitspersoneel

Let wel. vertaal.: Die skrywer van die artikel - Reuven Harrison - het meer as 20 jaar ondervinding in sagteware-ontwikkeling, en is vandag die CTO en medestigter van Tufin, 'n maatskappy vir oplossings vir sekuriteitsbeleidbestuur. Alhoewel hy Kubernetes-netwerkbeleide as kragtig genoeg beskou om die netwerk in 'n groep te segmenteer, glo hy ook dat dit nie so maklik is om in die praktyk te implementeer nie. Hierdie materiaal (nogal omvangryk) is bedoel om die bewustheid van spesialiste in hierdie saak te verbeter en hulle te help om die nodige konfigurasies te skep.

Vandag kies baie maatskappye al hoe meer Kubernetes om hul toepassings te laat loop. Belangstelling in hierdie sagteware is so groot dat sommige Kubernetes "die nuwe bedryfstelsel vir datasentrums" noem. Kubernetes (of k8s) begin geleidelik beskou word as 'n kritieke deel van die besigheid wat die organisasie van volwasse besigheidsprosesse vereis, insluitend netwerksekuriteit.

Vir sekuriteitspersoneel wat verbaas was deur met Kubernetes te werk, kan die verstekbeleid van hierdie platform 'n ware ontdekking wees: laat alles toe.

Hierdie gids sal jou help om die innerlike werking van netwerkbeleide te verstaan; verstaan ​​hoe hulle verskil van die reëls vir gewone firewalls. Dit sal ook praat oor sommige van die slaggate en aanbevelings gee wat sal help om toepassings in Kubernetes te beskerm.

Kubernetes-netwerkbeleide

Die Kubernetes-netwerkbeleidmeganisme laat jou toe om die interaksie van toepassings wat op die platform op die netwerklaag (die derde in die OSI-model) ontplooi is, te bestuur. Netwerkbeleide kort sommige van die gevorderde kenmerke van moderne firewalls, soos OSI-laag 7-beheer en bedreigingsopsporing, maar dit bied 'n basiese laag netwerksekuriteit wat 'n goeie beginpunt is.

Netwerkbeleide beheer kommunikasie tussen peule

Werkladings in Kubernetes word oor peule versprei, wat bestaan ​​uit een of meer houers wat saam ontplooi is. Kubernetes ken aan elke peul 'n IP-adres toe wat toeganklik is vanaf ander peule. Kubernetes-netwerkbeleide stel toegangstoestemmings vir groepe peule op dieselfde manier as wat sekuriteitsgroepe in die wolk gebruik word om toegang tot virtuele masjiengevalle te beheer.

Definieer netwerkbeleide

Net soos ander Kubernetes-bronne, word netwerkbeleide in YAML gestel. In die voorbeeld hieronder, die toepassing balance maak toegang tot 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

(Let wel. vertaal.: hierdie skermkiekie, soos alle daaropvolgende soortgelyke skermkiekies, is nie geskep met inheemse Kubernetes-nutsgoed nie, maar met behulp van die Tufin Orca-nutsding, wat ontwikkel is deur die maatskappy van die skrywer van die oorspronklike artikel en wat aan die einde van die materiaal genoem word.)

Basiese kennis van YAML word vereis om jou eie netwerkbeleid te definieer. Hierdie taal is gebaseer op inkeping (gespesifiseer deur spasies, nie oortjies nie). Die ingekeep element behoort aan die naaste ingekeep element bo dit. Die nuwe element van die lys begin met 'n koppelteken, alle ander elemente is van die vorm sleutel-waarde.

Nadat u die beleid in YAML beskryf het, gebruik kubectlom dit in die groepie te skep:

kubectl create -f policy.yaml

Netwerkbeleidspesifikasie

Die Kubernetes-netwerkbeleidspesifikasie sluit vier elemente in:

1. podSelector: definieer die peule wat deur hierdie beleid geraak word (teikens) - vereis;
2. policyTypes: dui aan watter tipe beleide in hierdie een ingesluit is: ingang en/of uitgang - opsioneel, maar ek beveel aan om dit in alle gevalle uitdruklik te spesifiseer;
3. ingress: definieer toegelaat inkomende verkeer na teikenpeule - opsioneel;
4. egress: definieer toegelaat uitgaande verkeer vanaf teikenpeule is opsioneel.

'n Voorbeeld geleen van die Kubernetes-werf (ek het vervang role op app), wys hoe al vier elemente gebruik word:

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

Let daarop dat dit nie nodig is om al vier elemente in te sluit nie. Dit word slegs vereis podSelector, kan die res van die parameters gebruik word soos verlang.

As ons weglaat policyTypes, sal die beleid as volg geïnterpreteer word:

• Dit word by verstek aanvaar om die ingangskant te definieer. Indien die beleid dit nie uitdruklik aandui nie, sal die stelsel aanvaar dat alle verkeer verbied is.
• Die gedrag aan die uitgang kant sal bepaal word deur die teenwoordigheid of afwesigheid van die ooreenstemmende uitgang parameter.

Om foute te vermy, beveel ek aan wees altyd eksplisiet policyTypes.

Volgens die logika hierbo, in die geval van die parameters ingress en / of egress weggelaat word, sal die beleid alle verkeer weier (sien "Sweep Reël" hieronder).

Verstekbeleid - laat toe

As geen beleide gedefinieer is nie, laat Kubernetes alle verkeer by verstek toe. Alle peule is vry om inligting met mekaar uit te ruil. Uit 'n sekuriteitsoogpunt kan dit teen-intuïtief lyk, maar onthou dat Kubernetes oorspronklik deur ontwikkelaars geskep is met die doel om toepassings interoperabel te maak. Netwerkbeleide is later bygevoeg.

Naamruimtes

Naamruimtes is die Kubernetes-samewerkingsmeganisme. Hulle is ontwerp om logiese omgewings van mekaar te isoleer, terwyl dit by verstek kommunikasie tussen ruimtes toelaat.

Soos die meeste Kubernetes-komponente, leef netwerkbeleide in 'n spesifieke naamruimte. In die blok metadata jy kan spesifiseer aan watter spasie die polis behoort:

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

As die naamspasie nie eksplisiet in die metadata gespesifiseer word nie, sal die stelsel die naamspasie gebruik wat in kubectl gespesifiseer is (verstek namespace=default):

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

Ek beveel aan spesifiseer naamruimte eksplisiet, tensy jy 'n beleid skryf wat verskeie naamruimtes tegelyk teiken.

Die belangrikste element podSelector in die beleid sal peule kies uit die naamruimte waaraan die beleid behoort (dit het nie toegang tot peule van 'n ander naamruimte nie).

Net so, podSelectors in in- en uitgangsblokke kan slegs peule uit hul eie naamruimte kies, tensy jy dit natuurlik kombineer met namespaceSelector (Dit sal bespreek word in die "Filter volgens naamruimtes en peule" afdeling).

Beleidsbenoemingsreëls

Beleidname is uniek binne dieselfde naamruimte. Daar kan nie twee beleide met dieselfde naam in dieselfde spasie wees nie, maar daar kan wel beleide met dieselfde naam in verskillende spasies wees. Dit is nuttig wanneer jy dieselfde beleid oor veelvuldige spasies weer wil toepas.

Ek hou veral van een van die naammetodes. Dit bestaan ​​uit die samevoeging van die naamruimtenaam met die teikenpeule. Byvoorbeeld:

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

Etikette

Gepasmaakte etikette kan aan Kubernetes-voorwerpe soos peule en naamruimtes geheg word. Etikette (etikette tags) is die ekwivalent van merkers in die wolk. Kubernetes-netwerkbeleide gebruik etikette om te kies peulewaarop hulle van toepassing is:

podSelector:
  matchLabels:
    role: db

… of naamruimteswaarop hulle van toepassing is. Hierdie voorbeeld kies alle peule in naamruimtes met bypassende etikette:

namespaceSelector:
  matchLabels:
    project: myproject

Een waarskuwing: wanneer dit gebruik word namespaceSelector maak seker dat die naamruimtes wat jy kies die korrekte etiket bevat. Wees bewus daarvan dat ingeboude naamruimtes soos default и kube-system, bevat nie by verstek etikette nie.

Jy kan 'n etiket soos volg by 'n spasie voeg:

kubectl label namespace default namespace=default

In hierdie geval, die naamruimte in die afdeling metadata moet verwys na die werklike naam van die spasie, nie die etiket nie:

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

Bron en Bestemming

Firewall-beleide bestaan ​​uit bron- en bestemmingreëls. Kubernetes-netwerkbeleide word gedefinieer per teiken, die stel peule waarop hulle van toepassing is, en stel dan reëls vir in- en/of uitgangverkeer. In ons voorbeeld sal die beleidteiken alle peule in die naamruimte wees default met sleuteletiket app en betekenis 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

Onderafdeling ingress in hierdie beleid maak inkomende verkeer oop vir teikenpeule. Met ander woorde, die ingang is die bron en die teiken is die ooreenstemmende bestemming. Net so is uitgang die bestemming, en die teiken is die bron daarvan.

Dit is gelykstaande aan twee firewall-reëls: Ingang → Teiken; Teiken → Uitgang.

Uitgang en DNS (belangrik!)

Beperk uitgaande verkeer gee spesiale aandag aan DNS - Kubernetes gebruik hierdie diens om dienste na IP-adresse te karteer. Die volgende beleid sal byvoorbeeld nie werk nie omdat jy nie die aansoek toegelaat het nie balance toegang tot 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

U kan dit regstel deur toegang tot die DNS-diens oop te maak:

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

Laaste element to leeg is, en dus kies dit indirek alle peule in alle naamruimtes, toelaat balance stuur DNS-navrae na die toepaslike Kubernetes-diens (gewoonlik loop dit in die ruimte kube-system).

Hierdie benadering werk egter te permissief en onseker, want dit laat jou toe om DNS-navrae buite die groepie te rig.

Jy kan dit in drie opeenvolgende stappe verbeter.

1. Laat slegs DNS-navrae toe binne groepeer deur by te voeg 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. Laat DNS-navrae slegs in die naamruimte toe kube-system.

Om dit te doen, moet jy 'n etiket by die naamruimte voeg kube-system: kubectl label namespace kube-system namespace=kube-system - en registreer dit in die polis deur gebruik te maak van 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. Paranoïese mense kan selfs verder gaan en DNS-versoeke beperk tot 'n spesifieke DNS-diens in kube-system. Die "Filter volgens naamruimtes EN peule"-afdeling sal jou wys hoe om dit te bereik.

Nog 'n opsie is om DNS op die naamruimtevlak op te los. In hierdie geval hoef dit nie vir elke diens oopgemaak te word nie:

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

Leeg podSelector kies alle peule in die naamruimte.

Eerste wedstryd en reël volgorde

In konvensionele brandmure word die aksie (Laat toe of weier) op 'n pakkie bepaal deur die eerste reël waaraan dit voldoen. In Kubernetes maak die volgorde van beleide nie saak nie.

By verstek, wanneer geen beleide gestel is nie, word kommunikasie tussen peule toegelaat en kan hulle inligting vrylik uitruil. Sodra jy begin om polisse te formuleer, word elke peul wat deur ten minste een van hulle geraak word geïsoleer volgens die disjunksie (logiese OF) van al die polisse wat dit gekies het. Peule wat nie deur enige beleid geraak word nie, bly oop.

Jy kan hierdie gedrag verander met 'n veegreël.

Opruimingsreël ("Verbied")

Firewall-beleide weier gewoonlik enige verkeer wat nie uitdruklik toegelaat word nie.

Kubernetes het nie 'n "ontken"-aksie nie, maar dieselfde effek kan bereik word met 'n normale (permissiewe) beleid deur 'n leë groep bronpeule (intree) te kies:

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

Hierdie beleid kies alle peule in die naamruimte en laat ingang ongedefinieerd, wat alle inkomende verkeer weier.

Net so kan jy alle uitgaande verkeer vanaf die naamruimte beperk:

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

Let asseblief daarop dat enige bykomende beleide wat verkeer na peule in die naamruimte toelaat, sal voorkeur geniet bo hierdie reël (soortgelyk aan die toevoeging van 'n toelaat-reël voor 'n weiering-reël in die firewall-konfigurasie).

Laat almal toe (Enige-Enige-Enige-Laat toe)

Om 'n "Laat almal toe"-beleid te skep, moet jy die bogenoemde weieringbeleid aanvul met 'n leë element ingress:

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

Dit bied toegang tot alle peule in alle naamruimtes (en alle IP's) na enige peul in die naamruimte default. Hierdie gedrag is by verstek geaktiveer, so dit hoef gewoonlik nie verder gedefinieer te word nie. Dit kan egter soms nodig wees om sekere spesifieke toestemmings tydelik te deaktiveer om die probleem te diagnoseer.

Die reël kan vernou word om slegs toegang toe te laat 'n spesifieke stel peule (app:balance) in die naamruimte default:

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

Die volgende beleid laat alle inkomende (inkomende) EN uitgaande (uitgaande) verkeer toe, insluitend toegang tot enige IP buite die groepering:

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

Kombineer veelvuldige beleide

Beleide word logies op drie vlakke OF georden; Elke peul se toestemmings word gestel volgens die verdeling van al die beleide wat dit raak:

1. In die velde from и to drie tipes elemente kan gedefinieer word (almal gekombineer met OF):

• namespaceSelector - kies die hele naamruimte;
• podSelector - kies peule;
• ipBlock - kies 'n subnet.

Terselfdertyd, die aantal elemente (selfs dieselfde) in onderafdelings from/to nie beperk nie. Almal van hulle sal gekombineer word met 'n logiese OF.

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. Binne-polisafdeling ingress kan baie elemente hê from (saamgestel deur logiese OF). Net so, afdeling egress kan baie elemente insluit to (ook gekombineer deur disjunksie):

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. Verskillende beleide word ook gekombineer met 'n logiese OF

Maar wanneer hulle gekombineer word, is daar een beperking waarop uitgewys Chris Cooney: Kubernetes kan slegs beleide met verskillende kombineer policyTypes (Ingress of Egress). Beleide wat ingang (of uitgang) definieer, sal mekaar oorskryf.

Verwantskap tussen naamruimtes

By verstek word die uitruil van inligting tussen naamruimtes toegelaat. Dit kan verander word met 'n beperkende beleid wat uitgaande en/of inkomende verkeer tot die naamruimte beperk (sien "Sweepreël" hierbo).

Deur toegang tot 'n naamruimte te blokkeer (sien "Veegreël" hierbo), kan jy uitsonderings op die weieringsbeleid maak deur verbindings vanaf 'n spesifieke naamruimte toe te laat met 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

As gevolg hiervan, alle peule in die naamruimte default kry toegang tot peule postgres in naamruimte database. Maar wat as jy toegang wil oopmaak tot postgres slegs spesifieke peule in die naamruimte default?

Filter volgens naamruimtes EN peule

Kubernetes weergawe 1.11 en hoër laat jou toe om operateurs te kombineer namespaceSelector и podSelector met behulp van logiese EN. Dit lyk soos volg:

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

Hoekom word dit geïnterpreteer as EN in plaas van die gewone OF?

Let asseblief daarop dat podSelector begin nie met 'n koppelteken nie. In YAML beteken dit dat podSelector en voor hom staan namespaceSelector verwys na dieselfde lyselement. Daarom word hulle gekombineer met 'n logiese EN.

Voeg 'n streep voor by podSelector sal lei tot 'n nuwe lyselement wat met die vorige een gekombineer sal word namespaceSelector gebruik logiese OF.

Om peule met 'n spesifieke etiket te kies in alle naamruimtes, voer leeg in 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

Veelvuldige etikette kombineer met EN

Firewall-reëls met veelvuldige entiteite (gashere, netwerke, groepe) word gekombineer deur 'n logiese OF te gebruik. Die volgende reël sal brand as die pakkiebron ooreenstem Host_1 OF Host_2:

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

Inteendeel, in Kubernetes verskillende etikette in podSelector of namespaceSelector word gekombineer met 'n logiese EN. Byvoorbeeld, die volgende reël sal peule kies wat beide byskrifte het, role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

Dieselfde logika geld vir alle soorte stellings: beleidteikenkiesers, peulkiesers en naamruimtekiesers.

Subnette en IP-adresse (IPBlocks)

Firewalls gebruik VLAN's, IP-adresse en subnette om 'n netwerk te segmenteer.

In Kubernetes word IP-adresse outomaties aan peule toegewys en kan gereeld verander, dus word etikette gebruik om peule en naamruimtes in netwerkbeleide te kies.

Subnetwerke (ipBlocks) word gebruik wanneer inkomende (inkomende) of uitgaande (uitgang) eksterne (Noord-Suid) verbindings bestuur word. Byvoorbeeld, hierdie beleid maak alle peule van die naamruimte oop default toegang tot Google DNS-diens:

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

Die leë peulkieser in hierdie voorbeeld beteken "kies alle peule in die naamruimte".

Hierdie beleid laat slegs toegang tot 8.8.8.8 toe; toegang tot enige ander IP is verbode. Dus, in wese, het u toegang tot die interne Kubernetes DNS-diens geblokkeer. As jy dit steeds wil oopmaak, spesifiseer dit uitdruklik.

Gewoonlik ipBlocks и podSelectors is wedersyds uitsluitend, aangesien die interne IP-adresse van die peule nie in gebruik word nie ipBlocks. Uit te wys interne IP-peule, sal jy eintlik verbindings na/van peule met daardie adresse toelaat. In die praktyk sal jy nie weet watter IP-adres om te gebruik nie, en daarom moet jy dit nie gebruik om peule te kies nie.

As 'n teenvoorbeeld sluit die volgende beleid alle IP's in en laat dus toegang tot alle ander peule toe:

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

U kan slegs toegang tot eksterne IP's oopmaak, die interne IP-adresse van die peule uitgesluit. Byvoorbeeld, as jou peul se subnet 10.16.0.0/14 is:

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

Hawens en protokolle

Gewoonlik luister peule op een poort. Dit beteken dat jy eenvoudig die poortnommers in jou polisse kan weglaat en alles as verstek laat. Dit word egter aanbeveel om beleide so beperkend as moontlik te maak, sodat u in sommige gevalle steeds poorte kan spesifiseer:

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

Let daarop dat die keurder ports van toepassing op alle elemente in die blok to of from, wat bevat. Om verskillende poorte vir verskillende itemstelle te spesifiseer, breek ingress of egress in verskeie onderafdelings to of from en skryf in elkeen jou poorte neer:

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

Standaard poorte werk:

• As jy die definisie van poorte heeltemal weglaat (ports), wat beteken alle protokolle en alle poorte;
• As jy die protokoldefinisie weglaat (protocol), wat TCP beteken;
• As jy die poortdefinisie (port), wat beteken alle hawens.

Beste praktyk: Moenie op verstekwaardes staatmaak nie, spesifiseer wat jy uitdruklik nodig het.

Let daarop dat jy pod-poorte moet gebruik, nie dienste nie (meer hieroor in die volgende paragraaf).

Beleide gedefinieer vir peule of dienste?

Gewoonlik kommunikeer peule in Kubernetes met mekaar deur 'n diens - 'n virtuele lasbalanseerder wat verkeer herlei na die peule wat die diens implementeer. Jy mag dalk dink dat netwerkbeleide toegang tot dienste beheer, maar dit is nie die geval nie. Kubernetes-netwerkbeleide werk met pod-poorte, nie dienste nie.

Byvoorbeeld, as 'n diens op poort 80 luister, maar verkeer na poort 8080 van sy peule herlei, moet jy 8080 in die netwerkbeleid spesifiseer.

So 'n meganisme moet as suboptimaal erken word: as die interne toestel van die diens (die poorte waarvan na peule luister) verander, sal netwerkbeleide opgedateer moet word.

Nuwe argitektoniese benadering met behulp van Service Mesh (sien byvoorbeeld oor Istio hieronder - ongeveer transl.) laat jou toe om hierdie probleem te hanteer.

Is dit nodig om beide Ingress en Egress te skryf?

Die kort antwoord is ja, sodat pod A met pod B kan kommunikeer, moet jy dit toelaat om 'n uitgaande verbinding te skep (hiervoor moet jy die uitgangsbeleid konfigureer), en pod B moet 'n inkomende verbinding kan aanvaar (hiervoor het jy dus intreebeleid nodig).

In die praktyk kan u egter op die verstekbeleid staatmaak om verbindings in een of albei rigtings toe te laat.

As een of ander peul-bron sal deur een of meer gekies word uitgang-politici, die beperkings wat daarop opgelê word, sal bepaal word deur hul disjunksie. In hierdie geval sal jy die verbinding met die peul uitdruklik moet toelaatgeadresseerde. As 'n pod nie deur enige beleid gekies word nie, word sy uitgaande (uitgaande) verkeer by verstek toegelaat.

Net so is die lot van die pod'a-geadresseerdedeur een of meer gekies binnedring-beleide sal bepaal word deur hul disjunksie. In hierdie geval moet jy dit uitdruklik toelaat om verkeer vanaf die bronpod te ontvang. As 'n pod nie deur enige beleid gekies word nie, word alle inkomende verkeer daarheen by verstek toegelaat.

Sien "Staatvol of Staatloos" hieronder.

Logs

Kubernetes-netwerkbeleide weet nie hoe om verkeer aan te teken nie. Dit maak dit moeilik om te bepaal of 'n beleid werk soos verwag en maak sekuriteitsontleding baie moeilik.

Verkeersbeheer na eksterne dienste

Kubernetes-netwerkbeleide laat jou nie toe om 'n volledig gekwalifiseerde domeinnaam (DNS) in uitgangsafdelings te spesifiseer nie. Hierdie feit lei tot 'n aansienlike ongerief wanneer probeer om verkeer te beperk na eksterne bestemmings wat nie 'n vaste IP-adres het nie (soos aws.com).

Beleidskontrole

Firewalls sal jou waarsku of selfs weier om 'n foutiewe beleid te aanvaar. Kubernetes doen ook 'n mate van verifikasie. Wanneer 'n netwerkbeleid via kubectl opgestel word, kan Kubernetes verklaar dat die beleid verkeerd is en weier om dit te aanvaar. In ander gevalle sal Kubernetes die polis neem en dit invul met die ontbrekende besonderhede. Jy kan hulle sien met die opdrag:

kubernetes get networkpolicy <policy-name> -o yaml

Hou in gedagte dat die Kubernetes-bekragtigingstelsel nie onfeilbaar is nie en sommige soorte foute kan mis.

Uitvoering

Kubernetes dwing nie netwerkbeleide op sy eie af nie, maar is bloot 'n API-poort wat die las van beheer plaas op 'n onderliggende stelsel genaamd die Container Networking Interface (CNI). Om beleide op 'n Kubernetes-kluster op te stel sonder om 'n toepaslike CNI toe te ken, is soortgelyk aan die opstel van beleide op 'n firewall-bestuurbediener sonder om dit daarna op firewalls te stel. Dit is aan jou om seker te maak jy het 'n ordentlike CNI of, in die geval van Kubernetes-platforms, in die wolk gehuisves (Vir 'n lys van verskaffers sien hier - ongeveer. trans.), aktiveer netwerkbeleide wat die CNI vir jou sal stel.

Let daarop dat Kubernetes jou nie sal waarsku as jy 'n netwerkbeleid stel sonder die toepaslike helper-CNI nie.

Staatsvol of Staatloos?

Alle Kubernetes CNI's wat ek teëgekom het, is statig (byvoorbeeld, Calico gebruik Linux-verbinding). Dit laat die peul toe om antwoorde te ontvang op die TCP-verbinding wat dit geïnisieer het sonder om dit te hervestig. Ek is egter nie bewus van 'n Kubernetes-standaard wat statigheid sal waarborg nie.

Gevorderde sekuriteitsbeleidbestuur

Hier is 'n paar maniere om die doeltreffendheid van sekuriteitsbeleidstoepassing in Kubernetes te verbeter:

1. Die Service Mesh-argitektoniese patroon gebruik syspan om gedetailleerde telemetrie en verkeersbeheer op diensvlak te verskaf. As 'n voorbeeld kan 'n mens neem Istio.
2. Sommige van die CNI-verskaffers het hul gereedskap uitgebrei om verder te gaan as Kubernetes-netwerkbeleide.
3. Tufin Orca bied deursigtigheid en outomatisering van Kubernetes-netwerkbeleide.

Die Tufin Orca-pakket bestuur Kubernetes-netwerkbeleide (en is die bron van die skermkiekies hierbo).

bykomende inligting

• Netwerkbeleidsvoorbeelde voorberei deur Ahmet Alp Balkan van GKE;
• Dokumentasie vanaf die amptelike Kubernetes-webwerf;
• Kubernetes netwerk model gids;
• Skrip om netwerkbeleide na te gaan.

Gevolgtrekking

Kubernetes-netwerkbeleide bied 'n goeie stel gereedskap vir die segmentering van groepe, maar dit is nie intuïtief nie en het baie subtiliteite. Ek glo dat as gevolg van hierdie kompleksiteit, die beleide van baie bestaande groepe foutief is. Moontlike oplossings vir hierdie probleem is die outomatisering van beleiddefinisies of die gebruik van ander segmenteringsinstrumente.

Ek hoop dat hierdie gids sal help om 'n paar vrae op te klaar en probleme op te los wat u mag teëkom.

PS van vertaler

Lees ook op ons blog:

• "Terug na mikrodienste met Istio": deel 1 (inleiding tot die hoofkenmerke), deel 2 (roetering, verkeersbeheer), deel 3 (sekuriteit);
• "'n Geïllustreerde gids tot netwerk in Kubernetes": dele 1 en 2 (netwerkmodel, oorlegnetwerke), deel 3 (dienste en verkeersverwerking);
• «Docker en Kubernetes in omgewings met veeleisende sekuriteit»;
• «9 Kubernetes Sekuriteit Beste Praktyke»;
• «11 maniere om (nie) gehack te word in Kubernetes nie".

Bron: will.com