Lista di controllo della sicurezza di Kubernetes per il 2025

Segui una checklist di sicurezza completa per garantire che il tuo cluster sia protetto, incluse le politiche di rete, la gestione dei segreti e il controllo degli accessi basato sui ruoli, per prevenire violazioni e mantenere la conformità nel tuo ambiente Kubernetes.

Le minacce informatiche sono in costante aumento e gli autori degli attacchi hanno bisogno di più tempo per prepararsi ad affrontarle. Ottimizzare la sicurezza di Kubernetes è fondamentale per migliorare la posizione di sicurezza cloud di un'azienda. Gli amministratori di Kubernetes devono comprendere il funzionamento dell'infrastruttura per incorporare misure di sicurezza efficaci.

La Lista di controllo per la sicurezza di Kubernetes per il 2025 può essere suddivisa in tre categorie principali:

• Cluster
• Pod
• Container

Lista di controllo per la sicurezza di Kubernetes deve essere semplificata e occorre affrontare la complessità operativa. Quando le organizzazioni cercano di dare priorità alle misure di sicurezza e di porre rimedio alle minacce, migliorano automaticamente la reputazione aziendale. Le aziende creano fiducia tra i clienti e stabiliscono credibilità. Inoltre, riducono le spese operative preparandosi a problemi futuri che potrebbero emergere in seguito con l'aumento delle minacce.

Approfondiamo questo argomento.

Lista di controllo per la sicurezza di Kubernetes con più componenti

La Lista di controllo per la sicurezza di Kubernetes ha più componenti-

• Auditing e registrazione
• Sicurezza della rete
• Autenticazione e autorizzazione
• Gestione dei segreti
• Controllo degli accessi
• Confini di sicurezza di Kubernetes
• Politiche di sicurezza di Kubernetes
• Sicurezza Kubelet
• Impostazioni predefinite "aperte"

Secondo il rapporto Kubernetes, le organizzazioni hanno documentato numerosi impatti negativi (tra cui perdite di entrate e multe) dovuti a negligenza nella sicurezza dei container Kubernetes. DevSecOps hanno affermato che le vulnerabilità e le configurazioni errate sono le principali preoccupazioni di sicurezza associate a Kubernetes e agli ambienti container. Le soluzioni software open source Kubernetes non sono sicure e compromettono la sicurezza della catena di fornitura del software. Oltre il 67% delle aziende ha ritardato le operazioni aziendali 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, dall'implementazione e dalla manutenzione.

La checklist definitiva per la sicurezza di Kubernetes per il 2025

#1. Seguire i benchmark CIS

I benchmark CIS forniscono politiche di sicurezza di base che le organizzazioni possono utilizzare per migliorare la sicurezza di Kubernetes. Proteggono i sistemi IT dagli attacchi informatici e includono una serie di processi e linee guida concordati dalla comunità e sviluppati per proteggere gli ambienti Kubernetes. Secondo la lista di controllo per la sicurezza di Kubernetes CIS Benchmark, i componenti principali che gli utenti devono proteggere 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ù diffusi per l'autenticazione API Kubernetes nella lista di controllo della sicurezza Kubernetes è l'utilizzo dei certificati X509. I certificati vengono utilizzati per evidenziare un gruppo di appartenenze e possono verificare i nomi dei soggetti che inviano le richieste.

Secondo la sicurezza Kubernetes esistono altri metodi integrati per l'autenticazione degli account utente. Le pratiche di autenticazione di Kubernetes convalidano l'identità degli utenti e determinano se debba essere loro concesso l'accesso. Nel processo viene implementato il controllo degli accessi basato sui ruoli.

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ù popolare di autenticazione Kubernetes è l'utilizzo di token OpenID Connect (OIDC). Molti provider OIDC come Google, Okta, dex e OpenUnison aiutano in questo senso. Vari servizi di single sign-on assistono nell'autenticazione API Kubernetes e le fasi di implementazione variano a seconda del servizio scelto dagli utenti. I token di autenticazione dell'account di servizio possono essere utilizzati per convalidare le richieste di autenticazione, mentre i token bearer nelle intestazioni HTTP possono anche emettere raccomandazioni.

L'ultimo metodo di autenticazione è l'uso di file di password statici. Si tratta dell'approccio di autenticazione meno sicuro, ma anche il più semplice. Richiede una configurazione minima e gli utenti devono aggiornare manualmente il file delle password per aggiornare le modifiche di accesso degli utenti. Per chi è nuovo all'autenticazione Kubernetes, l'utilizzo di file di password statiche come soluzione di autenticazione è l'approccio più semplice da utilizzare con i cluster di test.

#3. Sicurezza Kubelet

