Kubernetes sareko politiken sarrera Segurtasun profesionalentzako

Ohar. itzul.: Artikuluaren egileak, Reuven Harrisonek, 20 urte baino gehiagoko esperientzia du softwarearen garapenean, eta gaur egun, Tufin, segurtasun politikak kudeatzeko irtenbideak sortzen dituen enpresaren CTO eta sortzailekidea da. Kubernetes sareko politikak kluster batean sareak segmentatzeko tresna nahiko indartsu gisa ikusten dituen arren, praktikan ezartzeko hain errazak ere uste du. Material hau (nahiko bolumena) espezialistek gai honi buruzko kontzientzia hobetzea eta beharrezko konfigurazioak sortzen laguntzea da.

Gaur egun, enpresa askok gero eta gehiago aukeratzen dute Kubernetes beren aplikazioak exekutatzeko. Software honen interesa hain da handia, non batzuek Kubernetes "datu zentrorako sistema eragile berria" deitzen diote. Pixkanaka-pixkanaka, Kubernetes (edo k8s) negozioaren zati kritiko gisa ikusten hasi da, eta horrek negozio-prozesu helduak antolatzea eskatzen du, sareko segurtasuna barne.

Kubernetesekin lan egiteagatik harrituta dauden segurtasun profesionalentzat, benetako errebelazioa plataformaren politika lehenetsia izan daiteke: dena baimendu.

Gida honek sareko politiken barne egitura ulertzen lagunduko dizu; uler ezazu nola desberdintzen diren ohiko suebakien arauetatik. Gainera, akats batzuk estaliko ditu eta Kubernetes-en aplikazioak ziurtatzen laguntzeko gomendioak emango ditu.

Kubernetes sareko politikak

Kubernetes sareko politika mekanismoak plataforman zabaldutako aplikazioen elkarrekintza kudeatzeko aukera ematen du sare-geruzan (hirugarrena OSI ereduan). Sare-politikek suebaki modernoen ezaugarri aurreratu batzuk falta dituzte, hala nola, OSI Layer 7 betearaztea eta mehatxuak hautematea, baina sareko segurtasun-maila oinarrizkoa eskaintzen dute abiapuntu ona dena.

Sare-politikek gailuen arteko komunikazioak kontrolatzen dituzte

Kubernetes-en lan-kargak ontzietan banatzen dira, elkarrekin inplementatutako edukiontzi bat edo gehiagoz osatuta. Kubernetes-ek pod bakoitzari beste podetatik eskura daitekeen IP helbide bat esleitzen dio. Kubernetes sareko gidalerroek sarbide-eskubideak ezartzen dituzte pod-taldeentzako hodeiko segurtasun-taldeak makina birtualeko instantzietarako sarbidea kontrolatzeko erabiltzen diren modu berean.

Sare-politikak zehaztea

Kubernetes-eko beste baliabide batzuk bezala, sare-politikak YAML-n zehazten dira. Beheko adibidean, aplikazioa balance sarbidea 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

(Ohar. itzul.: pantaila-argazki hau, ondorengo antzeko guztiak bezala, Kubernetes jatorrizko tresnak erabili gabe sortu da, baina jatorrizko artikuluaren egilearen enpresak garatu duen Tufin Orca tresna erabiliz eta materialaren amaieran aipatzen dena).

Zure sare-politika definitzeko, YAMLren oinarrizko ezagutzak beharko dituzu. Lengoaia hau koskan oinarritzen da (tauletan baino zuriunez zehazten da). Koskatutako elementu bat haren gainean dagoen koskarik hurbileneko elementuari dagokio. Zerrendako elementu berri bat marratxo batekin hasten da, gainerako elementu guztiek forma dute gako-balioa.

YAML-n politika deskribatu ondoren, erabili kubectlmultzoan sortzeko:

kubectl create -f policy.yaml

Sare-politikaren zehaztapena

Kubernetes sareko politikaren zehaztapenak lau elementu ditu:

1. podSelector: politika honek kaltetutako lekak (helburuak) definitzen ditu - beharrezkoak;
2. policyTypes: honetan zer politika mota sartzen diren adierazten du: sarrera eta/edo irteera - aukerakoa, baina kasu guztietan esplizituki zehaztea gomendatzen dut;
3. ingress: baimenduta definitzen du sarrerako trafikoa helburu lekak - aukerakoa;
4. egress: baimenduta definitzen du irteera helburuko leketatik trafikoa aukerakoa da.

Kubernetes webgunetik hartutako adibidea (ordezkatu dut role on app), lau elementuak nola erabiltzen diren erakusten du:

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

Kontuan izan lau elementuak ez direla zertan sartu. Nahitaezkoa baino ez da podSelector, nahi bezala beste parametro batzuk erabil daitezke.

Baztertzen badugu policyTypes, politika honela interpretatuko da:

• Lehenespenez, sarrera aldea definitzen duela suposatzen da. Politikak ez badu hori berariaz adierazten, sistemak trafiko guztia debekatuta dagoela suposatuko du.
• Irteeraren aldean dagoen portaera dagokion irteera-parametroaren presentziaren edo ezaren arabera zehaztuko da.

Akatsak saihesteko gomendatzen dut beti esplizitu policyTypes.

Goiko logikaren arabera, parametroak bada ingress eta / edo egress baztertuta, gidalerroak trafiko guztia ukatuko du (ikus behean "Benusteko araua").

Politika lehenetsia Baimendu da

Gidalerrorik definitzen ez bada, Kubernetes-ek trafiko guztia onartzen du lehenespenez. Pod guztiek informazioa libreki trukatu dezakete euren artean. Segurtasunaren ikuspuntutik aurkakoa dirudi, baina gogoratu Kubernetes jatorriz garatzaileek diseinatu zutela aplikazioen elkarreragingarritasuna ahalbidetzeko. Sareko politikak geroago gehitu ziren.

Izen-espazioak

Izen-espazioak Kubernetes lankidetza-mekanismoa dira. Ingurune logikoak elkarrengandik isolatzeko diseinatuta daude, espazioen arteko komunikazioa lehenespenez onartzen den bitartean.

Kubernetesen osagai gehienak bezala, sare-politikak izen-espazio zehatz batean bizi dira. Blokean metadata politika zein espaziori dagokion zehaztu dezakezu:

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

Izen-espazioa metadatuetan esplizituki zehazten ez bada, sistemak kubectl-en zehaztutako izen-espazioa erabiliko du (lehenespenez namespace=default):

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

gomendatzen dut zehaztu izen-espazioa esplizituki, izen-espazio anitz aldi berean helburu dituen politika bat idazten ari ez bazara behintzat.

Nagusia elementu podSelector politikan, politikari dagokion izen-espazioko podsak hautatuko ditu (beste izen-espazio bateko podsetarako sarbidea ukatzen zaio).

Era berean, podSelectors sarrera eta irteera blokeetan beren izen-espaziotik bakarrik hauta ditzake lekak, horiekin konbinatzen ez badituzu noski namespaceSelector (Hori buruz eztabaidatuko da "Izen-espazioen eta leken arabera iragazi" atalean).

Politika izendatzeko arauak

Politika-izenak bakarrak dira izen-espazio berean. Espazio berean ezin dira izen bereko bi politika egon, baina espazio ezberdinetan izen bereko politikak egon daitezke. Hau erabilgarria da gidalerro bera hainbat espaziotan berriro aplikatu nahi duzunean.

Batez ere, izendatzeko metodoetako bat gustatzen zait. Izen-espazioaren izena xede-podekin konbinatzean datza. Adibidez:

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

Etiketak

Kubernetes objektuei etiketa pertsonalizatuak erantsi diezazkiekezu, adibidez, lekak eta izen-espazioak. Etiketak (labels - etiketak) hodeiko etiketen baliokideak dira. Kubernetes sareko gidalerroek etiketak erabiltzen dituzte hautatzeko lekakaplikatzen zaiena:

podSelector:
  matchLabels:
    role: db

