Best practice di sicurezza Kubernetes: hardening dalla build al runtime

Kubernetes viene fornito con impostazioni predefinite permissive, quindi la sicurezza del cluster è una tua responsabilità. Scopri le best practice di sicurezza Kubernetes nelle fasi di build, deploy e runtime.

Che cos'è la sicurezza di Kubernetes?

La sicurezza di Kubernetes è l'insieme dei controlli che applichi nelle fasi di build, deployment e runtime per proteggere un cluster, i workload che esegue e la pipeline che lo alimenta. Senza questi controlli, una singola richiesta non autenticata può compromettere l'intero cluster. È quanto accaduto con IngressNightmare, la vulnerabilità con gravità 9.8 resa nota a marzo 2025 in ingress-nginx, il controller in esecuzione in oltre il 40% dei cluster Kubernetes.

Il suo admission webhook si trovava sulla rete dei pod senza autenticazione e ingress-nginx legge per impostazione predefinita ogni Secret nel cluster. Raggiungi la rete, controlli il cluster. Non è servita alcuna catena di exploit, nessuna password rubata: solo impostazioni predefinite permissive che facevano esattamente ciò per cui erano state configurate.

Questo divario, tra ciò che Kubernetes fornisce di default e ciò di cui un cluster di produzione ha bisogno, è ciò che l'hardening colma. Le best practice di sicurezza di Kubernetes sono il modo in cui lo colmi, fase dopo fase, dall'immagine che crei al workload che esegui. Poiché l'orchestrazione centralizza workload, secret e traffico est-ovest in un unico control plane, una singola configurazione errata può esporre ogni servizio che esegui, ed è per questo che questo lavoro ricade su di te e non sulla piattaforma.

Perché la sicurezza di Kubernetes è importante?

Kubernetes non si protegge da solo. La guida CISA/NSA per l'hardening di Kubernetes documenta tre impostazioni predefinite significative presenti in ogni nuovo cluster: l'accesso anonimo all'API server è abilitato, i Secret sono archiviati senza crittografia in etcd e l'audit logging è disattivato. Il modello di responsabilità condivisa mette quattro controlli nelle tue mani: role-based access control (RBAC), network policy, crittografia dei secret e controlli di runtime. Il cloud provider non li configurerà per te, e nemmeno la distribuzione. Poiché questi controlli risiedono nella tua configurazione e cambiano nel tempo, i team li verificano sempre più spesso in modo continuo con il Kubernetes security posture management invece di eseguire audit manuali.

Un attaccante che raggiunge un API server non autenticato può leggere ogni Secret in etcd, pianificare un pod su qualsiasi nodo e spostarsi tra namespace mentre l'audit logging rimane silenzioso, quindi il primo segnale che ricevi potrebbe essere la violazione stessa. Un singolo endpoint esposto diventa accesso all'intero cluster in pochi minuti, lo stesso schema seguito da IngressNightmare.

La posta in gioco cresce con l'adozione. Il sondaggio annuale Cloud Native della Cloud Native Computing Foundation (CNCF) riporta che l'82% degli utenti di container ora esegue Kubernetes in produzione, rispetto al 66% del 2023. Poiché i cluster si trovano nel percorso di servizi rivolti ai clienti, dati regolamentati e obblighi di audit, un singolo controllo mancante si traduce in esposizione a violazioni, audit non superati e incidenti segnalabili di cui il tuo team deve rispondere. Sapere cosa è in gioco conta solo quando sai quali parti del cluster comportano questo rischio.

Componenti principali di un cluster Kubernetes

Non puoi rafforzare ciò che non hai inventariato. Ogni componente comporta una specifica esposizione alla sicurezza e comprenderla ti dice dove devono essere applicati i controlli.

Componenti del control plane:

• API server: Ogni comando kubectl che esegui, ogni admission webhook e ogni richiesta di token di service account passa attraverso l'API server. Un accesso non autorizzato qui significa controllo completo del cluster.
• etcd: Memorizza tutto lo stato del cluster, la configurazione e i Secret da cui dipendi. L'accesso in lettura a etcd equivale di fatto ai privilegi di root sull'intero cluster.
• Scheduler e controller manager: Uno scheduler compromesso può collocare workload su nodi specifici per sfruttare risorse locali. La manipolazione dei controller può alterare deployment, conteggi di repliche e assegnazioni di risorse in modo silenzioso.