La sicurezza Kubelet comporta l'esecuzione di nodi su cluster Kubernetes. È principalmente responsabile della gestione dei container Kubernetes direttamente sui nodi e interagisce con le interfacce di runtime dei container (CRI).

Sono coinvolte due porte: 10255 e 10250. La porta 10255 è una porta di sola lettura che restituisce dati sui pod e sui container in esecuzione sui nodi. La porta 10250 è una porta scrivibile che può pianificare i pod sui nodi selezionati.

Quando si distribuiscono cluster Kubernetes per la prima volta, è necessario prendere in considerazione le seguenti misure di sicurezza come parte della lista di controllo della sicurezza di Kubernetes:

• 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 le autorizzazioni dei kubelet. Il plugin di ammissione NodeRestriction può modificare i pod e collegarli agli oggetti Node.
• Utilizzare l'autenticazione basata su certificati e configurarla correttamente per consentire comunicazioni fluide tra master e nodi.
• Applicare regole firewall rigorose e consentire solo al master Kubernetes di comunicare con il kubelet
• Disattiva le porte di sola lettura e limita le informazioni condivise dai carichi di lavoro.
• Testa manualmente tutti i controlli di sicurezza di Kubernetes e assicurati che i kubelet siano inaccessibili per impostazione predefinita.

#4. Gestione dei segreti

I segreti Kubernetes memorizzano dati sensibili come chiavi API, password e token. I segreti Kubernetes non devono essere accessibili dai componenti interni di Kubernetes e vengono inviati ai nodi pod solo in caso di necessità. I segreti sono uno dei principali obiettivi degli hacker e devono essere protetti con cura.

Gli utenti devono limitare l'accesso a etcd, controllarlo e applicare la crittografia ai cluster etcd. Anche i container Kubernetes devono seguire il principio del privilegio minimo . L'autorizzazione dei nodi dovrebbe essere implementata tra gli altri elementi della lista di controllo della sicurezza di Kubernetes. Idealmente, gli utenti dovrebbero utilizzare diversi set di segreti per diversi ambienti Kubernetes.

È buona norma evitare di incorporare segreti nelle immagini. Si consiglia inoltre di abilitare la scansione in tempo reale dei segreti nei repository di codice sorgente e di verificarli. I segreti rischiano di essere scritti nei log e una delle migliori pratiche di sicurezza consiste nel trasmettere i segreti nei file. Impostare il volume montato come directory temporanea invece di scrivere sul disco. È anche possibile ruotare le chiavi segrete, scegliere diversi modi per memorizzarle e trasmetterle ai container per ottenere i migliori risultati. A volte è necessario riavviare le applicazioni per leggere le nuove password del database. Per gli utenti di flussi di lavoro basati su file, le password dei file possono essere aggiornate automaticamente senza riavvii.

#5. Controllori di ammissione

I controller di ammissione sono inclusi nella lista di controllo della sicurezza di Kubernetes per il 2025. Questi applicano i framework delle politiche di sicurezza di Kubernetes e fungono da seconda linea di difesa accanto ai controlli RBAC.

I controller di ammissione possono impostare regole basate su diversi parametri e limitare l'utilizzo delle risorse. Possono impedire l'esecuzione di comandi in container privilegiati e richiedere sempre ai pod di estrarre le immagini invece di utilizzare quelle memorizzate localmente nel nodo. Un altro vantaggio dei controller di ammissione è il monitoraggio delle richieste in entrata e l'impostazione di vincoli di risorse nei namespace. Si consiglia agli utenti di abilitare almeno i controller di ammissione predefiniti forniti da Kubernetes.

#6. Limiti di sicurezza di Kubernetes

I limiti di sicurezza di Kubernetes costituiscono la base della lista di controllo della sicurezza di Kubernetes. Impediscono ai processi di accedere ai dati di altri utenti e applicano politiche che offrono l'isolamento dei container. I modelli di ammissione LimitRanger e ResourceQuota impediscono la privazione delle risorse e, per quanto riguarda i pod, gli utenti possono definire contesti di sicurezza personalizzati e applicarli.

#7. Politiche di sicurezza Kubernetes

Gli standard di sicurezza dei pod sono soggetti a vari gradi di complessità. Le politiche di sicurezza dei pod Kubernetes sono configurate su una risorsa a livello di cluster e applicano l'uso di contesti di sicurezza e controller di ammissione. Il pod deve soddisfare i requisiti della politica di sicurezza dei pod, altrimenti non verrà eseguito. Le politiche di sicurezza dei pod vengono automaticamente rimosse da Kubernetes v1.25 e versioni successive, il che significa che gli utenti devono migrare al controller di ammissione Kubernetes Pod Security.

