Sysdig
Learn Cloud Native

Sign up to receive our newsletter

Capire la sicurezza della rete in Kubernetes

Le reti sono un componente di Kubernetes particolarmente complesso. Possono essere configurate in molti modi diversi. Potrebbe essere utilizzata una service mesh, oppure no. Alcune risorse nel cluster potrebbero interfacciarsi solo con le reti interne, mentre altre potrebbero richiedere un accesso diretto a Internet. Porte, indirizzi IP e altri attributi di rete sono di solito configurati in modo dinamico, il che può rendere difficile tracciare quello che accade a livello di rete.

A causa di queste e di altre complessità, la gestione della sicurezza della rete Kubernetes può rivelarsi particolarmente complicata. Richiede una profonda comprensione dell’architettura della rete e una certa familiarità con gli strumenti che Kubernetes offre per proteggerla, ad esempio le policy di rete e strumenti di terze parti che possono offrire una ulteriore difesa.

Questo articolo spiega le nozioni fondamentali sulla sicurezza della rete di Kubernetes. Descrive in che modo funzionano le reti di Kubernetes, quali sono i rischi per le risorse di rete e le migliori prassi da seguire per mantenerle protette.

Kubernetes Networking 101

Il primo passo per proteggere Kubernetes a livello di rete è comprendere in che modo Kubernetes gestisce le reti. Si tratta di un argomento ampio e complesso, ma riepiloghiamo di seguito le informazioni di base che è necessario conoscere.

Scopo della rete

In Kubernetes, le reti hanno due scopi fondamentali:

  • Reti interne: Gestiscono il traffico interno che facilita le comunicazioni tra pod, nodi e altre risorse in un cluster. Tipicamente, le reti interne utilizzano sottoreti e indirizzi IP privati e sono isolate dall’Internet pubblico.
  • Reti esterne: I workload che devono connettersi a Internet utilizzano indirizzi IP pubblici.

Kube-Proxy

Il servizio che gestisce i flussi del traffico in Kubernetes è kube-proxy. Kube-proxy viene eseguito su ciascun nodo in un cluster Kubernetes e inoltra pacchetti ai container ospitati su tali nodi in base agli indirizzi IP e alle porte dei container.

Lato backend, kube-proxy si affida a servizi a livello di OS, quali ad esempio iptables in Linux, per controllare il traffico. Ma poiché kube-proxy astrae tali servizi dalle risorse Kubernetes, la sottostante gestione della rete a livello di nodo non si rivela particolarmente importante in termini di sicurezza della rete.

Plugin CNI

In molti casi, Kubernetes utilizza il plugin Container Network Interface (CNI) per creare l’interfaccia di una rete virtuale che i container possono utilizzare. I plugin CNI possono essere utilizzati per integrare Kubernetes con diverse piattaforme terze che consentono di gestire le configurazioni di rete, ad esempio quelle eseguite nativamente sui cloud pubblici (come Azure Virtual Networks e AWS Network Interfaces).

I plugin CNI sono anche disponibili a supporto di piattaforme quali Project Calico e Weave Net, progettate per offrire uno strumento di standardizzazione delle configurazioni di rete di ambienti eterogenei o ibridi (ovvero, ambienti che combinano più tipi di piattaforme, ad esempio Kubernetes e un cloud pubblico o un data center privato).

Sebbene sia tecnicamente possibile configurare le reti in Kubernetes senza utilizzare un plugin CNI, molti cluster di produzione utilizzano questo strumento per gestire le reti.

Service mesh

Oltre ai plugin CNI, i cluster di produzione di Kubernetes di solito utilizzano una service mesh per semplificare le operazioni di rete. Le service mesh automatizzano la scoperta di diverse risorse su una rete. Molte di esse offrono anche funzionalità di osservabilità e sicurezza.

Kubernetes non offre una service mesh nativa, ma può integrare molte delle più comuni service mesh quali Istio, Traefik e NGINX.

Configurazioni dinamiche

Indipendentemente dal plugin CNI, dalla service mesh e da altri strumenti di rete utilizzati con Kubernetes, le configurazioni di rete sono sempre altamente dinamiche.

In altre parole, gli indirizzi IP e le porte di nodi, pod e servizi sono configurati al bisogno, quando le risorse vengono create. Sebbene gli amministratori possano definire pool di indirizzi IP che Kubernetes utilizzerà per eseguire le assegnazioni, non è possibile assegnare indirizzi IP statici (almeno non con gli strumenti nativi di Kubernetes).

Per certi versi, le configurazioni dinamiche rendono la sicurezza delle reti di Kubernetes più complessa.  Per esempio, non è possibile inserire in whitelist o blacklist gli host in base a configurazioni di indirizzi statici, come si fa in genere quando si lavora con le macchine virtuali. Potrebbe inoltre essere più difficile mappare i dati relativi al traffico a risorse specifiche in Kubernetes, poiché non si può sempre sapere se un dato indirizzo IP è stato utilizzato solo da un pod o da un nodo, per esempio, o se è stato utilizzato da una risorsa e poi riassegnato a un’altra quando la prima non è stata più disponibile.

Come proteggere le risorse di rete in Kubernetes

Dal momento che Kubernetes tipicamente fa affidamento su una commistione di risorse interne (come kube-proxy) e servizi esterni (come i plugin CNI e le service mesh) per gestire le configurazioni di rete e il traffico, proteggere le reti Kubernetes impone anche agli amministratori di utilizzare un insieme di strumenti nativi e di terze parti.