Componenti dei worker node:

• kubelet: L'agente su ogni nodo che esegue le specifiche dei pod. Se lasci esposta l'API di kubelet, un attaccante può creare container o eseguire comandi direttamente sul nodo.
• kube-proxy: Gestisce le regole di rete per l'instradamento dei servizi. Regole proxy configurate in modo errato possono esporre i servizi interni al traffico esterno.
• Container runtime: Esegue i container sull'host. Un runtime vulnerabile espone ogni container che supporta e l'host stesso, come osserva NIST SP 800-190.

Pod, container e networking:

• I pod condividono i namespace di rete, quindi un container compromesso in un pod può accedere ad altri container nello stesso pod senza controlli di rete. Senza oggetti NetworkPolicy, i pod in namespace diversi comunicano liberamente per impostazione predefinita. 
• Le immagini dei container e i template di infrastructure-as-code (IaC) entrano nel cluster da registry esterni e un'immagine compromessa introdotta in produzione si propaga su ogni nodo che la pianifica. Mappare ogni componente alla sua esposizione ti dice esattamente dove si applicano i controlli di hardening descritti in questa guida.

Come funziona la sicurezza di Kubernetes lungo il ciclo di vita dalla build al runtime

Proteggi Kubernetes attraverso un flusso di lavoro continuo, non con un controllo puntuale. Ogni fase applica una diversa categoria di controlli e l'output di una fase diventa l'input della successiva. Ecco cosa accade in ogni passaggio.

1. Build time: esegui la scansione delle immagini dei container per vulnerabilità note, convalidi i template IaC rispetto alle policy, firmi crittograficamente le immagini e generi una software bill of materials (SBOM). Questi controlli preventivi bloccano i problemi all'origine, prima che qualsiasi artefatto possa essere pianificato.
2. Deploy e configurazione: Quando invii un workload, gli admission controller lo valutano rispetto alle policy prima della pianificazione. RBAC determina chi può creare, modificare o leggere risorse e le network policy definiscono quali pod possono comunicare. L'immagine che hai firmato in fase di build è protetta qui solo se l'admission control verifica effettivamente la firma.
3. Configurazione del control plane e dei nodi: Configuri API server, etcd, kubelet e il sistema operativo del nodo per ridurre ciò che è esposto. Autenticazione, autorizzazione e crittografia definiscono il confine di fiducia su cui si basa ogni altra fase, quindi un control plane debole indebolisce tutto ciò che segue.
4. Runtime: Gli strumenti di monitoraggio osservano anomalie comportamentali, drift di configurazione e pattern di attacco noti nei workload in esecuzione, mentre i profili seccomp e AppArmor limitano le system call che i container possono effettuare. Il runtime è anche il punto in cui intercetti le lacune che build e deploy non hanno rilevato.

Chiudi il ciclo quando i risultati del runtime ritornano nella fase di build sotto forma di immagini aggiornate, IaC aggiornato e policy di admission aggiornate. Il ciclo di vita funziona solo quando ogni passaggio intermedio regge. Ecco il costo di un singolo passaggio fallito.

Impatto di un cluster Kubernetes compromesso

Quando il cluster viene compromesso, le conseguenze vanno ben oltre un singolo workload.

• Movimento laterale e blast radius: I cluster eseguono da decine a migliaia di pod che condividono la connettività di rete. Un attaccante che ottiene accesso a uno dei pod può spostarsi lateralmente tra namespace e nodi quando RBAC concede privilegi eccessivi e le network policy sono assenti.
• Esposizione dei secret: etcd contiene chiavi API, credenziali di database, certificati TLS e token di servizio. Poiché i Secret non sono crittografati per impostazione predefinita, un attaccante con accesso in lettura a etcd può estrarre ogni credenziale nel cluster.
• Propagazione della supply chain: Un'immagine container compromessa distribuita tramite la pipeline di continuous integration e continuous delivery (CI/CD) raggiunge ogni nodo che la pianifica. Nei cluster che eseguono centinaia di repliche, una singola immagine compromessa può eseguire codice malevolo sull'intera infrastruttura in pochi minuti.
• Compromissione di workload e dati: Database di produzione, applicazioni rivolte ai clienti e servizi interni vengono eseguiti fianco a fianco. Una violazione in un workload può esporre dati sensibili, interrompere la disponibilità del servizio o stabilire persistenza per attacchi futuri.
• Esposizione normativa e di conformità: Se i cluster elaborano dati di pagamento, cartelle cliniche o workload governativi, rientrano nei requisiti PCI DSS, HIPAA, FedRAMP e SOC 2. Un cluster configurato in modo errato che non supera un audit può comportare interruzioni operative e sanzioni finanziarie.