I contesti di sicurezza definiscono le impostazioni di controllo degli accessi e i privilegi per i container Kubernetes. Implementano controlli di accesso discrezionali, impostano le autorizzazioni per l'accesso agli oggetti in base agli ID di gruppo e configurano i processi senza privilegi.

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 autorizzazioni specifiche per le risorse, il che consente di adottare un approccio granulare. Gli utenti possono includere contesti di sicurezza con il codice del contesto di sicurezza presente nei file di distribuzione durante la creazione dei pod. Kubernetes è molto agile e gli utenti possono anche automatizzare la distribuzione dei profili tra i nodi. L'unico svantaggio è che non è supportato il contenitore Windows. Possono anche abilitare le autorizzazioni per proteggere account di servizio, nodi e utenti.

#8. Sicurezza di rete Kubernetes

La sicurezza di rete Kubernetes è una componente essenziale della lista di controllo della sicurezza Kubernetes. Aggiunge controlli che specificano come il traffico fluisce tra i container e definisce il tipo di traffico che deve essere bloccato. Gli utenti possono seguire un'architettura multi-cluster per isolare i carichi di lavoro e mitigare i problemi di sicurezza distribuendo i carichi di lavoro in cluster diversi. È possibile ottenere un elevato grado di isolamento dei container e ridurre contemporaneamente la complessità.

Esistono politiche di rete Kubernetes che aggiungono funzionalità di firewall e limitano il flusso di traffico tra i pod. Esso specifica quali pod comunicano con entità di rete selezionate. La politica di ingresso è consentita sulla porta di destinazione, mentre la politica di uscita deve essere sul pod di origine per consentire un flusso di traffico ottimale. Come regola generale, è consigliabile 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. Le reti di servizi Kubernetes possono semplificare il monitoraggio e fornire varie funzionalità relative al monitoraggio continuo e agli avvisi. Rilevano le minacce alla sicurezza e segnalano gli incidenti; sono disponibili molti progetti di service mesh. La checklist di sicurezza di Kubernetes suggerisce di utilizzare opzioni come Linkerd, Consul e Istio.

#9. Audit e registrazione di Kubernetes

È essenziale mantenere i registri degli eventi dei container e creare una traccia di audit per gli ambienti di produzione. La registrazione di audit di Kubernetes include la registrazione dell'identità delle immagini e degli utenti che richiamano i comandi di avvio e arresto. 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, i più popolari dei quali sono Cilium e Project Calico. Altri aspetti dell'auditing e della registrazione di Kubernetes includono la modifica dei payload dei container e dei mount dei volumi, il monitoraggio delle connessioni in entrata e in uscita e la correzione delle azioni non riuscite. La registrazione delle applicazioni è il modo più semplice per monitorare l'attività del cluster e può fornire informazioni utili per il debug delle applicazioni. L'implementazione della registrazione a livello di cluster e dei log push nei contenitori di archiviazione è una pratica standard che utilizza una piattaforma o un servizio di gestione dei log centralizzato.

Perché SentinelOne per la sicurezza di Kubernetes?

Cloud Workload Security (CWS) di SentinelOne’s per Kubernetes, parte della piattaforma Singularity™, offre una soluzione all'avanguardia progettata per affrontare efficacemente queste minacce moderne. Ecco come SentinelOne migliora la sicurezza di Kubernetes:

• Protezione dalle minacce in tempo reale: Singularity CWS monitora e protegge continuamente i carichi di lavoro Kubernetes da minacce come ransomware e vulnerabilità sconosciute. La sua tecnologia basata sull'intelligenza artificiale garantisce un rilevamento e una risposta rapidi, salvaguardando gli ambienti Kubernetes.
• Indagini sugli incidenti e ricerca delle minacce: Con Singularity Data Lake, SentinelOne fornisce informazioni complete sull'attività dei tuoi carichi di lavoro. Questo strumento aiuta a indagare sugli incidenti e a condurre la ricerca delle minacce. Il Workload Flight Data Recorder™ assiste nel ripristino dopo gli incidenti rimuovendo i carichi di lavoro problematici, riducendo al minimo le perdite finanziarie e i danni.
• Ampia compatibilità: SentinelOne supporta un'ampia gamma di carichi di lavoro containerizzati, tra cui 14 principali distribuzioni Linux, tre popolari runtime container e servizi Kubernetes gestiti e autonomi.

Conclusione

