Kubernetes Security: Checklist 12 Punti Prima di Esporre un Cluster in Produzione (2026)

Cluster Kubernetes in produzione da 4 mesi. Nessuna NetworkPolicy. ServiceAccount con permessi cluster-admin. Immagini da Docker Hub pubblico senza scan. Era un ambiente reale con dati di clienti. Questo scenario, purtroppo, non è un’eccezione ma una realtà diffusa in molte organizzazioni. La corsa alla containerizzazione e all’orchestrazione spesso porta a trascurare le fondamenta di sicurezza, esponendo dati sensibili e infrastrutture critiche a rischi elevatissimi. La complessità intrinseca di Kubernetes, con la sua miriade di componenti e configurazioni, può intimidire anche i team più esperti, portando a scelte di default poco sicure o a configurazioni affrettate che diventano veri e propri buchi neri nella cyber-difesa.

Quando si espone un cluster Kubernetes, anche per un ambiente di test che poi diventa ‘produzione’, la sicurezza deve essere una priorità assoluta fin dal giorno zero. Un singolo errore di configurazione può avere conseguenze devastanti, dalla compromissione dei dati all’interruzione dei servizi. Questo articolo fornisce una checklist operativa di 12 punti fondamentali per garantire che il vostro ambiente Kubernetes sia robusto e resiliente contro le minacce più comuni, basata su anni di esperienza sul campo nella gestione di infrastrutture enterprise complesse. Adottare queste best practice non è solo una questione di compliance, ma un investimento diretto nella continuità operativa e nella protezione del business.

Prerequisiti / Ambiente di test

Per seguire questa guida, avrete bisogno di un cluster Kubernetes funzionante (minikube, kind, o un cluster cloud come EKS/AKS/GKE) con accesso kubectl configurato. Alcuni comandi richiedono helm e jq installati. L’ambiente di test ideale dovrebbe replicare, per quanto possibile, le condizioni di un ambiente di produzione, anche se con un carico di lavoro limitato. Assicuratevi di avere permessi amministrativi per il cluster per poter applicare le configurazioni descritte.

1-2: API Server — Autenticazione e RBAC Minimale

L’API Server è il cuore di Kubernetes, il punto di accesso per tutti i controlli sul cluster. La sua sicurezza è paramount. Implementare un’autenticazione robusta è il primo passo, preferendo meccanismi come i certificati client, OIDC (OpenID Connect) o Webhook Token Authentication rispetto ai semplici ServiceAccount tokens per gli utenti umani. Per i ServiceAccount, è cruciale applicare il principio del privilegio minimo.

RBAC (Role-Based Access Control) è la chiave per limitare l’accesso. Un errore comune è concedere permessi cluster-admin a ServiceAccount o utenti che non ne hanno bisogno. Questo è un enorme rischio di sicurezza. Il 73% degli attacchi ai cluster Kubernetes sfrutta credenziali con privilegi eccessivi (Red Hat, 2024). Verificate regolarmente chi ha questi permessi:

kubectl get clusterrolebindings -o json | jq '.items[] | select(.roleRef.name=="cluster-admin")'

Analizzate l’output e rimuovete qualsiasi binding non strettamente necessario. Per ogni ServiceAccount e utente, definite ruoli e rolebindings specifici che concedano solo i permessi essenziali per le loro funzioni. Ad esempio, un’applicazione che deve solo leggere i Pods in un namespace non dovrebbe avere permessi per creare Deployments a livello di cluster.

3-4: Pod Security — non-root, read-only, SecurityContext

I Pod sono le unità di deployment in Kubernetes. La loro configurazione di sicurezza è fondamentale per prevenire privilege escalation e attacchi. Adottate i Pod Security Standards (PSS) o, per un controllo più granulare, i Pod Security Policies (PSP) (sebbene deprecati, il loro spirito è vivo nei PSS).

Esegui i container come utente non-root: Molte immagini Docker di default eseguono i processi come root. Questo è un rischio significativo. Specificare un runAsUser nel securityContext del Pod o del Container è una best practice. Ad esempio:

spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  containers:
  - name: my-app
    image: my-image:latest
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
          - ALL
        add:
          - NET_BIND_SERVICE

