Una Introduzione à e Politiche di Rete Kubernetes per i Prufessiunali di Sicurezza

Nota. transl.: L'autore di l'articulu - Reuven Harrison - hà più di 20 anni di sperienza in u sviluppu di software, è oghje hè u CTO è cofundatore di Tufin, una cumpagnia di soluzioni di gestione di pulitica di sicurezza. Mentre cunsidereghja e pulitiche di a rete Kubernetes per esse abbastanza putenti per segmentà a reta in un cluster, crede ancu chì ùn sò micca cusì faciuli di implementà in pratica. Stu materiale (piuttostu voluminoso) hè destinatu à migliurà a cuscenza di i specialisti in questa materia è aiutanu à creà e cunfigurazioni necessarii.

Oghje, parechje cumpagnie sceglienu sempre più Kubernetes per eseguisce e so applicazioni. L'interessu in questu software hè cusì altu chì certi chjamanu Kubernetes "u novu sistema operatore per i centri di dati". Pocu à pocu, Kubernetes (o k8s) hè cuminciatu à esse percive cum'è una parte critica di l'affari, chì esige l'urganizazione di prucessi di cummerciale maturi, cumpresa a sicurità di a rete.

Per i prufessiunali di sicurità chì sò stati perplessi cù u travagliu cù Kubernetes, a pulitica predeterminata di sta piattaforma pò esse una vera scuperta: permette tuttu.

Sta guida vi aiuterà à capisce u funziunamentu internu di e pulitiche di rete; capiscenu cumu si sò diffirenti da e regule per i firewalls regulari. Parlarà ancu di alcune di e trappule è dà cunsiglii chì aiutanu à prutege l'applicazioni in Kubernetes.

Politiche di rete Kubernetes

U mecanismu di a pulitica di a rete Kubernetes permette di gestisce l'interazzione di l'applicazioni implementate nantu à a piattaforma à a capa di a reta (u terzu in u mudellu OSI). I pulitichi di a rete ùn mancanu alcune di e funzioni avanzate di i firewall muderni, cum'è u cuntrollu di a capa OSI 7 è a rilevazione di minacce, ma furnisce una strata basica di sicurezza di rete chì hè un bonu puntu di partenza.

E pulitiche di rete cuntrolanu e cumunicazioni trà pods

I carichi di travagliu in Kubernetes sò distribuiti in pods, chì sò custituiti da unu o più cuntenituri disposti inseme. Kubernetes assigna à ogni pod un indirizzu IP accessibile da altri pods. E pulitiche di a rete Kubernetes stabiliscenu permessi d'accessu per i gruppi di pods in u listessu modu chì i gruppi di sicurezza in u nuvulu sò usati per cuntrullà l'accessu à l'istanze di a macchina virtuale.

Definizione di e pulitiche di rete

Cum'è l'altri risorse Kubernetes, e pulitiche di rete sò stabilite in YAML. In l'esempiu sottu, l'applicazione balance apre l'accessu à 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

(Nota. transl.: sta screenshot, cum'è tutti i screenshots simili successivi, ùn hè micca stata creata cù l'arnesi nativi di Kubernetes, ma cù u strumentu Tufin Orca, chì hè statu sviluppatu da a cumpagnia di l'autore di l'articulu originale è chì hè citatu à a fine di u materiale.)

A cunniscenza basica di YAML hè necessaria per definisce a vostra propria pulitica di rete. Sta lingua hè basatu annantu à l'indentazione (specificata da spazii, micca tabulazioni). L'elementu indentatu appartene à l'elementu indentatu più vicinu sopra. U novu elementu di a lista principia cù un trattu, tutti l'altri elementi sò di a forma chjave-valore.

Dopu avè descrittu a pulitica in YAML, utilizate kubectlper creà lu in u cluster:

kubectl create -f policy.yaml

Specificazione di a pulitica di a rete

A specificazione di a pulitica di a rete Kubernetes include quattru elementi:

1. podSelector: definisce i pods affettati da sta pulitica (obiettivi) - necessariu;
2. policyTypes: indica chì tippi di pulitiche sò inclusi in questu: ingressu è / o egress - facultativu, ma ricumandemu di specificà esplicitamente in tutti i casi;
3. ingress: definisce permessu in entrata trafficu per target pods - facultativu;
4. egress: definisce permessu in uscita u trafficu da i pods di destinazione hè facultativu.

Un esempiu prestitu da u situ Kubernetes (aghju rimpiazzatu role nantu app), mostra cumu i quattru elementi sò usati:

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

