Le minacce informatiche sono in costante evoluzione e gli attori malevoli hanno sempre più tempo per prepararsi. Ottimizzare la sicurezza di Kubernetes è fondamentale per migliorare la postura di sicurezza cloud di un’azienda. Gli amministratori Kubernetes devono comprendere il funzionamento dell’infrastruttura per integrare misure di sicurezza efficaci.
La Kubernetes Security Checklist per il 2026 può essere ampiamente classificata in tre categorie:
- Cluster
- Pod
- Container
.jpg)
La Kubernetes Security Checklist deve essere semplificata e la complessità operativa deve essere affrontata. Quando le organizzazioni cercano di dare priorità alle misure di sicurezza e di correggere le minacce, migliorano automaticamente la reputazione aziendale. Le aziende costruiscono fiducia tra i clienti e stabiliscono credibilità. Inoltre, si riducono le spese operative preparandosi a problemi futuri che potrebbero emergere con l’aumento delle minacce. Approfondiamo l’argomento.
Checklist di sicurezza Kubernetes a componenti multipli
La Kubernetes Security Checklist comprende diversi componenti,
- Audit e logging
- Sicurezza di rete
- Autenticazione e autorizzazione
- Gestione dei segreti
- Admission control
- Confini di sicurezza Kubernetes
- Policy di sicurezza Kubernetes
- Sicurezza kubelet
- Impostazioni predefinite “aperte”
Secondo il report Kubernetes adoption, security, and market trends 2024, le organizzazioni hanno documentato numerosi impatti negativi (inclusi perdite di ricavi e sanzioni) dovuti a negligenza nella sicurezza dei container Kubernetes. I team DevSecOps hanno dichiarato che vulnerabilità e configurazioni errate sono le principali preoccupazioni di sicurezza associate a Kubernetes e agli ambienti container. Le soluzioni software Kubernetes open source non sono sicure e incidono sulla sicurezza della supply chain software. Oltre il 67% delle aziende ha ritardato le operazioni di business a causa di problemi di sicurezza e la maggior parte delle aziende globali è sopraffatta da tutti gli aspetti della gestione della sicurezza, a partire dallo sviluppo, dal deployment e dalla manutenzione.
La checklist definitiva per la sicurezza Kubernetes 2026
#1. Seguire i CIS Benchmarks
I CIS Benchmarks forniscono policy di sicurezza di base che le organizzazioni possono utilizzare per migliorare la sicurezza di Kubernetes. Protegge i sistemi IT dagli attacchi informatici e include una serie di processi e linee guida sviluppate dalla comunità per mettere in sicurezza gli ambienti Kubernetes. Secondo la Kubernetes security checklist CIS Benchmark, i principali componenti da mettere in sicurezza sono: Kubernetes PKI, kubeadm, file CNI, directory dati etcd, kubeadm admin.conf, controller manager.conf e il file di specifica del pod.
#2. Autenticazione API Kubernetes
Uno dei metodi più adottati per l’autenticazione API Kubernetes nella Kubernetes security checklist è l’utilizzo di certificati X509. I certificati vengono utilizzati per evidenziare l’appartenenza a un gruppo e possono verificare i nomi dei soggetti che inviano richieste.
Secondo la Kubernetes security checklist, esistono altri metodi integrati per autenticare gli account utente. Le pratiche di autenticazione Kubernetes validano l’identità degli utenti e determinano se devono essere concessi i permessi di accesso. Il controllo degli accessi basato sui ruoli viene implementato nel processo.
Per utilizzare l’autenticazione X509, gli utenti devono creare una chiave privata ed emettere una richiesta di firma del certificato. Questo può essere avviato in ambienti Unix o sistemi operativi simili. La seconda tecnica più diffusa di autenticazione Kubernetes è l’utilizzo di token OpenID Connect (OIDC). Molti provider OIDC come Google, Okta, dex e OpenUnison supportano questa modalità. Vari servizi di single sign-on assistono nell’autenticazione API Kubernetes e i passaggi di implementazione variano in base al servizio scelto dagli utenti. I token di autenticazione degli account di servizio possono essere utilizzati per validare le richieste di autenticazione e i bearer token negli header HTTP possono anche emettere raccomandazioni.
L’ultimo metodo di autenticazione è l’uso di file di password statici. È l’approccio di autenticazione meno sicuro ma il più semplice. Richiede una configurazione minima e gli utenti devono aggiornare manualmente il file delle password per modificare gli accessi. Per chi è alle prime armi con l’autenticazione Kubernetes, l’utilizzo di file di password statici come soluzione di autenticazione è l’approccio più diretto per i cluster di test.
#3. Sicurezza Kubelet
La sicurezza kubelet riguarda l’esecuzione dei nodi nei cluster Kubernetes. È principalmente responsabile della gestione diretta dei container Kubernetes sui nodi e interagisce con le interfacce runtime dei container (CRI).
Sono coinvolte due porte: 10255 e 10250. La 10255 è una porta in sola lettura che restituisce dati sui pod e container in esecuzione sui nodi. La 10250 è una porta scrivibile che può programmare pod sui nodi selezionati.
Quando si distribuiscono cluster Kubernetes per la prima volta, le seguenti misure di sicurezza dovrebbero essere considerate come parte della Kubernetes security checklist:
- Eseguire sempre i nodi su reti interne
- Utilizzare kubelet con il flag –anonymous-auth=false e limitare l’accesso anonimo
- Evitare di impostare la modalità di autorizzazione su AlwaysAllow e selezionare un’altra opzione
- Limitare i permessi dei kubelet. Il plugin NodeRestriction può modificare i pod e associarli agli oggetti Node.
- Utilizzare l’autenticazione basata su certificato e configurarla correttamente per abilitare la comunicazione tra master e nodi senza problemi.
- Applicare regole firewall restrittive e consentire solo al master Kubernetes di comunicare con il kubelet
- Disattivare le porte in sola lettura e limitare le informazioni condivise dai workload
- Testare manualmente tutti i controlli di sicurezza Kubernetes e assicurarsi che i kubelet non siano accessibili di default
#4. Gestione dei segreti
I segreti Kubernetes memorizzano dati sensibili come chiavi API, password e token. I segreti Kubernetes non dovrebbero essere accessibili dai componenti interni di Kubernetes e vengono inviati ai nodi pod solo in base alla necessità. I segreti sono uno dei principali obiettivi degli attaccanti e devono essere protetti con attenzione.
Gli utenti dovrebbero limitare l’accesso a etcd, controllarlo e applicare la crittografia ai cluster etcd. I container Kubernetes dovrebbero inoltre seguire il principio del privilegio minimo. L’autorizzazione dei nodi dovrebbe essere implementata tra gli altri elementi della Kubernetes security checklist. Idealmente, gli utenti dovrebbero utilizzare set diversi di segreti per i diversi ambienti Kubernetes.
È buona pratica evitare di inserire i segreti nelle immagini. È inoltre consigliato abilitare la scansione in tempo reale dei segreti nei repository di codice sorgente e verificarli. I segreti rischiano di essere scritti nei log e una delle migliori pratiche di sicurezza è passarli tramite file. Impostare il volume montato come directory temporanea invece di scrivere su disco. È anche possibile ruotare le chiavi segrete, scegliere diversi modi per archiviarle e passarle ai container per ottenere i migliori risultati. A volte, le applicazioni devono essere riavviate per leggere le nuove password del database. Per chi utilizza workflow basati su file, i segreti file possono essere aggiornati automaticamente senza riavvii.
#5. Admission Controllers
Gli admission controller sono inclusi nella Kubernetes security checklist per il 2026. Questi applicano i framework di policy di sicurezza Kubernetes e funzionano come seconda linea di difesa accanto ai controlli RBAC.
Gli admission controller possono impostare regole in base a diversi parametri e limitare l’utilizzo delle risorse. Possono impedire l’esecuzione di comandi in container privilegiati e richiedere sempre ai pod di scaricare le immagini invece di utilizzare quelle memorizzate localmente sul nodo. Un altro vantaggio degli admission controller è il monitoraggio delle richieste in ingresso e l’impostazione di vincoli di risorse nei namespace. Si raccomanda di abilitare almeno gli admission controller predefiniti forniti da Kubernetes.
#6. Confini di sicurezza Kubernetes
I confini di sicurezza Kubernetes costituiscono la base della Kubernetes security checklist. Impediscono ai processi di accedere ai dati di altri utenti e applicano policy che offrono isolamento containerizzato. I template di admission LimitRanger e ResourceQuota impediscono la privazione di risorse e, per i pod, gli utenti possono definire contesti di sicurezza personalizzati e applicarli.
#7. Policy di sicurezza Kubernetes
Gli standard di sicurezza dei pod sono soggetti a diversi livelli di complessità. Le policy di sicurezza dei pod Kubernetes sono configurate come risorsa a livello di cluster e impongono l’uso di contesti di sicurezza e admission controller. Il pod deve soddisfare i requisiti della policy di sicurezza del pod, altrimenti non verrà eseguito. Le policy di sicurezza dei pod vengono rimosse automaticamente da Kubernetes v1.25 in poi, il che significa che gli utenti devono migrare al controller di admission Pod Security di Kubernetes.
I contesti di sicurezza definiscono le impostazioni di controllo degli accessi e i privilegi per i container Kubernetes. Implementano controlli di accesso discrezionali, impostano i permessi per l’accesso agli oggetti in base agli ID di gruppo e configurano processi non privilegiati.
Gli utenti possono definire strumenti di contesto di sicurezza interni e integrarli con funzionalità esterne. Possono utilizzare seccomp per filtrare le chiamate di sistema e AppArmor può limitare le capacità dei singoli componenti. Non è necessario fornire privilegi di accesso e assegnare permessi specifici per risorsa, consentendo un approccio granulare. Gli utenti possono includere i contesti di sicurezza con il codice Security context presente nei file di deployment durante la creazione dei pod. Kubernetes è molto agile e gli utenti possono anche automatizzare il deployment dei profili sui nodi. L’unico svantaggio è che non c’è supporto per i container Windows. Possono anche abilitare i permessi per mettere in sicurezza account di servizio, nodi e utenti.
#8. Sicurezza di rete Kubernetes
La sicurezza di rete Kubernetes è una componente essenziale della Kubernetes security checklist. Aggiunge controlli che specificano come il traffico fluisce tra i container e definisce il tipo di traffico da bloccare. Gli utenti possono seguire un’architettura multi-cluster per isolare i workload e mitigare i problemi di sicurezza distribuendo i workload in cluster diversi. È possibile ottenere un elevato grado di isolamento dei container e ridurre contemporaneamente la complessità.
Esistono policy di rete Kubernetes che aggiungono funzionalità di firewall e limitano il flusso di traffico tra i pod. Specifica quali pod comunicano con entità di rete selezionate. La policy di ingresso è consentita sulla porta di destinazione e la policy di uscita deve essere sul pod sorgente per abilitare un flusso di traffico ottimale. Come regola generale, è buona pratica utilizzare le etichette e gli utenti possono aggiungere procedure per consentire e indirizzare il traffico solo dove previsto. Possono limitare il traffico a porte specifiche per diverse applicazioni. I service mesh Kubernetes possono semplificare il monitoraggio e fornire varie funzionalità relative al monitoraggio continuo e agli alert. Rilevano minacce alla sicurezza e segnalano incidenti; sono disponibili molti progetti service mesh. La Kubernetes security checklist suggerisce di utilizzare opzioni come Linkerd, Consul e Istio.
#9. Audit e logging Kubernetes
Mantenere i log degli eventi dei container e creare una traccia di audit per gli ambienti di produzione è essenziale. L’audit logging Kubernetes include la registrazione dell’identità delle immagini e degli utenti che avviano i comandi di start e stop. I plugin CNI generano interfacce di rete virtuali utilizzate dai container. I plugin CNI si integrano anche con diverse piattaforme e strumenti di gestione della configurazione di terze parti, e i più popolari sono Cilium e Project Calico. Altri aspetti dell’audit e logging Kubernetes includono la modifica dei payload dei container e dei mount dei volumi, il monitoraggio delle connessioni in ingresso e in uscita e la correzione delle azioni non riuscite. Il logging applicativo è il modo più semplice per monitorare l’attività del cluster e può fornire informazioni utili per il debug delle applicazioni. Implementare il logging a livello di cluster e inviare i log nei container di storage è una pratica standard utilizzando una piattaforma o un servizio centralizzato di gestione dei log.
Perché SentinelOne per la sicurezza Kubernetes?
Cloud Workload Security (CWS) di SentinelOne per Kubernetes, parte della piattaforma Singularity™, offre una soluzione all’avanguardia progettata per affrontare efficacemente queste minacce moderne. Ecco come SentinelOne migliora la sicurezza Kubernetes:
- Protezione dalle minacce in tempo reale: Singularity CWS monitora e protegge costantemente i workload Kubernetes da minacce come ransomware e vulnerabilità sconosciute. La sua tecnologia basata su AI garantisce rilevamento e risposta rapidi, proteggendo gli ambienti Kubernetes.
- Investigazione degli incidenti e threat hunting: Con Singularity Data Lake, SentinelOne fornisce una visibilità completa sulle attività dei workload. Questo strumento aiuta nell’investigazione degli incidenti e nelle attività di threat hunting. Il Workload Flight Data Recorder™ assiste nel recupero dagli incidenti rimuovendo i workload problematici, riducendo al minimo le perdite finanziarie e i danni.
- Ampia compatibilità: SentinelOne supporta una vasta gamma di workload containerizzati, inclusi 14 principali distribuzioni Linux, tre runtime container più diffusi e servizi Kubernetes sia gestiti che self-run.
Protezione dei carichi di lavoro cloud (CWPP) basata su AI per server, VM e container, che rileva e blocca le minacce in tempo reale durante l'esecuzione.
Conclusione
I principi di base della Kubernetes Security Checklist 2026 ruotano attorno ad autenticazione, gestione della sicurezza dei pod, gestione dei segreti e altri componenti. Seguendo queste pratiche, le organizzazioni possono mettere in sicurezza gli ambienti Kubernetes e garantire che l’accesso ai dati sia limitato. Questi suggerimenti semplificano la sicurezza Kubernetes e stratificano la sicurezza per ridurre la complessità dell’architettura. Quando gli utenti ottimizzano la sicurezza Kubernetes per il cloud, diventa semplice integrarla con altri workflow di sicurezza.
Domande frequenti sulla Kubernetes Security Checklist
Una Kubernetes Security Checklist è un elenco di passaggi da seguire per mettere in sicurezza il cluster. Include la protezione dell'API server, etcd e kubelet; l'applicazione di RBAC; l'isolamento dei pod tramite policy di rete e di sicurezza dei pod; la cifratura dei segreti; e l'audit degli eventi.
La checklist funge da guida per assicurarsi che ogni componente critico—dal control plane ai workload—rispetti gli standard minimi di sicurezza.
I cluster Kubernetes gestiscono workload critici e qualsiasi errore può esporre dati sensibili o consentire movimenti laterali agli attaccanti. Una checklist previene il drift: consente di applicare controlli concordati in modo coerente, individuare lacune—come porte API aperte o RBAC troppo permissivo—e mantenere la conformità. Seguire regolarmente la checklist riduce le sorprese e mantiene i cluster protetti sia dalle minacce note che da quelle emergenti.
La checklist di produzione dovrebbe includere: limitare l'accesso all'API server alle reti fidate; abilitare i log di audit; cifrare i dati etcd a riposo; applicare RBAC con privilegi minimi; applicare policy di sicurezza dei pod o di ammissione; utilizzare policy di rete per isolare i servizi; mettere in sicurezza le immagini dei container; ruotare i certificati; e validare la sicurezza della pipeline CI/CD. Ogni voce protegge un livello del cluster prima che traffico o workload vadano in produzione.
I team dovrebbero revisionare la checklist almeno trimestralmente e dopo ogni aggiornamento importante di versione Kubernetes o cambiamento architetturale. Revisioni frequenti permettono di individuare drift di configurazione—come nuove porte aperte o regole RBAC allentate—e assicurano che i controlli si adattino a nuove minacce o componenti aggiunti.
Cambiamenti critici, come nuovi namespace o admission controller personalizzati, richiedono anche una revisione immediata della checklist.
Strumenti open source come kube-bench eseguono audit del cluster rispetto ai CIS Kubernetes Benchmarks. Kube-hunter individua esposizioni e configurazioni errate. Polaris valida i workload attivi rispetto a policy personalizzate. I log di audit nativi di Kubernetes vengono inviati ai SIEM per il monitoraggio degli eventi.
Combinati, questi strumenti automatizzano i controlli su impostazioni del control plane, RBAC, policy di rete e altro—rendendo più semplice individuare e correggere deviazioni dalla checklist.
Puoi iniziare dalla Kubernetes Security Checklist ufficiale su GitHub (kubernetes.io/docs/concepts/security/security-checklist/) o da guide mantenute dalla community come il repository krol3/kubernetes-security-checklist.
Molti provider cloud e vendor di sicurezza pubblicano anche checklist scaricabili in PDF—basta cercare “Kubernetes Security Checklist PDF” per trovare esempi da adattare al tuo ambiente.
L'implementazione è uno sforzo condiviso tra DevOps, ingegneri di piattaforma e team di sicurezza. Gli ingegneri di piattaforma configurano i componenti del control plane e le policy di rete. I team DevOps mettono in sicurezza i workload e le pipeline CI/CD.
I team di sicurezza definiscono i controlli di base, eseguono audit e monitorano la conformità. Insieme, assicurano che ogni voce della checklist—dalle regole RBAC alle policy di sicurezza dei pod—sia applicata e validata.
