Best practice per la sicurezza dei container per gli ambienti di produzione
Group COO & CISO
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
I tuoi contenitori sono sufficientemente sicuri per la produzione?I contenitori forniscono un eccellente isolamento tra le applicazioni, ma configurazioni errate, immagini vulnerabili e impostazioni di runtime non sicure possono trasformare i contenitori da un vantaggio per la sicurezza in una responsabilità. Questa guida copre le pratiche di sicurezza richieste dagli ambienti dei contenitori di produzione.
Punti chiave
- Inizia con immagini minime:Le immagini Distroless e Alpine riducono la superficie di attacco del 90% rispetto alle immagini del sistema operativo completo.
- Scansione in ogni fase:Crea, invia, distribuisci e in modo continuo nel registro. Le vulnerabilità vengono scoperte dopo la distribuzione.
- Non eseguire mai come root:I contenitori root possono sfuggire all'host. I contenitori non root vengono contenuti anche se compromessi.
- Filesystem di sola lettura:Se non è necessario scrivere sul contenitore, rendere il filesystem di sola lettura per impedire la persistenza del malware.
- Il monitoraggio in fase di esecuzione rileva ciò che manca alla scansione:Gli exploit zero-day, gli attacchi alla supply chain e le minacce interne richiedono il rilevamento in fase di esecuzione.
Sicurezza dell'immagine
Utilizza immagini di base minime
Ogni pacchetto in un'immagine del contenitore è una potenziale superficie di attacco. Una tipica immagine Ubuntu contiene oltre 100 pacchetti; un'immagine senza distribuzione contiene solo il runtime dell'applicazione. Utilizza Google Distroless per le applicazioni Java, Python, Node.js e Go. Usa Alpine (5 MB) quando hai bisogno di una shell per il debug. Non utilizzare mai immagini complete del sistema operativo (Ubuntu, Debian, CentOS) in produzione: contengono centinaia di pacchetti non necessari con vulnerabilità note.
Costruzioni in più fasi
Utilizza Dockerfile a più fasi per separare le dipendenze di build dalle immagini di runtime. La fase di compilazione include compilatori, gestori di pacchetti e strumenti di sviluppo. La fase finale contiene solo l'applicazione compilata e dipendenze runtime minime. Ciò impedisce agli strumenti di compilazione (che spesso hanno CVE di gravità elevata) di apparire nelle immagini di produzione.
Pipeline di scansione delle immagini
- Tempo di costruzione:Esegui la scansione nella pipeline CI prima di eseguire l'invio al registro. Blocca build con vulnerabilità critiche.
- Registro:La scansione continua in ECR, ACR o Harbour rileva i CVE appena scoperti nelle immagini esistenti.
- Ingresso:I controllori di ammissione Kubernetes verificano i risultati della scansione delle immagini prima di consentire la distribuzione.
- Durata:Monitorare il comportamento anomalo del contenitore che potrebbe indicare lo sfruttamento di vulnerabilità senza patch.
Sicurezza durante l'esecuzione
Indurimento dei contenitori
| Impostazione | Valore consigliato | Perché |
|---|---|---|
| runAsNonRoot | vero | Impedisce l'escape del contenitore attraverso i privilegi di root |
| readOnlyRootFilesystem | vero | Impedisce al malware di scrivere nel file system |
| consentirePrivilegeEscalation | falso | Impedisce ai processi di ottenere privilegi aggiuntivi |
| capacità | rilasciare: ["TUTTI"] | Rimuove tutte le funzionalità Linux, aggiungi solo ciò che è necessario |
| seccompProfilo | RuntimeDefault | Limita le chiamate di sistema disponibili al contenitore |
| risorse.limiti | Imposta CPU e memoria | Previene l'abuso di risorse (crypto-mining, DoS) |
Monitoraggio runtime con Falco
Falco monitora il comportamento dei container rispetto alle regole di sicurezza e avvisa in caso di violazioni. Le regole predefinite rilevano: shell generata all'interno di un contenitore, accesso a file sensibili (/etc/shadow, /etc/passwd), connessioni di rete impreviste, tentativi di escalation dei privilegi, esecuzione del gestore pacchetti in contenitori di produzione e processi di cripto-mining. È possibile aggiungere regole personalizzate per il comportamento specifico dell'applicazione.
Avete bisogno di supporto esperto per best practice per la sicurezza dei container per gli ambienti di produzione?
I nostri architetti cloud vi supportano con best practice per la sicurezza dei container per gli ambienti di produzione — dalla strategia all'implementazione. Prenotate una consulenza gratuita di 30 minuti senza impegno.
Sicurezza della catena di fornitura
Firma e verifica delle immagini
Firma le immagini del contenitore in fase di compilazione utilizzando cosign (Sigstore) o Docker Content Trust. Verifica le firme durante la distribuzione tramite i controller di ammissione Kubernetes. Ciò garantisce che possano essere distribuite solo le immagini create dalla pipeline CI/CD, prevenendo attacchi alla catena di fornitura in cui gli aggressori inseriscono immagini dannose nel tuo registro.
Distinta base software (SBOM)
Genera SBOM per ogni immagine del contenitore utilizzando Syft o Trivy. Una SBOM elenca tutti i componenti (pacchetti del sistema operativo, librerie, dipendenze) nell'immagine. Quando viene rivelata una nuova vulnerabilità, puoi identificare immediatamente quali immagini sono interessate senza dover ripetere la scansione del tutto. Le SBOM sono sempre più richieste dalle normative e dai clienti aziendali.
Come Opsio protegge i container
- Pipeline di immagini:Implementiamo la scansione, la firma e l'applicazione delle policy nell'intero ciclo di vita dell'immagine del contenitore.
- Sicurezza di esecuzione:Distribuiamo e gestiamo Falco/Sysdig per il monitoraggio continuo del runtime dei container.
- Kubernetes indurimento:Rafforziamo le configurazioni dei cluster in base ai benchmark CIS con un monitoraggio costante della conformità.
- Risposta all'incidente:Il nostro team SOC risponde agli incidenti legati alla sicurezza dei container con capacità di contenimento e forensi.
Domande frequenti
I container sono più sicuri delle VM?
I contenitori forniscono isolamento a livello di processo tramite spazi dei nomi Linux e cgroup, mentre le macchine virtuali forniscono isolamento a livello hardware tramite hypervisor. Le VM hanno confini di isolamento più forti. I contenitori offrono una distribuzione più rapida e una superficie di attacco più piccola (quando si utilizzano immagini minime). In pratica, i contenitori adeguatamente configurati con monitoraggio della sicurezza di runtime sono sufficientemente sicuri per la maggior parte dei carichi di lavoro di produzione. I carichi di lavoro altamente sensibili possono trarre vantaggio dall'isolamento di livello VM o dal sandboxing dei contenitori (gVisor, Kata Containers).
Qual è il rischio più grande per la sicurezza dei container?
Esecuzione di contenitori come root con funzionalità illimitate. Un contenitore root con tutte le funzionalità può sfuggire al sistema host, accedendo ad altri contenitori, risorse host e potenzialmente al server Kubernetes API. La soluzione è semplice: imposta runAsNonRoot: true, elimina tutte le funzionalità e utilizza file system di sola lettura. Queste tre impostazioni eliminano la maggior parte dei rischi per la sicurezza dei container.
Come gestisco i segreti nei contenitori?
Non inserire mai segreti nelle immagini del contenitore né trasmetterli come variabili di ambiente (visibili negli elenchi e nei log dei processi). Utilizza la gestione dei segreti esterna: HashiCorp Vault con iniezione sidecar, AWS Secrets Manager con integrazione ECS/EKS o Azure Key Vault con driver CSI. I segreti dovrebbero essere inseriti in fase di esecuzione e archiviati solo in memoria, mai su disco.
About the Author
Group COO & CISO at Opsio
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
Editorial standards: This article was written by a certified practitioner and peer-reviewed by our engineering team. We update content quarterly to ensure technical accuracy. Opsio maintains editorial independence — we recommend solutions based on technical merit, not commercial relationships.