… edo izen-espazioakaplikatzen zaien. Adibide honek dagozkien etiketak dituzten izen-espazioetako pod guztiak hautatzen ditu:

namespaceSelector:
  matchLabels:
    project: myproject

Kontuz bat: erabiltzean namespaceSelector ziurtatu hautatzen dituzun izen-espazioek etiketa zuzena dutela. Kontuan izan izen-espazio integratuak, hala nola default и kube-system, lehenespenez, ez dute etiketarik.

Etiketa bat gehi diezaiokezu honelako espazio bati:

kubectl label namespace default namespace=default

Aldi berean, izen-gunea atalean metadata benetako espazioaren izenari erreferentzia egin behar zaio, ez etiketari:

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

Iturria eta helmuga

Suebakiaren gidalerroak iturri eta helmuga dituzten arauez osatuta daude. Kubernetes sareko gidalerroak helburu baterako definitzen dira - aplikatzen zaizkien pod multzo bat - eta, ondoren, sarrera eta/edo irteera-trafikorako arauak ezartzen dira. Gure adibidean, politikaren helburua izen-eremuko pod guztiak izango dira default giltzadun etiketarekin app eta esanahia 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

Azpiatala ingress gidalerro honetan, sarrerako trafikoa irekitzen du helburuko podetara. Beste era batera esanda, sarrera da iturburua eta xedea dagokion helmuga. Era berean, irteera helmuga da eta xede iturria.

Suebaki bi arauren baliokidea da: Sarrera → Helburua; Helburua → Irteera.

Irteera eta DNS (garrantzitsua!)

Irteerako trafikoa mugatuz, arreta berezia jarri DNSari - Kubernetes-ek zerbitzu hau erabiltzen du zerbitzuak IP helbideetara mapatzeko. Adibidez, hurrengo politikak ez du funtzionatuko aplikazioa baimendu ez duzulako balance atzitu 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

DNS zerbitzurako sarbidea irekiz konpondu dezakezu:

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

Azken elementua to hutsik dago, eta, beraz, zeharka hautatzen du pod guztiak izen-espazio guztietan, ahalbidetuz balance bidali DNS kontsultak Kubernetes zerbitzu egokiari (normalean espazioan exekutatzen da kube-system).

Ikuspegi honek funtzionatzen du, hala ere gehiegi permisiboa eta ziurgabea, DNS kontsultak clusterretik kanpo bideratzeko aukera ematen duelako.

Hiru urrats jarraian hobetu dezakezu.

1. Onartu DNS kontsultak soilik barruan multzoa gehituz 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. Onartu DNS kontsultak izen-eremuan soilik kube-system.

Horretarako etiketa bat gehitu behar diozu izen-espazioari kube-system: kubectl label namespace kube-system namespace=kube-system - eta idatzi politika erabiliz 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. Jende paranoikoak are urrunago joan daitezke eta DNS kontsultak DNS zerbitzu jakin batera mugatu ditzakete kube-system. "Izen-espazioen arabera Iragazi ETA lekaren arabera" atalean hori nola lortu esango da.

Beste aukera bat da DNS izen-espazio mailan ebaztea. Kasu honetan, ez da zerbitzu bakoitzerako ireki beharko:

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

Hutsik podSelector izen-eremuko pod guztiak hautatzen ditu.

Lehenengo partida eta arau-ordena

Ohiko suebakietan, pakete baten ekintza (Baimendu edo Ukatu) betetzen duen lehen arauaren arabera zehazten da. Kubernetesen, politiken ordenak ez du axola.

Lehenespenez, politikak ezartzen ez direnean, poden arteko komunikazioak onartzen dira eta informazioa libreki truka dezakete. Politikak formulatzen hasten zarenean, gutxienez horietako batek eragindako pod bakoitza isolatu egiten da hautatu duten politika guztien disjuntzioaren arabera (EDO logikoa). Inongo gidalerrok eragiten ez duten ontziek irekita jarraitzen dute.

Portaera hori aldatzeko arau bat erabiliz alda dezakezu.

Ezabatzeko araua ("Ukatu")