L'hardening riduce il blast radius di qualsiasi singola compromissione, abbrevia i tempi di incident response e produce le evidenze di audit richieste dal programma di conformità. Ottenere questo risultato nella pratica è più difficile di quanto sembri, per ragioni specifiche del funzionamento di Kubernetes.

Sfide nella protezione di Kubernetes

La sicurezza di Kubernetes è operativamente complessa, anche per i membri più esperti del team. L'ephemeralità della piattaforma, il modello di configurazione dichiarativo e l'architettura distribuita creano attriti che gli strumenti di sicurezza statici non sono stati progettati per gestire.

• Workload effimeri e in costante cambiamento: I pod vengono creati, distrutti e ripianificati continuamente. Un'istantanea della postura del cluster alle 9:00 potrebbe non riflettere il suo stato alle 9:05.
• Lacune di visibilità nei container in esecuzione: I container condividono il kernel dell'host ma isolano processi, filesystem e stack di rete. I normali strumenti di monitoraggio basati su host spesso non hanno il contesto necessario per distinguere il comportamento normale dei container da attività malevole.
• Complessità della configurazione e drift: Un cluster di produzione coinvolge centinaia di manifest YAML, binding RBAC e regole di admission. Il drift tra ciò che dichiari in Git e ciò che viene eseguito nel cluster introduce esposizioni non tracciate.
• Proliferazione multi-cluster e multi-cloud: Se esegui cluster su Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP) e ambienti on-premises, devi applicare policy coerenti tra diversi servizi gestiti, ciascuno con il proprio confine di responsabilità condivisa.
• Strumenti frammentati: La scansione delle immagini, la gestione di RBAC, l'applicazione delle network policy, il monitoraggio del runtime e il reporting di conformità richiedono spesso strumenti separati senza un modello dati condiviso. La correlazione degli avvisi ricade su di te.
• Competenze specialistiche e attriti organizzativi: Le competenze specialistiche sono scarse e il sondaggio CNCF 2025 ha rilevato che per la prima volta il principale ostacolo all'adozione cloud native è organizzativo piuttosto che tecnico: comunicazione interna, dinamiche di team e allineamento della leadership. I controlli non vengono applicati perché nessuno ne è responsabile.

Questi vincoli influenzano sia le scelte degli strumenti sia le priorità di assunzione e spiegano perché gli stessi errori si ripresentano nei cluster.

Errori comuni nella sicurezza di Kubernetes

Specifici anti-pattern operativi creano le esposizioni che gli attaccanti sfruttano. Identifica ed elimina ciascuno di questi nei tuoi cluster:

• Eseguire container privilegiati o come root. I container privilegiati aggirano tutto l'isolamento del kernel Linux. Un container eseguito come root con allowPrivilegeEscalation: true può evadere verso l'host.
• Concedere cluster-admin o RBAC con wildcard. I permessi wildcard (resources: ["*"], verbs: ["*"]) si estendono automaticamente a risorse API che non esistono ancora. La documentazione di Kubernetes etichetta questo pattern come "DO NOT USE."
• Lasciare in vigore il networking default-allow. Senza oggetti NetworkPolicy, i pod in namespace diversi comunicano liberamente.
• Archiviare Secret in manifest in chiaro. Effettuare il commit delle credenziali in Git o passarle come variabili d'ambiente le espone in crash dump, log e cronologia della shell.
• Saltare la scansione di immagini e IaC. Distribuire immagini non sottoposte a scansione consente alle vulnerabilità di raggiungere la produzione senza controlli.
• Trattare l'hardening come un controllo una tantum. Un cluster rafforzato al bootstrap va incontro a drift man mano che i team aggiungono workload e modificano configurazioni. Senza applicazione continua, la postura si degrada.
• Ignorare la configurazione dei nodi e del control plane. Lasciare abilitato l'accesso anonimo all'API server, saltare la crittografia di etcd e omettere l'audit logging sono stati predefiniti che richiedono una correzione esplicita da parte tua.