Nota chì ùn hè micca necessariu di include tutti i quattru elementi. Hè solu necessariu podSelector, u restu di i paràmetri pò esse usatu cum'è vulete.

Se omettemu policyTypes, a pulitica serà interpretata cusì:

• Hè assumatu per difettu per definisce u latu di ingressu. Se a pulitica ùn indica micca esplicitamente questu, u sistema assumerà chì tuttu u trafficu hè pruibitu.
• U cumpurtamentu in u latu di egressu serà determinatu da a prisenza o l'absenza di u paràmetru di egress currispondente.

Per evitari sbagli, vi cunsigliu esse sempre esplicitu policyTypes.

Sicondu a logica sopra, in casu i paràmetri ingress è / o egress omessa, a pulitica denegarà tuttu u trafficu (vede "Regula di Sweep" sottu).

Pulitica predeterminata - permette

Sì nisuna pulitica hè definita, Kubernetes permette tuttu u trafficu per automaticamente. Tutti i pods ponu scambià liberamente infurmazione cù l'altri. Da u puntu di vista di a sicurità, questu pò esse contru à l'intuitivu, ma ricordate chì Kubernetes hè stata creata in origine da sviluppatori cù u scopu di rende l'applicazioni interoperabili. E pulitiche di rete sò state aghjunte dopu.

Spazi di nomi

I namespaces sò u mecanismu di cullaburazione Kubernetes. Sò pensati per isolà ambienti lògichi l'una di l'altru, mentre permettenu a cumunicazione trà i spazii per difettu.

Cum'è a maiò parte di i cumpunenti di Kubernetes, e pulitiche di rete campanu in un spaziu di nome specificu. In u bloccu metadata pudete specificà à quale spaziu appartene a pulitica:

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

Se u spaziu di nomi ùn hè micca esplicitamente specificatu in i metadati, u sistema utilizerà u spaziu di nomi specificatu in kubectl (predeterminatu namespace=default):

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

Vi cunsigliu specificà u spaziu di nomi esplicitamente, salvu chì scrivite una pulitica chì mira à parechji spazii di nomi à una volta.

Principale elementu podSelector in a pulitica selezziunate pods da u namespace à quale a pulitica appartene (ùn hà micca accessu à pods da un altru namespace).

In listessu modu, podSelectors in blocchi di entrata è di uscita ponu selezziunà solu pods da u so propiu spaziu di nomi, salvu chì, sicuru, ùn li combina cun namespaceSelector (Questu serà discututu in a sezione "Filtra per spazii di nomi è pods").

Reguli di Nominazione di Politiche

I nomi di pulitica sò unichi in u stessu spaziu di nomi. Ùn ci ponu esse dui pulitiche cù u stessu nome in u stessu spaziu, ma ponu esse pulitiche cù u listessu nome in spazii diffirenti. Questu hè utile quandu vulete riapplicà a stessa pulitica in parechje spazii.

Mi piace soprattuttu unu di i metudi di nomi. Hè custituitu di concatenate u nome di u spaziu di nome cù i pods di destinazione. Per esempiu:

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

Etichette

L'etichetti persunalizati ponu esse attaccati à l'uggetti Kubernetes, cum'è pods è spazii di nomi. etichette (etichetti tags) sò l'equivalenti di tag in u nuvulu. I pulitichi di a rete di Kubernetes utilizanu etichette per selezziunà baccellià quale si applicanu:

podSelector:
  matchLabels:
    role: db

… o spazii di nomià quale si applicanu. Questu esempiu selezziunate tutti i pods in spazii di nomi cù etichette currispondenti:

namespaceSelector:
  matchLabels:
    project: myproject

Un avvertimentu: quandu si usa namespaceSelector assicuratevi chì i spazii di nomi chì selezziunate cuntenenu l'etichetta curretta. Siate cuscenti chì i spazii di nomi integrati cum'è default и kube-system, ùn cuntene micca etichette per difettu.

Pudete aghjunghje una etichetta à un spaziu cum'è questu:

kubectl label namespace default namespace=default

In questu casu, u namespace in a rùbbrica metadata deve riferite à u nome propiu di u spaziu, micca l'etichetta:

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

Fonte è destinazione

I pulitiche di u firewall sò custituiti da e regule d'origine è di destinazione. E pulitiche di a rete Kubernetes sò definite per destinazione, l'inseme di pods chì si applicanu, è poi stabilisce e regule per u trafficu di ingressu è / o di egressu. In u nostru esempiu, u scopu di pulitica serà tutti i pods in u namespace default cù l'etichetta chjave app è significatu 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

