Sicurezza dei container a runtime

Benvenuto nella sicurezza dei container a runtime! Creare immagini sicure è fondamentale, ma cosa succede quando il container è in esecuzione?

Questa lezione si concentra sulle best practice per proteggere le applicazioni mentre sono attive, limitando i potenziali danni causati da vulnerabilità o attacchi.

Un concetto fondamentale della sicurezza è il principio del privilegio minimo. Consiste nel concedere a un'entità (come un container o un utente) solo i permessi assolutamente necessari per svolgere la propria funzione, e nessun altro.

La sua applicazione riduce la superficie di attacco e limita l'impatto nel caso in cui un container venga compromesso.

Per impostazione predefinita, i processi all'interno di un container Docker vengono eseguiti come utente root, che dispone di tutti i privilegi amministrativi all'interno del container.

• Rischio: Se un attaccante prende il controllo di un container con privilegi root, potrebbe sfruttare le vulnerabilità del demone Docker o del kernel per ottenere l'accesso root al sistema host.
• Best practice: Eseguire sempre i processi del container come utente non root.

È possibile specificare un utente (tramite nome o UID) per il processo del container usando il flag --user con docker run. In questo esempio, eseguiamo il comando id in un container Alpine come utente 1000.

Se l'utente 1000 non esiste, Docker utilizzerà comunque tale UID.

I sistemi Linux tradizionali hanno un utente root con privilegi assoluti. Le Linux Capabilities suddividono i potenti privilegi di root in unità più piccole e distinte.

In questo modo, un processo può disporre solo dei poteri specifici simili a quelli di root di cui ha bisogno (ad esempio, l'associazione a porte basse o l'accesso diretto alla rete), senza avere tutti i privilegi di root.

Per impostazione predefinita, i container Docker vengono eseguiti con un insieme ampio di capabilities. È possibile rimuovere quelle non necessarie usando --cap-drop, per limitare ulteriormente le operazioni che un container può eseguire.

In questo esempio, rimuoviamo la capability NET_RAW. Il comando ping, che richiede NET_RAW, non riuscirà quindi a essere eseguito, dimostrando la limitazione.

I container condividono il kernel e le risorse dell'host. L'uso incontrollato delle risorse da parte di un container può causare una negazione del servizio (DoS) per altri container o persino per l'host stesso.

• Limiti della CPU: Impediscono a un container di monopolizzare i cicli della CPU.
• Limiti di memoria: Impediscono a un container di consumare tutta la RAM disponibile, evitando l'instabilità del sistema.

È possibile impostare direttamente i limiti di CPU e memoria con docker run. Questo esempio limita la memoria a 128 MB e l'utilizzo della CPU a 0.5 (metà di un core della CPU).

In questo modo si garantisce che il container si comporti correttamente senza privare di risorse gli altri processi.

Molte applicazioni non devono scrivere nel proprio filesystem root dopo l'avvio. Rendendo il filesystem di sola lettura, si ottengono importanti vantaggi in termini di sicurezza:

• Impedisce le manomissioni: Un attaccante non può modificare i file esistenti né scrivere nuovi file dannosi.
• Limita la persistenza: Qualsiasi modifica effettuata è temporanea e viene persa al riavvio del container.
• Impone l'immutabilità: Favorisce una progettazione in cui i container sono temporanei e la configurazione è esterna.

Usi il flag --read-only quando esegue un container. Qualsiasi tentativo di scrivere nel filesystem del container (al di fuori dei volumi montati esplicitamente) non andrà a buon fine.

Provi a creare un file in questo container di sola lettura:

Quali tra le seguenti sono buone pratiche per proteggere i container a runtime?

Ottimo lavoro! Ha appreso come migliorare la sicurezza dei container mentre sono in esecuzione:

• Privilegio minimo: Concedere solo i permessi necessari.
• Utenti non root: Evitare di eseguire i processi come root.
• Capabilities: Rimuovere le Linux Capabilities non necessarie.
• Limiti delle risorse: Controllare l'utilizzo di CPU e memoria.
• Sola lettura: Rendere i filesystem immutabili per impedire le scritture.

Queste pratiche riducono significativamente la superficie di attacco e l'impatto di eventuali compromissioni. Continui a esercitarsi!