Suebaki-politikek normalean berariaz onartzen ez den trafikoa ukatzen dute.

Kubernetesen ez dago ukatze ekintzarik, hala ere, antzeko efektua lor daiteke ohiko politika (baimendun) batekin iturburu-talde huts bat hautatuz (sarrera):

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

Gidalerro honek izen-eremuko pod guztiak hautatzen ditu eta sarrera zehaztu gabe uzten du, sarrerako trafiko guztia ukatuz.

Era berean, izen-eremu batetik irteerako trafiko guztia muga dezakezu:

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

Mesedez, kontutan izan Izen-espazioko pods-en trafikoa baimentzen duten politika gehigarriek lehentasuna izango dute arau honen gainetik (suebakiaren konfigurazio batean baimentzeko araua ukatzeko arauaren aurretik gehitzearen antzekoa).

Baimendu dena (Edozein-Edozein-Edozein-Baimendu)

Baimendu guztiak politika sortzeko, goiko Ukatu politika elementu huts batekin osatu behar duzu ingress:

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

Bertatik sartzeko aukera ematen du izen-espazio guztietako pods guztiak (eta IP guztiak) izen-eremuko edozein podetara default. Portaera hau lehenespenez gaituta dago, beraz, normalean ez da gehiago definitu behar. Hala ere, batzuetan arazoa diagnostikatzeko baimen zehatz batzuk aldi baterako desgaitu beharko dituzu.

Araua murriztu daiteke soilik sarbidea uzteko leka multzo zehatz bat (app:balance) izen-eremuan default:

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

Honako politika honek sarrera-irteera-trafiko guztia onartzen du, klusterretik kanpoko edozein IPrako sarbidea barne:

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

Politika anitz konbinatuz

Politikak hiru mailatan EDO logikoa erabiliz konbinatzen dira; Pod bakoitzaren baimenak eragina duten politika guztien bereizketaren arabera ezartzen dira:

1. Eremuetan from и to Hiru elementu mota defini daitezke (guztiak OR erabiliz konbinatuta):

• namespaceSelector — izen-espazio osoa hautatzen du;
• podSelector — lekak hautatzen ditu;
• ipBlock — azpisare bat hautatzen du.

Gainera, azpiataletako elementu kopurua (berdinak ere bai). from/to ez mugatuta. Horiek guztiak EDO logikoaren bidez konbinatuko dira.

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. Politika atalaren barruan ingress elementu asko izan ditzake from (EDO logikoaren bidez konbinatuta). Era berean, atala egress elementu asko izan ditzake to (disjunkzio bidez ere konbinatuta):

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. Politika desberdinak EDO logikoarekin ere konbinatzen dira

Baina horiek konbinatzean, muga bat dago seinalatu zuen Chris Cooney: Kubernetes-ek politika desberdinekin soilik konbina ditzake policyTypes (Ingress edo Egress). Sarrera (edo irteera) definitzen duten gidalerroek elkar gainidatziko dute.

Izen-espazioen arteko erlazioa

Lehenespenez, izen-eremuen artean informazioa partekatzea onartzen da. Hau alda daiteke izen-espaziora irteerako eta/edo sarrerako trafikoa mugatuko duen ukatze-politika bat erabiliz (ikus goiko "Benuzketa-araua").

Izen-espazio baterako sarbidea blokeatu ondoren (ikus goiko "Benuzketa-araua"), ukatze-politikan salbuespenak egin ditzakezu izen-espazio zehatz bateko konexioak baimenduz. 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

Ondorioz, izen-espazioko pod guztiak default leketarako sarbidea izango du postgres izen-eremuan database. Baina zer gertatzen da sarbidea ireki nahi baduzu postgres izen-espazioko pod espezifikoak bakarrik default?

Iragazi izen-espazioen eta leken arabera

Kubernetes 1.11 bertsioak eta berriagoak operadoreak konbinatzeko aukera ematen du namespaceSelector и podSelector ETA logikoa erabiliz. Honela dirudi:

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

Zergatik interpretatzen da hau ohiko EDOaren ordez ETA gisa?