Ognuno di questi problemi è correggibile con le pratiche riportate di seguito. Considerali come una checklist di esposizioni da eliminare prima di scalare ulteriori workload sul cluster.

Best practice di sicurezza di Kubernetes

Queste best practice di sicurezza di Kubernetes costituiscono il nucleo operativo dell' hardening del cluster Kubernetes, organizzato secondo le stesse quattro fasi del ciclo di vita introdotte sopra. Affrontale in ordine, perché ogni fase presuppone che la precedente sia solida.

Proteggere la fase di build

1. Esegui la scansione delle immagini per rilevare vulnerabilità prima che raggiungano un registry. Integra la scansione delle immagini dei container nelle pipeline CI in modo che le immagini vulnerabili non diventino mai artefatti distribuibili.
2. Usa immagini di base minime o distroless. Le immagini distroless contengono solo l'applicazione e le relative dipendenze di runtime, senza shell, package manager o binari non necessari. Fissa le immagini a suffissi di versione espliciti (e.g., gcr.io/distroless/static-debian13) e non usare mai il latest tag.
3. Firma e verifica le immagini. Usa Cosign o Notary per firmare le immagini in CI. Configura gli admission controller per rifiutare immagini non firmate o non verificate al momento del deploy.
4. Esegui la scansione di IaC e dei manifest Kubernetes. Convalida Terraform, Helm chart e YAML grezzo rispetto alle policy di sicurezza prima che raggiungano il cluster.
5. Genera un SBOM per ogni immagine per stabilire la provenienza e supportare il tracciamento delle vulnerabilità dopo il deployment.
6. Tieni i secret fuori dalle immagini. Non incorporare mai credenziali, chiavi API o certificati nelle immagini dei container o nei Dockerfile.

Questi controlli della fase di build tengono artefatti vulnerabili e non firmati fuori dalla pipeline prima che qualsiasi elemento possa essere eseguito. Un'immagine che li supera è comunque sicura solo se il cluster la ammette correttamente, ed è qui che subentra la configurazione al momento del deploy.

Hardening della configurazione del cluster e del deployment

Queste best practice Kubernetes RBAC e i controlli di rete trasformano le policy di deploy in guardrail applicati.

1. Applica RBAC con privilegio minimo. Crea Role con ambito namespace con verbi espliciti e nomi di risorse espliciti. Elimina le concessioni wildcard. Limita cluster-admin all'uso break-glass. Imposta automountServiceAccountToken: false sui service account che non necessitano di accesso API.

2. Applica network policy default-deny. Applica una default-deny-all Netwenforce mode con il livello restrictedorkPolicy, sia ingress sia egress, a ogni namespace al bootstrap. Aggiungi regole di allow esplicite per workload, inclusa un'eccezione DNS egress sulla porta UDP 53.

3. Applica il Restricted Pod Security Standard. Usa Pod Security Admission in modalità enforce con il restricted level per i namespace di produzione. Questo blocca i container privilegiati, richiede runAsNonRoot, impone profili seccomp e limita i tipi di volume.

4. Aggiungi admission control con OPA Gatekeeper o Kyverno. Applica readOnlyRootFilesystem: true, allowPrivilegeEscalation: false, allowlist dei registry di immagini e policy di capability drop-ALL. Usa prima la modalità dryrun per verificare i workload esistenti prima di passare a deny.

5. Gestisci i Secret in uno store esterno con crittografia di etcd at rest. Usa il provider key management service (KMS) v2 per la crittografia envelope e monta i Secret come volumi tramite Secrets Store CSI Driver, che usa tmpfs in modo che i dati segreti non raggiungano mai il disco del nodo. Evita di passare i Secret come variabili d'ambiente.

6. Imposta limiti di risorse. Definisci richieste e limiti di CPU e memoria su ogni container per prevenire l'esaurimento delle risorse.

Con le policy di deploy applicate, i workload vengono eseguiti con privilegio minimo e networking default-deny. La fiducia su cui si basano questi guardrail risiede ancora nel control plane e nei nodi sottostanti, quindi rafforza quelli successivamente.

Proteggere il control plane e i worker node

Il control plane è l'unico punto in cui una singola impostazione debole si ripercuote su tutto il resto. Configura ciascuno di questi elementi, quindi verificali secondo una pianificazione invece di farlo una sola volta al bootstrap.