readOnlyRootFilesystem: true: Impedisce alle applicazioni di scrivere nella filesystem root del container, limitando i danni in caso di compromissione. La persistenza dei dati dovrebbe avvenire solo su volumi specifici e ben controllati.

5-6: Network Policy — Default Deny, Isolamento Namespace

Per default, i Pod in Kubernetes possono comunicare liberamente tra loro. Questo è un rischio enorme in un ambiente multi-tenant o con diverse applicazioni. Le Network Policy sono essenziali per segmentare il traffico a livello di Pod/Namespace.

Implementa una default-deny policy: Il primo passo è bloccare tutto il traffico in entrata e in uscita in un namespace, per poi permettere esplicitamente solo ciò che è necessario. Questo approccio zero-trust riduce drasticamente la superficie di attacco. Circa il 60% dei cluster in produzione non implementa Network Policies (Datadog, 2023).

kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
EOF

Dopo aver applicato questa policy, nessun Pod nel namespace default potrà comunicare con l’esterno o con altri Pod, a meno che non vengano create Network Policy specifiche per consentire il traffico necessario. Questo è un cambiamento drastico che richiede pianificazione, ma è vitale per l’isolamento.

7-8: Secrets — Encryption at Rest, External Secrets Operator

La gestione dei segreti (API keys, password, token) è una delle sfide più grandi in Kubernetes. I Secrets di Kubernetes sono codificati in Base64, non crittografati, e questo non è sufficiente per la produzione.

Crittografia at rest: Assicurati che il tuo Cloud Provider (o il tuo setup on-premise) crittografi i dati di etcd, dove i Secrets sono memorizzati. Usa un Key Management System (KMS) per la crittografia dei Secrets. Ad esempio, GKE e EKS offrono integrazioni native con i loro KMS.

External Secrets Operator: Per una gestione più robusta, integra Kubernetes con Secret Manager esterni come HashiCorp Vault, AWS Secrets Manager, Azure Key Vault o Google Secret Manager. L’External Secrets Operator sincronizza i segreti da questi sistemi esterni con i Secrets di Kubernetes, evitando di memorizzare i segreti direttamente in etcd.

9-10: Image — Registry Privato, Admission Controller, Scan

Le immagini container sono la base delle vostre applicazioni. La loro sicurezza è un punto critico.

Registry privato: Non pullate immagini direttamente da Docker Hub pubblico in produzione. Usate un registry privato (es. Harbor, ECR, GCR, ACR) dove avete il controllo completo sulle immagini e sulla loro provenienza.

Admission Controller per la sicurezza: Implementa Admission Controller come Kyverno o OPA Gatekeeper per imporre policy di sicurezza sulle immagini. Puoi bloccare il deployment di immagini da registry non autorizzati, immagini con vulnerabilità note, o immagini che non rispettano i Pod Security Standards.

Scan di vulnerabilità: Ogni immagine nel tuo registry privato deve essere scansionata regolarmente per vulnerabilità. Tool come Clair, Trivy o Anchore possono essere integrati nella CI/CD pipeline per automatizzare questo processo. Un’immagine con CVE critiche non dovrebbe mai raggiungere la produzione. Il 45% delle immagini container in produzione contiene almeno una vulnerabilità critica (Snyk, 2024).

11-12: Audit Log e Runtime Security con Falco

Anche con tutte le precauzioni, un attacco può sempre verificarsi. Avere visibilità su cosa succede nel cluster è fondamentale.

Audit Log: Abilita e centralizza gli audit log di Kubernetes. Questi log registrano tutte le richieste all’API Server e sono cruciali per l’analisi forense e la rilevazione di attività sospette. Integrali con il tuo SIEM (Security Information and Event Management) o EDR (Endpoint Detection and Response) per una correlazione avanzata.

Runtime Security con Falco: Falco è un motore di rilevamento delle minacce open source che monitora l’attività dei container e del kernel Linux. Permette di rilevare comportamenti anomali come esecuzioni di shell in container, modifiche a file di sistema critici o connessioni di rete inattese. Installare Falco è relativamente semplice tramite Helm:

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
helm install falco falcosecurity/falco --set falco.grpc.enabled=true

Falco può generare alert in tempo reale, integrandosi con sistemi di notifica come Slack, PagerDuty o il tuo SIEM.

kube-bench: Audit Automatico CIS Benchmark in 5 Minuti