Subsection ingress in questa pulitica apre u trafficu entrante per target pods. In altri palori, l'ingressu hè a fonte è a destinazione hè a destinazione currispondente. In listessu modu, l'egress hè u destinazione, è u mira hè a so fonte.

Questu hè equivalente à duie regule di firewall: Ingress → Target; Target → Egress.

Egressu è DNS (impurtante!)

Restrizzione di u trafficu in uscita Prestate una attenzione particulare à DNS - Kubernetes usa stu serviziu per mappe i servizii à l'indirizzi IP. Per esempiu, a seguente pulitica ùn hà micca travagliatu perchè ùn avete micca permessu l'applicazione balance accede à 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

Pudete riparà aprendu l'accessu à u serviziu DNS:

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

Ultimu elementu to hè viotu, è cusì sceglie indirettamente tutti i pods in tutti i namespaces, permettendu balance Mandate e dumande DNS à u serviziu Kubernetes appropritatu (di solitu corre in u spaziu kube-system).

Stu approcciu travaglia, però eccessivamente permissive è insicuru, perchè vi permette di diretta e dumande DNS fora di u cluster.

Pudete migliurà in trè passi consecutivi.

1. Permette solu e dumande DNS ind'u cluster agghiuncennu 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. Permette e dumande DNS solu in u spaziu di nomi kube-system.

Per fà questu, avete bisognu di aghjunghje una etichetta à u namespace kube-system: kubectl label namespace kube-system namespace=kube-system - è arregistrallu in a pulitica usendu 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. Paranoids pò andà ancu più luntanu è limità e dumande DNS à un serviziu DNS specifichi in kube-system. A sezione "Filtra per spazii di nomi E pods" vi mostrarà cumu fà questu.

Un'altra opzione hè di risolve DNS à u livellu di u namespace. In questu casu, ùn deve esse apertu per ogni serviziu:

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

Viotu podSelector selezziunà tutti i pods in u namespace.

Prima partita è ordine di regula

In i firewalls cunvinziunali, l'azzione (Permette o Deny) nantu à un pacchettu hè determinata da a prima regula chì satisface. In Kubernetes, l'ordine di e pulitiche ùn importa micca.

Per automaticamente, quandu ùn sò micca stabilite pulitiche, a cumunicazione trà pods hè permessa è ponu scambià infurmazioni liberamente. Appena principiatu à furmulà e pulitiche, ogni poda affettata da almenu una di elle diventa isolata secondu a disjunzione (OR logica) di tutte e pulitiche chì l'anu sceltu. I podi chì ùn sò micca affettati da alcuna pulitica restanu aperti.

Pudete cambià stu cumpurtamentu cù una regula di sweep.

Regula di Pulizia ("Proibisce")

E pulitiche di firewall generalmente deneganu ogni trafficu chì ùn hè micca esplicitamente permessu.

Kubernetes ùn hà micca una azzione "nega"., ma u listessu effettu pò esse ottenutu cù una pulitica normale (permissiva) selezziunendu un gruppu vacanti di baccelli di fonte (ingress):

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

Questa pulitica selezziunate tutti i pods in u spaziu di nomi è lascia l'ingressu indefinitu, denegando tuttu u trafficu entrante.

In listessu modu, pudete limità tuttu u trafficu in uscita da u spaziu di nomi:

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

Innota chì qualsiasi pulitiche supplementari chì permettenu u trafficu à i pods in u spaziu di nomi hà da esse a priorità nantu à sta regula (simile à aghjunghje una regula permessa prima di una regula di denegazione in a cunfigurazione di u firewall).

Permette tutti (Qualunque-Qualunque-Permette)

Per creà una pulitica "Allow All", avete bisognu di cumplementà a pulitica di denegazione sopra cù un elementu viotu ingress:

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