Fase di hardening	Cosa configurare	Fonte
Accesso all'API server	Richiedi autenticazione forte e mutual TLS; mantieni l'API server fuori da internet pubblico.	CIS Benchmark
Autenticazione anonima	Imposta --anonymous-auth=false	Guida CISA/NSA
Audit logging	Abilita log di audit API, metriche, applicazione e seccomp; aggregali fuori dal cluster e genera avvisi su di essi	Guida CISA/NSA
etcd	Crittografa at rest, richiedi mutual TLS e isola dietro un firewall raggiungibile solo dagli API server	CIS Benchmark
kubelet	Limita l'accesso API, disabilita le porte di sola lettura, applica configurazioni a livello di nodo	CIS Benchmark
Baseline del nodo	Allinea control plane, etcd e nodi al CIS Kubernetes Benchmark per la tua release; esegui scansioni con cadenza continua	CIS Benchmark
Versioni	Applica patch a Kubernetes, al sistema operativo del nodo e al container runtime con cadenza regolare	—

Con il control plane bloccato e i nodi aggiornati, le fondamenta reggono. Un workload attivo può comunque andare incontro a drift rispetto allo stato dichiarato o essere attaccato dall'interno, ed è qui che intervengono i controlli di runtime.

Sicurezza runtime e rilevamento delle minacce

Una solida Kubernetes runtime security rileva ciò che i controlli statici non possono rilevare.

1. Monitora il comportamento a runtime. Distribuisci uno strumento di sicurezza runtime nativo per container che osservi syscall anomale, esecuzione imprevista di processi, connessioni di rete e modifiche ai file. NIST SP 800-190 afferma che i tradizionali strumenti intrusion prevention system (IPS) e web application firewall (WAF) non forniscono una protezione adeguata per i container.
2. Rileva il drift di configurazione. Confronta i workload in esecuzione con il loro stato dichiarato in Git. Segnala i container che si sono discostati dall'immagine o dalla configurazione originale.
3. Applica profili seccomp e AppArmor o SELinux. Usa almeno i profili seccomp RuntimeDefault. Distribuisci prima profili personalizzati su un sottoinsieme di nodi, quindi estendili all'intero cluster dopo la convalida.
4. Esegui filesystem root in sola lettura e rimuovi capability non necessarie. Imposta readOnlyRootFilesystem: true e capabilities: drop: [ALL] su ogni container di produzione.
5. Applica runAsNonRoot. Richiedi runAsNonRoot: true nei security context dei pod. Crea immagini che vengano eseguite come utente non root in fase di build invece di affidarti solo a override al momento del deployment.
6. Abilita risposta autonoma e audit logging continuo. Correla gli avvisi di runtime con i log di audit per ricostruire le timeline degli attacchi. Riporta i risultati nelle policy di build-time per chiudere il ciclo.

Insieme, queste quattro fasi producono un cluster continuamente rafforzato. I benchmark di settore descrivono cosa significa essere "configurato correttamente" in ogni fase e dovresti misurare il cluster rispetto a essi.

Standard di sicurezza e conformità di Kubernetes

I benchmark riconosciuti dal settore rendono operative le pratiche descritte sopra e forniscono le evidenze di audit richieste dal programma di conformità Kubernetes.

Standard	Ambito	Rilevanza
CIS Kubernetes Benchmark	Control plane, etcd, worker node, policy	Riconosciuto da PCI DSS, FedRAMP, SOC 2, FISMA e dal NIST National Checklist Program
CISA/NSA Kubernetes Hardening Guidance	Build, deploy, rete, RBAC, logging, runtime	Baseline governativa autorevole per cluster federali e di infrastrutture critiche
Pod Security Standards	Restrizioni dei privilegi a livello di pod su tre livelli	Meccanismo di enforcement integrato in Kubernetes; mappa direttamente alla Tabella I della guida CISA/NSA
NIST SP 800-190	Sicurezza del ciclo di vita dei container	Mappa i controlli dei container a NIST SP 800-53 Rev 5 (AU-2, CM-2, SC-7, IR-4 e altri)

Ora che Kubernetes è la piattaforma di produzione predefinita, i framework di conformità trattano sempre più spesso i controlli specifici di Kubernetes come un dominio di audit distinto piuttosto che come un sottoinsieme della sicurezza generale dell'infrastruttura. 