Definire le policy di rete

La più importante risorsa nativa offerta da Kubernetes per la sicurezza di rete è rappresentata dalle policy di rete. In parole semplici, le policy di rete definiscono le regole che governano il modo in cui i pod possono comunicare tra loro a livello di rete.

Oltre a fornire un modo sistematico per controllare le comunicazioni tra i pod, le policy di rete offrono anche l’importante vantaggio di consentire agli amministratori di definire le risorse e le regole di rete associate in base a contesti quali le etichette dei pod e i namespace. Questo aspetto è cruciale perché, come già sottolineato, non è possibile utilizzare gli indirizzi IP per gestire le regole di rete, data la natura dinamica delle configurazioni di rete di Kubernetes.

Le policy di rete sono simili alle policy RBAC di Kubernetes. Sono file che specificano quali regole di rete devono essere applicate e individuano inoltre le risorse (un namespace, un pod, ecc) a cui la regola si riferisce.

Per esempio, la seguente policy di rete impedisce l’uscita dal backend tra pod che eseguono il namespace “default”:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-backend-egress
namespace: default
spec:
podSelector:
matchLabels:
tier: backend
policyTypes:
- Egress
egress:
- to:
- podSelector:
matchLabels:
tier: backend
Code language: JavaScript (javascript)

Limiti delle policy di rete

Per quanto le policy di rete siano uno strumento cruciale per la sicurezza di rete in Kubernetes, è importante riconoscere i loro limiti:

  • Si concentrano sui pod: Le policy di rete sono pensate essenzialmente per isolare o limitare l’accesso alla rete per i pod. Non possono essere utilizzate (almeno non in modo semplice e diretto) per gestire le regole di rete per nodi o altre risorse in Kubernetes.
  • Non rilevano gli abusi: Le policy di rete sono uno strumento incredibile per bloccare l’accesso alla rete e per chiudere potenziali falle nella sicurezza. Tuttavia, non fanno nulla per rilevare o notificare eventuali problemi di sicurezza.
  • Non eseguono la crittografia dei dati: Le policy di rete non possono eseguire la crittografia dei dati mentre si spostano tra i vari componenti di Kubernetes. È necessario utilizzare strumenti di terze parti (come le service mesh) per ottenere la crittografia di rete.
  1. Utilizzare strumenti di terze parti per la sicurezza della rete

In termini di strumenti nativi dedicati alla sicurezza della rete, Kubernetes offre praticamente solo le policy di rete. Per occuparsi di altri aspetti della sicurezza, è necessario utilizzare strumenti esterni.

Dal momento che gli strumenti e le funzioni messi a disposizione da diverse soluzioni di terze parti per Kubernetes variano molto, non esiste una soluzione univoca per fare fronte ai requisiti di sicurezza della rete attraverso gli strumenti esterni.

In generale, tuttavia, le service mesh consentono di crittografare il traffico, autenticare e autorizzare le risorse connesse alla rete e raccogliere dati di telemetria dalle risorse di rete Kubernetes che possono essere poi inviati alle piattaforme di analisi per rilevare eventuali violazioni. Alcune service mesh offrono anche strumenti che possono essere utilizzati per applicare le regole di sicurezza di rete che non possono essere applicate in modo pratico utilizzando Kubernetes, ad esempio isolando i namespace o rifiutando connessioni in assenza di sicurezza a livello di trasporto.

I plugin CNI spesso offrono funzioni simili, compresi strumenti per policy e monitoraggio della rete. Quindi, in base allo strumento specifico di elezione, è possibile affidarsi a piattaforme di rete connesse a CNI o alle service mesh per ottenere la visibilità e l’applicazione delle policy necessarie per massimizzare la sicurezza della rete Kubernetes.

Seguire le migliori prassi di sicurezza per Kubernetes

Oltre a impiegare i diversi strumenti disponibili per aiutare a proteggere le reti di Kubernetes, esistono alcune migliori prassi standard da seguire quando si lavora con risorse di rete all’interno di un ambiente che ospita un cluster Kubernetes.

  • Utilizzare RBAC: Sebbene il Role-Based Access Control (RBAC) di Kubernetes non sia un quadro di sicurezza, le regole RBAC possono aiutare a mitigare l’impatto delle minacce che hanno origine in rete limitando l’accesso a risorse all’interno di un cluster.
  • Evitare le porte predefinite: Kubernetes utilizza porte predefinite per la maggior parte dei suoi servizi. Per migliorare la sicurezza della rete, è possibile scegliere porte personalizzate per rendere più difficile l’individuazione delle risorse da parte degli autori degli attacchi.
  • Segmentare le reti esterne: Anche se è possibile (e si dovrebbe) utilizzare le policy di rete, le regole di service mesh e le altre risorse disponibili per isolare le reti in Kubernetes, è possibile ottenere un ulteriore livello di sicurezza segmentando anche le reti esterne. In base al luogo in cui vengono ospitati i cluster, questo significa sfruttare risorse quali VPC o firewall locali per minimizzare l’esposizione delle risorse all’Internet pubblico.
  • Sfruttare i registri di controllo: I registri di controllo di Kubernetes registrano qualunque richiesta di una risorsa che avviene all’interno di Kubernetes. Abilitando e analizzando i registri di controllo, è possibile massimizzare la possibilità di rilevare comportamenti che potrebbero indicare una violazione della rete.