Offre accessu à tutti i pods in tutti i namespaces (è tutti l'IP) à qualsiasi pod in u namespace default. Stu cumpurtamentu hè attivatu per automaticamente, per quessa, di solitu ùn hè micca bisognu di più definitu. Tuttavia, qualchì volta pò esse necessariu disattivà temporaneamente certi permessi specifichi per diagnosticà u prublema.

A regula pò esse ristretta per permette solu l'accessu un gruppu specificu di pods (app:balance) in u spaziu di nomi default:

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

A seguente pulitica permette à tuttu u trafficu entrante (ingressu) È in uscita (egress), cumpresu l'accessu à qualsiasi IP fora di u cluster:

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

Cumminendu Politiche Multiple

I pulitichi sò logicamente ORed à trè livelli; I permessi di ogni pod sò stabiliti secondu a disjunzione di tutte e pulitiche chì l'affettanu:

1. In i campi from и to ponu esse definiti trè tippi di elementi (tutti cumminati cù OR):

• namespaceSelector - selezziunà tuttu u spaziu di nomi;
• podSelector - selezziunà i baccelli;
• ipBlock - sceglie una subnet.

À u listessu tempu, u numeru di elementi (ancu i stessi) in subsections from/to micca limitatu. Tutti seranu cumminati cù un OR logicu.

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. Dentru seccione pulitica ingress pò avè parechji elementi from (cumbinatu da OR logica). In listessu modu, sezione egress pò include parechji elementi to (cumbinatu ancu da disjunzione):

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. Diversi pulitiche sò ancu cumminati cù un OR logicu

Ma quandu sò cumminati, ci hè una restrizzione nantu à quale hà signalatu Chris Cooney: Kubernetes pò solu combine pulitiche cù diverse policyTypes (Ingress o Egress). E pulitiche chì definiscenu l'ingress (o egress) si sovrascriveranu l'una l'altra.

Relazione trà spazii di nomi

Per automaticamente, u scambiu d'infurmazioni trà spazii di nomi hè permessu. Questu pò esse cambiatu cù una pulitica restrittiva chì restringe u trafficu in uscita è / o in entrata à u spaziu di nomi (vede "Regula Sweep" sopra).

Bluccà l'accessu à un spaziu di nomi (vede "Regula di Sweep" sopra), pudete fà eccezzioni à a pulitica di denegazione permettendu cunnessione da un spaziu di nomi specificu cù 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

In u risultatu, tutti i pods in u namespace default accede à i pods postgres in namespace database. Ma chì si vulete apre l'accessu postgres solu pods specifichi in u namespace default?

Filtrà per namespaces E pods

Kubernetes versione 1.11 è sopra permette di cumminà l'operatori namespaceSelector и podSelector usendu AND logicu. Sembra cusì:

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

Perchè hè interpretatu cum'è AND invece di u solitu OR?

nutate chì podSelector ùn principia micca cù un trattino. In YAML questu significa chì podSelector è stà davanti à ellu namespaceSelector riferite à u listessu elementu di lista. Per quessa, sò cumminati cù un AND lògicu.

Aghjunghjite un trattu prima podSelector resultarà in un novu elementu di lista chì serà cumminatu cù u precedente namespaceSelector utilizendu OR logicu.

Per selezziunà pods cù una etichetta specifica in tutti i namespaces, entre viotu 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

Più etichette combinate cù AND

I reguli di firewall cù parechje entità (ospiti, rete, gruppi) sò cumminati cù un OR logicu. A regula seguente spararà se a fonte di u pacchettu currisponde Host_1 OR Host_2:

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

À u cuntrariu, in Kubernetes diverse etichette in podSelector o namespaceSelector sò cumminati cù un AND lògicu. Per esempiu, a regula seguente selezziunà pods chì anu e duie etichette, role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

A stessa logica s'applica à tutti i tipi di dichjarazioni: selettori di destinazione di pulitica, selettori di pod, è selettori di spazii di nomi.

Subnets è indirizzi IP (IPBlocks)

I firewalls utilizanu VLAN, indirizzi IP è subnets per segmentà una reta.

In Kubernetes, l'indirizzi IP sò automaticamente assignati à pods è ponu cambià spessu, cusì l'etichette sò aduprate per selezziunà pods è namespaces in e pulitiche di rete.

Subnets (ipBlocks) sò usati per gestisce e cunnessione esterne (Nord-Sud) in entrata (ingress) o in uscita (uscita). Per esempiu, sta pulitica apre tutti i pods da u namespace default accessu à u serviziu di Google DNS:

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

U selettore di pod viotu in questu esempiu significa "select all pods in the namespace".

Sta pulitica permette solu accessu à 8.8.8.8; l'accessu à qualsiasi altru IP hè pruibitu. Dunque, in essenza, avete bluccatu l'accessu à u serviziu internu di Kubernetes DNS. Se vulete ancu apre, specificate esplicitamente.

n gèniri ipBlocks и podSelectors sò mutualmente esclusivi, postu chì l'indirizzi IP interni di i pods ùn sò micca usati ipBlocks. Puntendu pods IP interni, In realtà permetterà cunnessione à / da pods cù quelli indirizzi. In pratica, ùn sapete micca quale indirizzu IP aduprà, per quessa ùn avete micca aduprà per selezziunà pods.

Comu contraesempiu, a seguente pulitica include tutte l'IP è dunque permette l'accessu à tutti l'altri pods:

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

Pudete apre l'accessu solu à l'IP esterni, senza l'indirizzi IP interni di i pods. Per esempiu, se a subnet di u vostru pod hè 10.16.0.0/14:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-any
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 10.16.0.0/14

Porti è Protocolli

Di solitu i pods ascoltanu nantu à un portu. Questu significa chì pudete simpricimenti lascià i numeri di portu in i vostri pulitiche è lasciate tuttu in modu predeterminatu. Tuttavia, hè cunsigliatu di fà e pulitiche u più restrittive pussibule, cusì in certi casi pudete sempre specificà porti:

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

Nota chì u selettore ports s'applica à tutti l'elementi in u bloccu to o from, chì cuntene. Per specificà diversi porti per i diversi setti di elementi, rompe ingress o egress in parechje sottosezzioni to o from è in ogni scrive i vostri porti:

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

I porti predeterminati funzionanu:

• Se omette completamente a definizione di porti (ports), chì significa tutti i protokolli è tutti i porti;
• Se omette a definizione di u protocolu (protocol), chì significa TCP;
• Se omette a definizione di u portu (port), chì significa tutti i porti.

Best Practice: Ùn fate micca fiducia in i valori predeterminati, specificate ciò chì avete bisognu esplicitamente.

Nota chì avete bisognu di usà i porti di pod, micca i servizii (più nantu à questu in u paràgrafu prossimu).

Politiche definite per pods o servizii?

Di solitu, i pods in Kubernetes cumunicanu cù l'altri per mezu di un serviziu - un equilibratore di carica virtuale chì redirige u trafficu à i pods chì implementanu u serviziu. Puderete pensà chì e pulitiche di rete cuntrollanu l'accessu à i servizii, ma ùn hè micca u casu. E pulitiche di a rete di Kubernetes funzionanu cù porti pod, micca servizii.

Per esempiu, se un serviziu à sente in u portu 80, ma redirige u trafficu à u portu 8080 di i so pods, deve specificà 8080 in a pulitica di a rete.

Un tali mecanismu deve esse ricunnisciutu cum'è suboptimal: se u dispusitivu internu di u serviziu (i porti di quale ascolta pods) cambia, e pulitiche di a rete anu da esse aghjurnata.

Novu approcciu architettonicu utilizendu Service Mesh (per esempiu, vede nantu à Istio sottu - circa trad.) permette di trattà stu prublema.

Hè necessariu di scrive l'Ingress è l'Egress?

A risposta corta hè sì, per chì u pod A cumunicà cù u pod B, avete bisognu di permette di creà una cunnessione in uscita (per questu avete bisognu di cunfigurà a pulitica di uscita), è u pod B deve esse capace di accettà una cunnessione in entrata. (per questu, per quessa, avete bisognu di pulitica di ingressu).

In ogni casu, in pratica, pudete confià nantu à a pulitica predeterminata per permette e cunnessione in una o duie direzzione.

Se qualchì pod-fonti serà sceltu da unu o più uscita-pulitici, e restrizioni imposte à ellu seranu determinate da a so disjunzione. In questu casu, avete bisognu di permette esplicitamente a cunnessione à u poddestinatariu. Se un pod ùn hè micca sceltu da alcuna pulitica, u so trafficu in uscita (egress) hè permessu per automaticamente.

In listessu modu, u destinu di u pod'a-destinatariusceltu da unu o più ingress-pulitiche seranu determinate da a so disjunzione. In questu casu, deve esse esplicitamente permettenu di riceve u trafficu da u pod di fonte. Se un pod ùn hè micca sceltu da alcuna pulitica, tuttu u trafficu ingressu hè permessu per automaticamente.

Vede "Stateful o Stateless" sottu.

Logs

I pulitichi di a rete di Kubernetes ùn sanu micca cumu logu u trafficu. Questu rende difficiuli di determinà se una pulitica funziona cum'è prevista è rende l'analisi di sicurezza assai difficili.

U cuntrollu di u trafficu à i servizii esterni

E pulitiche di a rete di Kubernetes ùn permettenu micca di specificà un nome di duminiu cumplettamente qualificatu (DNS) in e sezioni di egress. Stu fattu porta à un inconveniente significativu quandu si prova di limità u trafficu à destinazioni esterni chì ùn anu micca un indirizzu IP fissu (cum'è aws.com).

Cuntrolla di pulitica

Firewalls vi avvisanu o ancu ricusate di accettà una pulitica erronea. Kubernetes faci ancu una verificazione. Quandu stabilisce una pulitica di rete via kubectl, Kubernetes pò dichjarà chì a pulitica hè incorrecta è ricusà di accettà. In altri casi, Kubernetes pigliarà a pulitica è l'incarcerà cù i dettagli mancanti. Pudete vede cù u cumandamentu:

kubernetes get networkpolicy <policy-name> -o yaml

Tenite in mente chì u sistema di validazione di Kubernetes ùn hè micca infallibile è pò missu certi tipi d'errori.

Esecutà

Kubernetes ùn impone micca e pulitiche di rete per sè stessu, ma hè solu una porta di API chì mette u pesu di cuntrollu nantu à un sistema sottostante chjamatu Container Networking Interface (CNI). Stabbilimentu di e pulitiche nantu à un cluster Kubernetes senza assignà un CNI adattatu hè simile à stabilisce e pulitiche nantu à un servitore di gestione di firewall senza dopu mette in firewall. Tocca à voi per assicurà chì avete un CNI decentu o, in u casu di e plataforme Kubernetes, ospitate in u nuvulu. (Per una lista di i fornituri vede ccà - ca. trad.), attivate e pulitiche di rete chì stabiliscenu u CNI per voi.

Nota chì Kubernetes ùn vi avvirrà micca se stabilisce una pulitica di rete senza l'aiutu CNI adattatu.

Stateful o Stateless?

Tutti i CNI di Kubernetes chì aghju scontru sò stateful (per esempiu, Calico usa Linux conntrack). Questu permette à u pod per riceve risposte nantu à a cunnessione TCP chì hà iniziatu senza avè da ristabilisce. Tuttavia, ùn sò micca cunuscenza di un standard di Kubernetes chì guarantissi statefulness.

Gestione Avanzata di Politica di Sicurezza

Eccu alcuni modi per migliurà l'efficienza di l'applicazione di a pulitica di sicurezza in Kubernetes:

1. U mudellu architettonicu Service Mesh usa sidecars per furnisce telemetria dettagliata è cuntrollu di trafficu à u livellu di serviziu. Per esempiu, si pò piglià Istio.
2. Alcuni di i venditori CNI anu allargatu i so strumenti per andà oltre e pulitiche di a rete Kubernetes.
3. Tufin Orca furnisce trasparenza è automatizazione di e pulitiche di rete Kubernetes.

U pacchettu Tufin Orca gestisce e pulitiche di a rete Kubernetes (è hè a fonte di i screenshots sopra).

applicàrisi nantu à u corsu

• Esempi di pulitica di rete preparati da Ahmet Alp Balkan di GKE;
• Documentazione da u situ ufficiale di Kubernetes;
• Guida di mudelli di rete Kubernetes;
• Script per verificà e pulitiche di a rete.

cunchiusioni

E pulitiche di a rete di Kubernetes offrenu un bonu set di strumenti per segmentà i clusters, ma ùn sò micca intuitivi è anu parechje suttilità. Credu chì per via di sta cumplessità, e pulitiche di parechji clusters esistenti sò buggy. I pussibuli suluzioni à stu prublema sò l'automatizazione di e definizioni di pulitica o l'usu di altri strumenti di segmentazione.

Spergu chì sta guida vi aiuterà à chiarisce alcune dumande è risolve i prublemi chì pudete scontru.

PS da u traduttore

Leghjite puru nant'à u nostru blog:

• "Torna à i microservizi cù Istio": parte 1 (introduzione à e caratteristiche principali), parte 2 (routing, cuntrollu di trafficu), parte 3 (securità);
• "Una guida illustrata per a rete in Kubernetes": parte 1 è 2 (mudellu di rete, rete di overlay), parte 3 (servizii è trasfurmazioni di trafficu);
• «Docker è Kubernetes in ambienti esigenti di sicurità";
• «9 Kubernetes Best Practices di Sicurezza";
• «11 Modi per (micca) esse pirate in Kubernetes».

Source: www.habr.com