Benchmark specifici della piattaforma, come il benchmark CIS GKE e il CIS OpenShift Benchmark, estendono il benchmark generale con controlli specifici per i servizi gestiti. Conoscere gli standard è il punto di partenza. La domanda più difficile è dove si stia dirigendo la sicurezza di Kubernetes.

Tendenze future nella sicurezza di Kubernetes

I controlli che implementi oggi poggiano su basi in evoluzione e tre tendenze stanno rimodellando il modo in cui i team affrontano le best practice di sicurezza di Kubernetes.

1. I workload AI spostano la superficie di attacco. Poiché i cluster stanno diventando l'ambiente predefinito per workload di AI e machine learning, la pianificazione delle GPU, gli artefatti dei modelli e i grandi dataset di training diventano nuovi obiettivi. Proteggere la supply chain dei dati e dei modelli sta diventando parte dell'hardening del cluster, non una preoccupazione separata.
2. L'integrità della software supply chain diventa obbligatoria. La generazione di SBOM, gli artefatti firmati e l'attestazione della provenienza stanno passando da indicatori opzionali di maturità a requisiti di base nei settori regolamentati e negli approvvigionamenti governativi.
3. La difesa runtime autonoma sostituisce il triage manuale. Il volume e la velocità dell'attività del cluster superano la capacità di revisione umana. L'AI comportamentale che distingue l'attività normale da quella anomala dei workload e risponde senza attendere un analista sta passando da elemento distintivo a impostazione predefinita.

Ogni tendenza punta nella stessa direzione: più automazione nelle prime fasi del ciclo di vita e maggiore autonomia nel runtime, che è il punto in cui gli strumenti di piattaforma dimostrano il loro valore.

Rafforza la sicurezza di Kubernetes con SentinelOne

I controlli nativi di Kubernetes trattati in questa guida, RBAC, NetworkPolicy, Pod Security Standards, crittografia di etcd e audit logging, costituiscono la base dell'hardening del cluster. SentinelOne aggiunge posture management, scansione della supply chain, K8s admission control e rilevamento delle minacce a runtime, ciascuno associato a una debolezza indicata in questa guida.

Singularity Cloud Security esegue la scansione dei cluster Kubernetes prima ancora che vengano eseguiti. La scansione in fase di build si integra direttamente con pipeline CI/CD, sistemi di controllo versione e registry di container. Verifica vulnerabilità note e oltre 750 tipi di secret esposti. La stessa scansione copre i template infrastructure-ascode, inclusi Terraform, Helm, CloudFormation e Kubernetes YAML, per rilevare tempestivamente le violazioni delle policy. Un Kubernetes Admission Controller agisce come gatekeeper finale presso l'API server, bloccando immagini non autorizzate o note come malevole prima del deployment.

Kubernetes Security Posture Management (KSPM) colma le lacune di visibilità nel cluster. Costruisce un inventario unificato tra cluster, nodi, namespace e deployment, quindi evidenzia accessi eccessivamente permissivi e configurazioni rischiose. L'Offensive Security Engine™ simula quindi attacchi reali, confermando tramite Verified Exploit Paths™ quali configurazioni errate sono effettivamente raggiungibili dagli attaccanti. I team di sicurezza danno priorità a ciò che è sfruttabile invece di fare triage su ogni singolo rilevamento. Lo stesso motore di regole alimenta l'Admission Controller, così la policy rimane coerente dalla postura fino al deployment.

Nel runtime, Singularity Cloud Workload Security basato su extended Berkeley Packet Filter (eBPF) rileva comportamenti anomali alla velocità della macchina. Le risposte automatizzate terminano i processi malevoli e mettono in quarantena i file infetti senza attendere un analista. Graph Explorer visualizza le relazioni nell'intera superficie di attacco Kubernetes, così i team vedono esattamente cosa è esposto. Quando il rilevamento runtime segnala un'immagine malevola, quel risultato viene automaticamente riportato all'Admission Controller. L'immagine viene quindi bloccata da ogni deployment futuro, trasformando un singolo rilevamento in una policy duratura. Purple AI porta threat hunting in linguaggio naturale e riepiloghi degli eventi alla telemetria dei cloud workload su un unico data lake, così gli analisti interrogano in linguaggio naturale invece di passare da uno strumento all'altro.

