Sicurezza Kubernetes: RBAC, policy di rete e sicurezza dei pod

Kubernetes orchestra workload containerizzati su larga scala, ma la sua complessità crea un'ampia superficie di attacco. Tra i componenti principali da proteggere vi sono: l'API Server (il piano di controllo centrale: la sua compromissione consente di controllare l'intero cluster), etcd (il database dello stato del cluster: memorizza i segreti in base64 e deve essere crittografato a riposo), il kubelet (l'agente del nodo: un'API kubelet non autenticata consente l'esecuzione arbitraria di pod), il container runtime (Docker/containerd) e l'infrastruttura di rete che collega tutti i pod. Chi sostiene Security+ dovrebbe comprendere che le configurazioni errate di Kubernetes sono tra i risultati più comuni delle valutazioni di sicurezza cloud.

Il RBAC (Role-Based Access Control) di Kubernetes controlla quali utenti, account di servizio e processi possono eseguire determinate azioni su specifiche risorse API. Il modello comprende quattro oggetti: Role (autorizzazioni limitate a un namespace), ClusterRole (autorizzazioni a livello di cluster), RoleBinding (assegna un Role a un soggetto all'interno di un namespace) e ClusterRoleBinding (assegna un ClusterRole a un soggetto nell'intero cluster). Ogni comando kubectl viene tradotto in una chiamata API, verificata rispetto alle regole RBAC. Se RBAC non è configurato, qualsiasi utente autenticato (o account di servizio) potrebbe disporre dell'accesso amministrativo.

Ogni pod in Kubernetes viene eseguito con un service account, ovvero un'identità utilizzata per l'autenticazione all'API. Per impostazione predefinita, i pod usano il service account default del proprio namespace, che potrebbe disporre di autorizzazioni troppo ampie. Il principio del privilegio minimo richiede la creazione di account di servizio dedicati per ogni applicazione, con le sole autorizzazioni necessarie. Inoltre, impostare automountServiceAccountToken: false sui pod che non necessitano dell'accesso all'API impedisce il montaggio del token dell'account di servizio nel filesystem del pod, dove un'applicazione compromessa potrebbe utilizzarlo per effettuare chiamate API.

Per impostazione predefinita, in Kubernetes tutti i pod possono comunicare con tutti gli altri pod in qualsiasi namespace. Un pod compromesso può tentare immediatamente di raggiungere database, API interne e altri microservizi. Le risorse Kubernetes NetworkPolicy definiscono regole che limitano il traffico tra pod in base a label, namespace e porte. L'approccio consigliato consiste nell'applicare una policy di rete 'default deny all' in ogni namespace, seguita da regole di autorizzazione esplicite per i percorsi di comunicazione necessari. Si noti che NetworkPolicy richiede un plugin CNI che la supporti (Calico, Cilium, Weave): Kubernetes vanilla ignora NetworkPolicy in assenza di un CNI compatibile.

I Pod Security Standards (PSS), introdotti in Kubernetes 1.23 e stabili dalla versione 1.25, sostituiscono i deprecati Pod Security Policy (PSP) con tre profili integrati applicabili a livello di namespace: Privileged (senza restrizioni, per i componenti di sistema), Baseline (previene escalation di privilegi note, come l'uso di container privilegiati e l'accesso alla rete dell'host) e Restricted (rafforzato, richiede utenti non root, elimina tutte le capabilities e impone filesystem root in sola lettura). I namespace vengono contrassegnati con label per applicare un livello di policy e i pod che lo violano vengono rifiutati in fase di admission.

I Secrets di Kubernetes memorizzano dati sensibili come password, token e certificati TLS. Per impostazione predefinita, i Secrets sono archiviati in etcd come valori codificati in base64, non crittografati. Chiunque possa leggere etcd o disponga di autorizzazioni RBAC sufficienti può decodificarli facilmente. Le best practice includono: abilitare la crittografia a riposo per etcd usando AES-GCM con una chiave memorizzata in un KMS (AWS KMS, GCP KMS), integrare un secrets manager esterno come HashiCorp Vault o AWS Secrets Manager tramite Secrets Store CSI Driver e limitare l'accesso ai Secret tramite RBAC, in modo che possano leggerli solo gli account di servizio che ne hanno bisogno.

Gli admission controller sono plugin del server API di Kubernetes che intercettano le richieste API dopo l'autenticazione e l'autorizzazione, ma prima della persistenza dell'oggetto, consentendo di convalidare, modificare o rifiutare le richieste. Tra gli admission controller rilevanti per la sicurezza vi sono: PodSecurity (applica i Pod Security Standards), ImagePolicyWebhook (consente la verifica esterna della firma delle immagini), AlwaysPullImages (impone il pull di immagini aggiornate per impedire l'uso di immagini dannose presenti nella cache locale) e OPA/Gatekeeper (Open Policy Agent, la soluzione più flessibile, che consente di esprimere policy personalizzate nel linguaggio Rego per applicare qualsiasi regola di sicurezza aziendale).