I principi di base della Lista di controllo per la sicurezza di Kubernetes 2025 ruotano attorno all'autenticazione, alla gestione della sicurezza dei pod, alla gestione dei segreti e ad altri componenti. Seguendo queste pratiche, le organizzazioni possono proteggere gli ambienti Kubernetes e garantire che l'accesso ai dati sia limitato. Questi suggerimenti semplificano la sicurezza di Kubernetes e la sicurezza a livelli per ridurre le complessità dell'architettura. Quando gli utenti ottimizzano la sicurezza di Kubernetes per il cloud, diventa facile integrarla con altri flussi di lavoro di sicurezza.

"

Domande frequenti sulla checklist di sicurezza di Kubernetes

Che cos'è una checklist di sicurezza Kubernetes?

Una checklist di sicurezza Kubernetes è un elenco di passaggi da seguire per proteggere il proprio cluster. Comprende la protezione del server API, etcd e kubelet; l'applicazione di RBAC; l'isolamento dei pod con politiche di sicurezza di rete e dei pod; la crittografia dei segreti; e l'auditing degli eventi.

La checklist funge da guida per garantire che ogni componente critico, dal piano di controllo ai carichi di lavoro, soddisfi gli standard di sicurezza di base.

Perché è importante una checklist di sicurezza Kubernetes?

I cluster Kubernetes gestiscono carichi di lavoro critici e qualsiasi errore può esporre dati sensibili o consentire agli aggressori di muoversi lateralmente. Una checklist previene gli scostamenti: consente di applicare in modo coerente i controlli concordati, individuare le lacune, come porte API aperte o RBAC eccessivamente permissivi, e mantenere la conformità. Seguire regolarmente la checklist riduce le sorprese e mantiene i cluster protetti sia dalle minacce note che da quelle emergenti.

Cosa dovrebbe essere incluso in una checklist di sicurezza Kubernetes per i cluster di produzione?

La checklist di produzione dovrebbe includere: limitazione dell'accesso al server API alle reti affidabili; abilitazione dei log di audit; crittografia dei dati etcd inattivi; applicazione di RBAC con privilegi minimi; applicazione di politiche di sicurezza o di ammissione dei pod; utilizzo di politiche di rete per isolare i servizi; protezione delle immagini dei container; rotazione dei certificati; e convalida della sicurezza della pipeline CI/CD. Ogni elemento blocca un livello del cluster prima che il traffico o i carichi di lavoro diventino attivi.

Con quale frequenza i team dovrebbero rivedere la loro checklist di sicurezza Kubernetes?

I team dovrebbero rivedere la checklist almeno trimestralmente e dopo ogni aggiornamento importante della versione di Kubernetes o modifica dell'architettura. Revisioni frequenti consentono di individuare eventuali scostamenti nella configurazione, come nuove porte aperte o regole RBAC meno rigorose, e garantiscono che i controlli si adattino alle nuove minacce o ai componenti aggiunti.

Anche modifiche critiche, come nuovi spazi dei nomi o controller di ammissione personalizzati, richiedono una revisione immediata della checklist.

Quali strumenti aiutano a verificare la checklist di sicurezza di Kubernetes?

Strumenti open source come kube-bench verificano il cluster rispetto ai benchmark CIS Kubernetes. Kube-hunter ricerca esposizioni e configurazioni errate. Polaris convalida i carichi di lavoro in tempo reale rispetto alle politiche personalizzate. I log di audit nativi di Kubernetes vengono inviati ai SIEM per il monitoraggio degli eventi.

Combinati, questi strumenti automatizzano i controlli delle impostazioni del piano di controllo, RBAC, politiche di rete e altro ancora, rendendo più facile individuare e correggere le deviazioni dalla checklist.

Dove posso scaricare o accedere a un esempio di checklist di sicurezza Kubernetes?

Puoi iniziare con la checklist di sicurezza ufficiale di Kubernetes su GitHub (kubernetes.io/docs/concepts/security/security-checklist/) o con guide gestite dalla community come il repository krol3/kubernetes-security-checklist.

Molti fornitori di servizi cloud e di sicurezza pubblicano anche liste di controllo in formato PDF scaricabili: basta cercare "Kubernetes Security Checklist PDF" per trovare esempi che puoi adattare al tuo ambiente.

Chi è responsabile dell'implementazione della checklist di sicurezza di Kubernetes?

L'implementazione è uno sforzo condiviso tra DevOps, ingegneri di piattaforma e team di sicurezza. Gli ingegneri della piattaforma configurano i componenti del piano di controllo e le politiche di rete. I team DevOps proteggono i carichi di lavoro e le pipeline CI/CD.

I team di sicurezza definiscono i controlli di base, eseguono audit e monitorano la conformità. Insieme, garantiscono che ogni voce della checklist, dalle regole RBAC alle politiche di sicurezza dei pod, sia applicata e convalidata.