Scopri dove i tuoi cluster sono esposti in produzione. Richiedi una demo di SentinelOne per vedere Kubernetes posture management e rilevamento delle minacce runtime nel tuo ambiente.

Fai un tour

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.

Punti chiave

Kubernetes viene fornito con impostazioni predefinite permissive che lasciano la sicurezza del cluster nelle tue mani. Le best practice di sicurezza di Kubernetes in questa guida coprono quattro fasi: scansione e firma delle immagini in fase di build, RBAC e NetworkPolicy al deploy, crittografia di etcd e audit logging nel control plane e monitoraggio comportamentale nel runtime. 

Allinea la configurazione al CIS Benchmark e alla guida CISA/NSA, elimina gli errori comuni identificati sopra e chiudi il ciclo riportando i risultati del runtime nelle policy di build-time. Quando ci riesci, smetti di andare a tentativi. Puoi indicare qualsiasi namespace in qualsiasi giorno e mostrare cosa viene applicato, cosa è andato in drift e cosa hai fatto al riguardo.

FAQ

Quali impostazioni di Kubernetes sono non sicure per impostazione predefinita?

Tre impostazioni vengono distribuite come non sicure in ogni nuovo cluster Kubernetes. La CISA/NSA Kubernetes Hardening Guidance v1.2 le documenta: l'accesso anonimo al server API è abilitato, i Secrets sono archiviati senza crittografia in etcd e il logging di audit è disabilitato. 

La comunicazione da pod a pod non è soggetta a restrizioni senza oggetti NetworkPolicy. Devi applicare tu stesso l'hardening di queste impostazioni. Né il cloud provider né la distribuzione Kubernetes applicano questi controlli per tuo conto nel modello di responsabilità condivisa.

Qual è la differenza tra la sicurezza Kubernetes e la sicurezza dei container?

La sicurezza dei container e la sicurezza di Kubernetes operano a livelli diversi dello stesso stack. La sicurezza dei container si concentra sull'immagine e sull'istanza del container: scansione delle vulnerabilità, isolamento in fase di runtime, rimozione delle capability e protezione del kernel host. 

La sicurezza di Kubernetes comprende sia i singoli container sia il cluster che li circonda, aggiungendo RBAC, controllo di ammissione, criteri di rete, etcd e registrazione di audit dell'orchestrazione. La sicurezza dei container rientra nella più ampia disciplina della sicurezza di Kubernetes.

In che modo i Pod Security Standards si relazionano alle Pod Security Policies deprecate?

Le Pod Security Policies (PSP) sono state deprecate in Kubernetes v1.21 e rimosse in v1.25. I Pod Security Standards (PSS) definiscono tre livelli di policy (Privileged, Baseline, Restricted) e sono applicati da Pod Security Admission (PSA), un controller di admission integrato che applica le policy a livello di namespace tramite label. 

PSA è diventato stabile in v1.25. Se il tuo cluster esegue la versione v1.25 o successiva e non hai configurato PSA, stai operando senza il livello di enforcement a livello di pod.

Quali benchmark di conformità si applicano ai cluster Kubernetes?

Quattro framework di conformità principali si applicano ai cluster Kubernetes. Il CIS Kubernetes Benchmark è riconosciuto da PCI DSS, FedRAMP, SOC 2 e FISMA. La CISA/NSA Kubernetes Hardening Guidance funge da riferimento di base per il settore governativo. 

NIST SP 800-190 associa i controlli dei container alle famiglie di controlli di NIST SP 800-53 Rev 5. I Pod Security Standards forniscono il meccanismo di applicazione integrato che si allinea direttamente alla guida CISA/NSA.

I servizi gestiti come EKS, AKS e GKE gestiscono per te la sicurezza del cluster?

I servizi Kubernetes gestiti si occupano della disponibilità del control plane, dell'applicazione delle patch e di parte della sicurezza dell'infrastruttura. Rimangono comunque di tua responsabilità le policy RBAC, gli oggetti NetworkPolicy, Pod Security Admission, la crittografia dei Secrets e il monitoraggio del runtime. 

Si applica il modello di responsabilità condivisa: il provider protegge l'infrastruttura del control plane e tu proteggi i workload, la configurazione e i controlli di accesso. I CIS Benchmarks specifici della piattaforma documentano i controlli aggiuntivi che devi applicare su ciascun servizio gestito.