Per un audit rapido e automatico della conformità del tuo cluster agli standard di sicurezza del CIS (Center for Internet Security) Benchmark, kube-bench è uno strumento indispensabile. Ti permette di identificare rapidamente le configurazioni non conformi.

kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl logs job/kube-bench

Eseguendo questi comandi, kube-bench verrà deployato come un Job nel tuo cluster ed eseguirà una scansione, fornendoti un report dettagliato su eventuali violazioni del CIS Benchmark. Questo è un ottimo punto di partenza per identificare le aree che necessitano di maggiore hardening.

Errori comuni e troubleshooting

Uno degli errori più comuni è applicare Network Policies troppo restrittive senza testarle adeguatamente, bloccando il traffico legittimo e causando interruzioni di servizio. Iniziate sempre con policy permissive e restringetele gradualmente, oppure testatele in un ambiente di staging. Un altro errore è sottovalutare l’impatto delle modifiche al RBAC: un permesso mancante può bloccare un’applicazione intera. Usate kubectl auth can-i per testare i permessi di un utente o ServiceAccount.

Quando si implementano Pod Security Standards, le applicazioni legacy potrebbero non essere compatibili con i requisiti più stringenti (es. readOnlyRootFilesystem). In questi casi, valutate la possibilità di containerizzare l’applicazione in modo diverso o di isolarla in un namespace con policy meno restrittive, ma sempre monitorata attentamente.

FAQ — Domande Frequenti

Qual è la differenza tra Pod Security Standards (PSS) e Pod Security Policies (PSP)?

I Pod Security Policies (PSP) sono stati deprecati in Kubernetes 1.25. I Pod Security Standards (PSS) sono il loro successore e prevedono tre livelli di policy (Privileged, Baseline, Restricted) che possono essere applicate a livello di namespace o cluster tramite Admission Controller. Sono più semplici da configurare e gestire rispetto ai PSP.

Come posso testare l’efficacia delle mie Network Policy?

Potete usare strumenti come netshoot o debug containers per eseguire test di connettività tra i pod. Deployate un pod temporaneo in un namespace e tentate di raggiungere altri pod o servizi. L’output vi dirà se la connessione è permessa o bloccata dalla Network Policy.

È sufficiente usare solo un registry privato per la sicurezza delle immagini?

Un registry privato è un ottimo punto di partenza, ma non è sufficiente da solo. Dovete combinare un registry privato con scansioni automatiche di vulnerabilità delle immagini (es. Trivy, Clair) e, idealmente, con Admission Controller che bloccano il deployment di immagini non conformi o con CVE note. Questo crea una difesa a più strati.

Qual è il rischio di usare ServiceAccount con permessi cluster-admin?

Concedere permessi cluster-admin a un ServiceAccount è estremamente rischioso. Se un attaccante compromettesse un Pod che utilizza quel ServiceAccount, avrebbe accesso completo al cluster, potendo creare, modificare o eliminare qualsiasi risorsa, inclusi altri Pod, Secrets e persino l’API Server stesso. È una delle cause principali di compromissioni di cluster Kubernetes.

Conclusioni con takeaway operativi

La sicurezza di Kubernetes è un processo continuo, non un evento singolo. L’adozione di una checklist rigorosa prima di esporre un cluster in produzione è il primo passo per costruire un ambiente resiliente. Ricordate di:

• Applicare il principio del privilegio minimo per RBAC e ServiceAccount.
• Isolare i carichi di lavoro con Network Policy default-deny.
• Proteggere i Secrets con crittografia at rest e Secret Manager esterni.
• Garantire l’integrità delle immagini con registry privati, scan di vulnerabilità e Admission Controller.
• Monitorare attivamente con audit log e runtime security come Falco.

Ogni punto di questa checklist riduce la superficie di attacco e aumenta la capacità di rilevare e rispondere a potenziali minacce. Non aspettate che sia troppo tardi. Implementate queste misure oggi stesso per proteggere i vostri dati e la vostra infrastruttura.

Leggi anche

Leggi anche: Docker Sicurezza Produzione: 10 Best Practice Ignorate (2026)

Leggi anche: Zero Trust VPN Alternativa 2026: La Fine delle VPN Tradizionali

Leggi anche: Active Directory Hardening: 10 Impostazioni Critiche da Verificare Subito (2026)

Aggiornato: giugno 2026