Sicurezza in Docker: Consigli e Strategie

In precedenti guide ho già accennato ad alcune pratiche di sicurezza. Oggi approfondiremo i possibili rischi nell’uso di Docker e vedremo come mitigarli, comprendendo anche i principali vettori di attacco:

• Esposizione non sicura: spesso le interfacce web delle applicazioni vengono esposte senza adeguate misure di sicurezza.​
• Immagini malevole: l’esecuzione di immagini da fonti non verificate può introdurre malware o codice non mantenuto.​
• Dipendenze compromesse: gli attacchi alla supply chain possono colpire applicazioni tramite dipendenze contenenti codice malevolo.​
• Movimenti laterali: un dispositivo compromesso nella rete può consentire a un attaccante di accedere al server attraverso le applicazioni.​
• Vulnerabilità e bug: le applicazioni possono presentare vulnerabilità sfruttabili con vari impatti potenziali.​ Qui ho consigliato un applicazione per effettuare scansioni di vulnerabilità sulle immagini.

Misure di Sicurezza Consigliate

1. Verifica delle Fonti delle Immagini: utilizzare solo immagini da fonti affidabili, verificando il codice sorgente e valutando la popolarità e la frequenza degli aggiornamenti.​
2. Aggiornamenti Regolari: mantenere aggiornati l’host, il motore Docker e i container per proteggersi da vulnerabilità note. Evitare aggiornamenti automatici per prevenire l’introduzione di compromessi non rilevati.​
3. Proxy per Docker Socket: evitare di montare direttamente il socket Docker (/var/run/docker.sock) nei container. Utilizzare invece un docker socket proxy con i privilegi minimi necessari per ridurre i rischi di compromissione dell’host.​
4. Nessun Nuovo Privilegio: impedire l’escalation dei privilegi all’interno dei container utilizzando l’opzione no-new-privileges. Questo potrebbe influire sul funzionamento di alcune immagini che richiedono privilegi elevati.​

• Proxy per il Docker Socket Non montare direttamente il socket Docker (/var/run/docker.sock) nei container. Anche in modalità sola lettura :ro spesso inserito nella parte finale di questa definizione, il socket rimane completamente accessibile e non limita il suo utilizzo e spesso in molte configurazioni che mi è capitato di vedere/leggere e consigliate come configurazione viene fatto.

L’accesso al socket Docker permette a un attaccante di uscire facilmente dal container e compromettere l’host.

È preferibile utilizzare un docker socket proxy con i minimi privilegi necessari. In questo modo, l’accesso al socket è limitato a un solo container verificabile, invece di concederlo indiscriminatamente a tutte le immagini che lo richiedono.

• Evitare Privilegi Pericolosi: non concedere privilegi elevati come privileged o capacità come SYS_ADMIN ai container, poiché possono facilitare la fuga dal container e la compromissione dell’host.​

• Esecuzione come Utente Non Root: eseguire i container con un utente non root utilizzando variabili PUID e PGID o l’opzione user per limitare le capacità di un eventuale attaccante all’interno del container.​

  somecontainer:
    environment:
      - PUID=1000
      - PGID=1000
  othercontainer:
    user: "1000:1000"

• Limitazione delle Risorse: impostare limiti alle risorse dei container per prevenire che comportamenti anomali influenzino negativamente l’host. Utilizzare un’ancora come base per tutti i container e sovrascrivere valori specifici se necessario.​

x-base: &base
  mem_limit: 2000m 
  pids_limit: 200
  cpus: "3.5" 
  logging:
    options:
      max-size: "10m"
      max-file: "3"
  security_opt:
    - no-new-privileges=true
services:
  somecontainer:
    <<: *base
    environment:
      - PUID=1000
      - PGID=1000

• Backup Regolari: effettuare backup regolari dei file di configurazione e dei volumi montati sull’host per garantire la possibilità di ripristino in caso di compromissione. Prestare attenzione alle applicazioni che richiedono strumenti di backup specifici, come PostgreSQL o MariaDB.