Il tuo cluster Kubernetes è sicuro o è semplicemente in esecuzione?Le configurazioni predefinite di Kubernetes danno priorità alla facilità d'uso rispetto alla sicurezza. Senza un rafforzamento deliberato, i cluster sono vulnerabili alla fuga di container, all’escalation dei privilegi, allo spostamento laterale e al furto di dati. Questa lista di controllo copre tutti i controlli di sicurezza che devi implementare per gli ambienti di produzione Kubernetes.
Punti chiave
- L'impostazione predefinita Kubernetes non è sicura:Le configurazioni predefinite consentono contenitori privilegiati, accesso alla rete illimitato e ampie autorizzazioni del server API.
- RBAC è la tua prima difesa:Limita l'accesso al server API al minimo richiesto per ciascun account di servizio e utente.
- Le politiche di rete impediscono il movimento laterale:Senza policy di rete, ogni pod può comunicare con ogni altro pod: una rete piatta all'interno del tuo cluster.
- Gli standard di sicurezza dei pod sostituiscono PSP:Pod Security Admission (PSA) applica vincoli di sicurezza su tutti i pod.
- La sicurezza della catena di fornitura è importante:Verifica la provenienza delle immagini, esegui la scansione delle vulnerabilità e applica le policy relative alle immagini attraverso il controllo dell'ammissione.
Kubernetes Lista di controllo della sicurezza
API Sicurezza del server
- Abilita RBAC e disabilita l'autenticazione anonima
- Utilizza l'autenticazione forte (OIDC, basata su certificati), non l'autenticazione di base o i token statici
- Limita l'accesso al server API agli intervalli IP conosciuti (gestito Kubernetes: utilizza reti autorizzate)
- Abilita la registrazione di controllo per tutte le richieste del server API
- Disabilita funzionalità alpha/beta nei cluster di produzione
- Configura i controller di ammissione: PodSecurity, ResourceQuota, LimitRange
Migliori pratiche RBAC
- Segui il privilegio minimo: nessuna associazione ClusterAdmin per gli account di servizio
- Utilizzare ruoli con spazio dei nomi anziché ClusterRoles ove possibile
- Controlla regolarmente RBAC con strumenti come kubectl-who-can e rbac-lookup
- Non concedere mai autorizzazioni con caratteri jolly (verbi: ["*"], risorse: ["*"])
- Limita l'accesso ai segreti: concedi get/list sui segreti solo ai pod che ne hanno bisogno
- Utilizza account di servizio separati per applicazione (non l'account di servizio predefinito)
Sicurezza della rete
- Implementare i criteri di rete con rifiuto predefinito in tutti gli spazi dei nomi
- Consenti solo il traffico in entrata e in uscita richiesto per applicazione
- Utilizzare un CNI che supporti NetworkPolicies (Calico, Cilium, Antrea)
- Crittografa la comunicazione tra pod con la rete di servizi mTLS (Istio, Linkerd)
- Limitare l'uscita agli endpoint esterni noti (impedire l'esfiltrazione dei dati)
- Isola i carichi di lavoro sensibili in spazi dei nomi dedicati con policy rigorose
Sicurezza del pod
- Abilita l'ammissione alla sicurezza dei pod a livello di spazio dei nomi (applica il profilo "limitato")
- Esegui i contenitori come non root (runAsNonRoot: true)
- Utilizza il filesystem root di sola lettura (readOnlyRootFilesystem: true)
- Elimina tutte le funzionalità, aggiungi solo ciò che è necessario (rilascia: ["ALL"])
- Disabilita l'escalation dei privilegi (allowPrivilegeEscalation: false)
- Imposta i limiti delle risorse (CPU, memoria) su tutti i contenitori per prevenire l'abuso delle risorse
- Non montare il token dell'account di servizio se non necessario (automountServiceAccountToken: false)
Sicurezza dell'immagine
- Scansiona tutte le immagini per individuare eventuali vulnerabilità prima della distribuzione (Trivy, Snyk)
- Utilizza immagini di base minime (distroless, Alpine) per ridurre la superficie di attacco
- Firmare le immagini del contenitore e verificare le firme all'ammissione (cosign, notazione)
- Consenti solo immagini provenienti da registri attendibili (applicazione tramite controllo di ammissione)
- Non utilizzare mai il tag :latest: aggiungilo a digest di immagini specifici per riproducibilità
- Ricostruisci e aggiorna regolarmente le immagini di base per incorporare patch di sicurezza
Gestione dei segreti
- Non archiviare i segreti nelle variabili di ambiente o nelle ConfigMap
- Utilizza la gestione dei segreti esterna (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault)
- Se si utilizzano Kubernetes Secrets, abilitare la crittografia dei dati inattivi (EncryptionConfiguration)
- Ruota regolarmente i segreti con rotazione automatizzata tramite operatori segreti esterni
- Limita l'accesso RBAC ai segreti: la maggior parte dei pod non dovrebbe essere in grado di elencare tutti i segreti
Monitoraggio e rilevamento
- Abilita la registrazione di controllo Kubernetes e inoltra a SIEM
- Distribuire il monitoraggio della sicurezza in fase di esecuzione (Falco, Sysdig)
- Monitoraggio di: esecuzione imprevista di processi, connessioni di rete, modifiche di file, escalation di privilegi
- Avviso relativo a: nuova creazione di ClusterRoleBinding, accesso segreto da parte di pod imprevisti, comandi exec del contenitore
- Implementa le violazioni dei criteri di sicurezza dei pod come avvisi SIEM
CIS Kubernetes Benchmark
Il Center for Internet Security (CIS) pubblica benchmark di sicurezza dettagliati per Kubernetes. Utilizza kube-bench per valutare automaticamente il tuo cluster rispetto ai benchmark CIS. Affrontare tutti i risultati critici ed elevati prima della distribuzione in produzione. I servizi gestiti Kubernetes (EKS, AKS, GKE) gestiscono automaticamente alcuni elementi di benchmark, ma gli elementi responsabili del cliente richiedono comunque la configurazione.
Come Opsio protegge Kubernetes
- Valutazione della sicurezza del cluster:Valutiamo i tuoi cluster Kubernetes rispetto ai benchmark CIS e alle best practice dei provider cloud.
- Implementazione dell'hardening:Implementiamo tutti gli elementi dell'elenco di controllo, inclusi RBAC, policy di rete, sicurezza dei pod e monitoraggio.
- Monitoraggio del tempo di esecuzione:Il nostro SOC monitora i cluster Kubernetes per eventi di sicurezza e comportamenti anomali.
- Applicazione delle politiche:Utilizziamo OPA/Gatekeeper o Kyverno per applicare automaticamente le politiche di sicurezza.
- Gestione continua:Revisioni periodiche della sicurezza, rivalutazione dei benchmark CIS e aggiornamenti della configurazione della sicurezza.
Domande frequenti
Qual è il controllo di sicurezza Kubernetes più importante?
Politiche di rete con rifiuto predefinito. Senza policy di rete, ogni pod può comunicare con ogni altro pod: un pod dell'applicazione web compromesso può accedere direttamente al pod del database, allo stack di monitoraggio e al server Kubernetes API. Le policy di rete di rifiuto predefinito riducono immediatamente il raggio d'azione di qualsiasi compromissione del contenitore.
Dovrei utilizzare una rete di servizi per la sicurezza?
Service mesh (Istio, Linkerd) aggiunge mTLS tra i servizi, fornendo crittografia e autenticazione per tutte le comunicazioni tra pod. Se gestisci dati sensibili o devi soddisfare i requisiti di conformità per la crittografia in transito, il service mesh è prezioso. Per ambienti più semplici, le sole policy di rete potrebbero essere sufficienti.
Come posso gestire i segreti in Kubernetes in modo sicuro?
Usare un gestore di segreti esterno (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) con un operatore di segreti Kubernetes (Operatore di segreti esterni, Operatore di segreti di Vault). Ciò mantiene i segreti fuori da Git, fornisce la registrazione di controllo, consente la rotazione e centralizza la gestione dei segreti sui carichi di lavoro Kubernetes e nonKubernetes.