Sicurezza di container e Kubernetes

I container condividono il kernel dell'host, quindi sono meno isolati rispetto alle VM. La sicurezza dei container comprende: igiene delle immagini (nessun pacchetto vulnerabile), protezione del runtime (rilevamento dei comportamenti anomali), policy di rete (limitazione della comunicazione tra pod) e configurazione RBAC.

Trivy analizza le immagini dei container alla ricerca di CVE dei pacchetti del sistema operativo, vulnerabilità delle dipendenze applicative, misconfigurazioni e segreti. Lo integri nella CI/CD per bloccare le immagini con vulnerabilità critiche prima che arrivino in produzione.

Utilizzi immagini di base minimali (alpine, distroless). Esegua il container con un utente non root (USER 1000). Eviti COPY . . — sia specifico. Le build multi-stage riducono le dimensioni dell'immagine finale. Esegua la scansione prima del push. Non codifichi mai segreti o credenziali nei layer.

RBAC di Kubernetes controlla l'accesso al server API. ClusterRoles e Roles definiscono le autorizzazioni sulle risorse (pod, secret, deployment). ClusterRoleBindings e RoleBindings le assegnano a utenti, gruppi o ServiceAccounts. Eviti cluster-admin, tranne che per l'automazione.

PSS definisce tre profili: Privileged (senza restrizioni), Baseline (restrizioni minime) e Restricted (rafforzato). Li applichi tramite le label dei namespace del controller di ammissione PodSecurity. Il profilo Restricted impedisce l'esecuzione come root, vieta l'escalation dei privilegi e richiede filesystem in sola lettura.

Per impostazione predefinita, tutti i pod possono comunicare con tutti gli altri pod. Le NetworkPolicies di Kubernetes definiscono regole in ingresso e in uscita per ogni selettore di pod. Implementi policy di default-deny e consenta esplicitamente solo i percorsi di comunicazione necessari, per limitare il raggio d'azione di un attacco.

I Secret di Kubernetes sono codificati in base64, non crittografati, per impostazione predefinita. Abiliti la crittografia dei dati a riposo per etcd. Utilizzi External Secrets Operator o Vault Agent Injector per recuperare i secret da HashiCorp Vault o dai secret manager cloud invece dei Secret di Kubernetes.

I controller di ammissione intercettano le richieste API prima della creazione degli oggetti. OPA/Gatekeeper applica policy personalizzate (ad esempio, richiedere label specifiche o bloccare i container privilegiati). Kyverno offre policy-as-code con una sintassi YAML più semplice per i vincoli di sicurezza comuni di K8s.

Falco rileva i comportamenti anomali durante l'esecuzione utilizzando eBPF: shell avviate nei container, connessioni in uscita inattese, file scritti in /etc, tentativi di escalation dei privilegi ed esecuzione di strumenti di attacco noti. Le regole di avviso sono personalizzabili in YAML.

Abiliti il logging di audit del server API per registrare ogni richiesta con utente, azione, risorsa e timestamp. Inoltri i log a un SIEM per rilevare attività API insolite: elenco dei token dei ServiceAccount, enumerazione dei secret, escalation dei ruoli ed esecuzione di kubectl exec nei pod di produzione.

Firmi le immagini dei container con Cosign (Sigstore) per garantire l'integrità della supply chain. I controller di policy (Connaisseur, Kyverno) possono imporre l'ammissione nel cluster delle sole immagini firmate provenienti da registry attendibili, bloccando il pull di immagini non attendibili.

Che cosa ottiene una NetworkPolicy di Kubernetes con un podSelector vuoto e policyTypes Ingress/Egress?

La sicurezza dei container e di Kubernetes richiede la protezione della supply chain delle immagini, l'applicazione di RBAC e dei Pod Security Standards, l'implementazione delle policy di rete, una gestione corretta dei secret e l'utilizzo del rilevamento durante l'esecuzione per individuare gli attacchi che aggirano i controlli preventivi.