Kontuan izan podSelector ez da marratxo batekin hasten. YAML-n horrek esan nahi du podSelector eta bere aurrean zutik namespaceSelector erreferentzia zerrendako elementu berari. Horregatik, ETA logikoarekin konbinatzen dira.

Aurretik marratxo bat gehitzea podSelector zerrenda-elementu berri bat sortuko da, aurrekoarekin konbinatuko dena namespaceSelector EDO logikoa erabiliz.

Etiketa zehatz bat duten lekak hautatzeko izen-espazio guztietan, idatzi hutsik 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

Hainbat etiketa elkartzen dira I-rekin

Hainbat objektu dituen suebaki baten arauak (ostalariak, sareak, taldeak) EDO logikoa erabiliz konbinatzen dira. Ondorengo arauak funtzionatuko du pakete-iturburua bat badator Host_1 OR Host_2:

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

Aitzitik, Kubernetes-en hainbat etiketa podSelector edo namespaceSelector ETA logikoarekin konbinatzen dira. Adibidez, hurrengo arauak bi etiketak dituzten lekak hautatuko ditu. role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

Logika bera aplikatzen zaie mota guztietako operadoreei: politika-helburuen hautatzaileak, pod hautatzaileak eta izen-espazioen hautatzaileak.

Azpisareak eta IP helbideak (IPBlocks)

Suebakiek VLANak, IP helbideak eta azpisareak erabiltzen dituzte sare bat segmentatzeko.

Kubernetes-en, IP helbideak automatikoki esleitzen zaizkie podei eta maiz alda daitezke; beraz, etiketak erabiltzen dira sareko gidalerroetan lekak eta izen-eremuak hautatzeko.

Azpisareak (ipBlocks) sarrerako (sarrera) edo irteerako (irteera) kanpoko (Ipar-Hego) konexioak kudeatzeko erabiltzen dira. Esate baterako, gidalerro hau izen-eremuko pod guztietara irekitzen da default Google DNS zerbitzurako sarbidea:

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

Adibide honetako pod hautatzaileak "hautatu izen-eremuko pod guztiak" esan nahi du.

Gidalerro honek 8.8.8.8rako sarbidea bakarrik onartzen du; Debekatuta dago beste edozein IPrako sarbidea. Beraz, funtsean, Kubernetes barneko DNS zerbitzurako sarbidea blokeatu duzu. Oraindik ireki nahi baduzu, adierazi hau esplizituki.

Normalean ipBlocks и podSelectors elkarren artean esklusiboak dira, poden barne IP helbideak ez baitira erabiltzen ipBlocks. Adieraziz barneko IP podak, helbide hauek dituzten podsetarako/etxeetatik konexioak baimenduko dituzu. Praktikan, ez duzu jakingo zein IP helbide erabili behar duzun, horregatik ez dira erabili behar pods hautatzeko.

Kontra-adibide gisa, honako gidalerro honek IP guztiak barne hartzen ditu eta, beraz, gainerako pod guztietarako sarbidea ahalbidetzen du:

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

Kanpoko IPetarako sarbidea ireki dezakezu soilik, poden barne IP helbideak kenduta. Adibidez, zure pod-aren azpisarea 10.16.0.0/14 bada:

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

Portuak eta protokoloak

Normalean podek ataka bat entzuten dute. Horrek esan nahi du ezin duzula ataka-zenbakiak gidalerroetan zehaztu eta dena lehenetsi gisa utzi. Hala ere, politikak ahalik eta murriztaileenak egitea gomendatzen da, eta, beraz, kasu batzuetan oraindik portuak zehaztu ditzakezu:

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

Kontuan izan hautatzaileak ports blokeko elementu guztiei aplikatzen zaie to edo from, daukana. Elementu multzo ezberdinetarako ataka desberdinak zehazteko, zatitu ingress edo egress hainbat azpiataletan to edo from eta erregistro bakoitzean zure portuak:

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

Portuaren funtzionamendu lehenetsia:

• Portuaren definizioa guztiz baztertzen baduzu (ports), horrek protokolo guztiak eta portu guztiak esan nahi du;
• Protokoloaren definizioa baztertzen baduzu (protocol), honek TCP esan nahi du;
• Portuaren definizioa baztertzen baduzu (port), honek portu guztiak esan nahi du.

Praktika onena: ez fidatu balio lehenetsietan, zehaztu behar duzuna esplizituki.

Kontuan izan pod portuak erabili behar dituzula, ez zerbitzu atakak (horri buruzko informazio gehiago hurrengo paragrafoan).

Zehazten al dira politikak pod edo zerbitzuetarako?

Normalean, Kubernetes-eko podak zerbitzu baten bidez sartzen dira elkarren artean; karga-orekatzaile birtual bat, trafikoa zerbitzua ezartzen duten podetara birbideratzen du. Pentsa dezakezu sare-politikek zerbitzuetarako sarbidea kontrolatzen dutela, baina ez da horrela. Kubernetes sareko politikek pod portuetan funtzionatzen dute, ez zerbitzu ataketan.

Adibidez, zerbitzu batek 80 ataka entzuten badu, baina trafikoa bere poden 8080 atakara birbideratzen badu, 8080 zehatz-mehatz zehaztu behar duzu sare-politikan.

Mekanismo hori ezin hobetzat jo behar da: zerbitzuaren barne-egitura (podek entzuten dituzten atakak) aldatzen bada, sare-politikak eguneratu beharko dira.

Ikuspegi arkitektoniko berria Service Mesh erabiliz (adibidez, ikusi behean Istiori buruz - gutxi gorabehera. itzul.) arazo honi aurre egiteko aukera ematen dizu.

Beharrezkoa al da Ingress eta Egress erregistratzea?

Erantzun laburra baietz da, A poda B podarekin komunikatzeko, irteerako konexio bat sortzeko baimena eman behar zaio (horretarako irteera-politika bat konfiguratu behar duzu), eta B poda sarrerako konexioa onartzeko gai izan behar du ( horretarako, horren arabera, sarrera-politika bat behar duzu).politika).

Hala ere, praktikan, politika lehenetsian fidatu zaitezke norabide batean edo bietan konexioak baimentzeko.

Pod batzuk bada-iturri batek edo gehiagok aukeratuko dute irteera-politikariei, ezarritako murrizketak haien disjuntzioak zehaztuko ditu. Kasu honetan, espresuki baimendu beharko duzu podarekin konexioa -hartzailea. Inongo politikaren arabera pod bat hautatzen ez bada, bere irteerako (irteera) trafikoa onartzen da lehenespenez.

Era berean, lekaren patua dahartzailea, batek edo gehiagok hautatuta sarrera-politikariak, haien disjuntzioaren arabera zehaztuko da. Kasu honetan, espresuki baimendu behar diozu iturburuko ontzitik trafikoa jasotzea. Inongo politikaren arabera pod bat hautatzen ez bada, sarrerako trafiko guztia lehenespenez onartzen da.

Ikus behean Estaturik gabekoa edo Estaturik gabekoa.

Erregistroak

Kubernetes sareko gidalerroek ezin dute trafikoa erregistratu. Horrek zaildu egiten du politika batek nahi bezala funtzionatzen duen ala ez zehaztea eta asko zailtzen du segurtasun-analisia.

Kanpoko zerbitzuetarako trafikoaren kontrola

Kubernetes sareko gidalerroek ez dizute uzten guztiz kualifikatutako domeinu-izen bat (DNS) zehaztea irteerako ataletan. Gertaera horrek eragozpen handiak eragiten ditu IP helbide finkorik ez duten kanpoko helmugetara trafikoa mugatzen saiatzean (aws.com adibidez).

Politikaren egiaztapena

Suebakiek politika okerra onartzeari uko egingo dizute edo ohartaraziko dizute. Kubernetes-ek egiaztapen batzuk ere egiten ditu. Kubectl-en bidez sare-politika ezartzean, Kubernetes-ek okerra dela deklaratu dezake eta onartzeari uko egin diezaioke. Beste kasu batzuetan, Kubernetes-ek politika hartuko du eta falta diren xehetasunekin beteko du. Komandoa erabiliz ikus daitezke:

kubernetes get networkpolicy <policy-name> -o yaml

Kontuan izan Kubernetes baliozkotzeko sistema ez dela hutsezina eta errore mota batzuk galdu ditzakeela.

Execution

Kubernetes-ek ez ditu sare-politikak berez ezartzen, edukiontzien sareko interfazea (CNI) izeneko azpiko sistema bati kontrolaren zama API atebide bat besterik ez da. Kubernetes kluster batean politikak ezartzea CNI egokia esleitu gabe, suebakien kudeaketa zerbitzari batean politikak sortzearen berdina da, gero suebakietan instalatu gabe. Zure esku dago CNI duin bat duzula ziurtatzea edo, Kubernetes plataformen kasuan, hodeian ostatatuta duzula. (hornitzaileen zerrenda ikus dezakezu Hemen — gutxi gorabehera. trans.), gaitu CNI ezarriko dizuten sare-politikak.

Kontuan izan Kubernetes-ek ez zaituela ohartaraziko sare-politika bat ezartzen baduzu CNI laguntzaile egokirik gabe.

Estatuduna edo Estaturik gabekoa?

Topatu ditudan Kubernetes CNI guztiak egoera egoeran daude (adibidez, Calicok Linux conntrack erabiltzen du). Horri esker, pod-ak hasitako TCP konexioan erantzunak jaso ditzake berriro ezarri beharrik gabe. Hala ere, ez naiz ezagutzen egoera-egoera bermatuko lukeen Kubernetes estandarrik.

Segurtasun Politiken Kudeaketa Aurreratua

Hona hemen Kubernetesen segurtasun-politikak betearaztea hobetzeko modu batzuk:

1. Service Mesh eredu arkitektonikoak sidecar edukiontziak erabiltzen ditu telemetria zehatza eta trafikoa kontrolatzeko zerbitzu mailan. Adibide gisa har dezakegu Istio.
2. CNIren saltzaile batzuek beren tresnak zabaldu dituzte Kubernetes sareko politiketatik harago joateko.
3. Tufin Orca Kubernetes sareko politiken ikusgarritasuna eta automatizazioa eskaintzen ditu.

Tufin Orca paketeak Kubernetes sareko politikak kudeatzen ditu (eta goiko pantaila-argazkien iturria da).

Informazio osagarria

• GKEko Ahmet Alp Balkanek prestatutako sare-politiken adibideak;
• Kubernetes webgune ofizialeko dokumentazioa;
• Kubernetes sareko ereduaren gida;
• Sare-politikak egiaztatzeko scripta.

Ondorioa

Kubernetes sare-politikek klusterrak segmentatzeko tresna multzo on bat eskaintzen dute, baina ez dira intuitiboak eta ñabardura asko dituzte. Konplexutasun hori dela eta, lehendik dauden kluster-politika asko akatsak direla uste dut. Arazo honen konponbide posibleak politikaren definizioak automatizatzea edo beste segmentazio tresna batzuk erabiltzea dira.

Espero dut gida honek galdera batzuk argitzen eta aurki ditzakezun arazoak konpontzen laguntzea.

PS itzultzailetik

Irakurri ere gure blogean:

• "Itzuli mikrozerbitzuetara Istio-rekin": 1. zatia (ezaugarri nagusien sarrera), 2. zatia (bideratzea, trafikoa kontrolatzea), 3. zatia (segurtasuna);
• "Kubernetes-en sareak egiteko gida ilustratua": 1. eta 2. zatiak (sare-eredua, gainjarritako sareak), 3. zatia (zerbitzuak eta trafikoaren tratamendua);
• «Docker eta Kubernetes segurtasuna eskatzen duten inguruneetan»;
• «Kubernetes segurtasunerako 9 praktika onak»;
• «11 modu (Ez) Kubernetes Hack baten biktima bihurtzeko'.

Iturria: www.habr.com