Contenitori e sicurezza

Considerazioni Generali

Vi possono essere notevoli problemi di sicurezza nell'uso di default di contenitori:

  • I permessi di default di docker sono quelli di root
  • Usare Docker vuol dire caricare immagini non garantite dalla rete e lanciarle coi permessi di root

“Will you walk into my parlour?” - said the spider to the fly.

Prima Regola: Non scaricare immagini non fidate

  • l'immagine ufficiale di un prodotto su Docker Hub si può considerare fidata
  • altre immagini di altri produttori, anche su Docker Hub, non sono da considerarsi fidate

Docker Hub da la possibilità di compiere l'upload di immagini pubbliche. Non ne compie un'analisi di sicurezza.

Le uniche immagini veramente fidate sono quelle che abbiamo costruito noi, manualmente o tramite Dockerfile.

Seconda Regola: Progettare i programmi dentro i container con le stesse avvedutezze dei programmi dello host

  • I server devono diminuire i privilegi
  • Meglio sottoporre i contenitori a pentesting
  • Controllare i log dello host

Terza Regola: Attenzione allo host mapping

Esempio pericoloso. Considerare il comando:

docker run --rm -v /:/homeroot -it alpine sh

Il processo sh del contenitore ha i diritti di root nel contenitore, ma anche sul sistema host se riesce ad uscirne. Il mappaggio -v /:/homeroot fa sì che modifiche alla cartella /homeroot del contenitore corrispondano a modifiche di / del sistema host.

Sicurezza del Server

Un server con docker dovrebbe avere solo docker come servizio attivo.

  • Spostare gli altri servizi ad altri server
  • Se non è possibile, spostare tutti gli altri servizi in containers
  • Si può lasciare sshd ma solo con autenticazione a chiave condivisa, non password

Il server docker espone una REST API al client docker su una socket unix.

E' possibile attivarlo su una socket inet ma è estremamente pericoloso perchè espone il servizio ad attacchi Cross Site Request Forgery (XSRF).

  • Limitare l'accesso al client docker - gli utenti che appartengono al gruppo docker sono fidati e responsabili, possibilmente già con mansioni amministrative sullo host
  • Lanciare i comandi docker dallo host locale - prima usare ssh per accedere al server docker, poi dare comandi che eseguono in locale

Contenitori in Macchine Virtuali

Questo aggiunge uno strato di sicurezza, ma va in controtendenza alla filosofia dei contenitori.

Un contenitore che conduca un attacco di diniego di servizio può riuscire al massimo a consumare tutte le risorse della VM, non del sistema host, di altri contenitori sul sistema host o di altri contenitori in altre VM.

E' una soluzione da adottarsi solo in caso di sospetto su un contenitore particolare, non di prammatica.

Idealmente:

  • le immagini di base sono derivate da repositories ufficiali di fiducia
  • le immagini dipendenti, che richiedono quelle base, hanno un Dockerfile di specifica
  • tutte le immagini derivate sono conservate su un repository locale

Docker Content Trust

Servizio offerto da Docker.io. Pull solo di immagini firmate dal fornitore.

Va abilitato:

export DOCKER_CONTENT_TRUST=1

Download del certificato di firma dal repository. Questo va accettato separatamente, come con SSH.

Ha un costo di licenza.

Permette anche l'upload di immagini firmate. Generata coppia di chiavi ed un certificato. Chiave privata in: ~/.docker/trust/private

Per scaricare un'immagine non firmata, quando il trust è abilitato, usare il comando:

docker pull --disable-content-trust immagine

Il Docker Content Trust non protegge da attacchi Man-In-The-Middle (MITM) o di Ingegneria Sociale.

Per configurare un repository locale con Docker Content Trust occorre installare un Notary Server. Anche questo è offerto come servizio aggiuntivo a licenza dalla Docker.io.