È fondamentale rafforzare la sicurezza dei componenti del piano di controllo Kubernetes: il server API dovrebbe avere --anonymous-auth=false per disabilitare l'accesso non autenticato, --audit-log-path configurato per acquisire tutte le attività API e TLS per tutte le connessioni. Il kubelet dovrebbe avere --authorization-mode=Webhook (non AlwaysAllow) e l'autenticazione anonima disabilitata. etcd dovrebbe usare la crittografia TLS tra peer e client, avere l'accesso di rete limitato (ed essere raggiungibile solo dal server API) e proteggere i dati a riposo tramite crittografia. Il CIS Kubernetes Benchmark fornisce una checklist completa per tutte le impostazioni dei componenti.

I namespace di Kubernetes forniscono una separazione logica delle risorse, ma da soli non costituiscono un confine di sicurezza forte: offrono principalmente un isolamento organizzativo. Per un vero isolamento multi-tenant (ad esempio, per i workload di clienti diversi) sono necessari controlli aggiuntivi: policy di rete per bloccare il traffico tra namespace, quote delle risorse per impedire attacchi DoS causati da tenant che consumano risorse eccessive, pool di nodi separati per tenant fortemente isolati oppure cluster dedicati per ciascun tenant. Molte organizzazioni usano gli Hierarchical Namespaces o soluzioni commerciali come vCluster per ottenere un isolamento multi-tenant più forte all'interno di un singolo cluster.

La registrazione degli audit di Kubernetes registra ogni richiesta API: chi l'ha effettuata, da dove, quale azione è stata richiesta e quale risorsa era interessata. I log di audit sono essenziali per le indagini forensi dopo un incidente di sicurezza e per rilevare comportamenti anomali, come associazioni di ruoli insolite, accessi ai secret o comandi exec nei pod di produzione. I log di audit devono essere trasmessi a un SIEM centralizzato. Falco fornisce il monitoraggio del comportamento dei container, mentre i servizi Kubernetes gestiti dal cloud (EKS, GKE, AKS) offrono l'integrazione nativa dei log di audit con le rispettive piattaforme di logging.

La sicurezza della catena di approvvigionamento per Kubernetes garantisce che in produzione arrivino solo immagini attendibili e verificate. Le raccomandazioni CNCF sulla Supply Chain Security includono: verificare le firme delle immagini con Cosign prima della distribuzione (imponendo il controllo tramite admission controller), generare e verificare gli SBOM (Software Bills of Materials) per tutte le immagini dei container per tracciare la provenienza dei componenti, bloccare le immagini su digest (myimage@sha256:abc123) anziché su tag mutabili e analizzare tutti i chart Helm di terze parti alla ricerca di configurazioni errate e vulnerabilità prima della distribuzione.

In questa lezione ha imparato che: RBAC di Kubernetes controlla l'accesso alle API tramite Roles, ClusterRoles e Bindings — applichi sempre il principio del privilegio minimo agli account di servizio; le configurazioni NetworkPolicy con negazione predefinita impediscono i movimenti laterali tra pod e namespace; e i Pod Security Standards impongono l'hardening dei container a livello di namespace, bloccando i container privilegiati, l'accesso alla rete dell'host e l'esecuzione come root. Nel prossimo argomento esamineremo la sicurezza serverless e le superfici di attacco a livello di funzione.