È sicuro affidarsi a un contenitore Docker?

Al momento non c'è modo di capire facilmente se fidarsi di specifici contenitori di finestre mobili. Esistono contenitori di base forniti da Docker e provider di sistemi operativi che chiamano "trusted" ma il software non ha ancora meccanismi validi (ad esempio la firma digitale) per verificare che le immagini non siano state manomesse.

Per chiarimenti, cita la standard di sicurezza CIS per la finestra mobile di recente rilasciata di recente sezione 4.2

Official repositories are Docker images curated and optimized by the Docker community or the vendor. But,the Docker container image signing and verification feature is not yet ready.

Hence, the Docker engine does not verify the provenance of the container images by itself.

You should thus exercise a great deal of caution when obtaining container images.

Quando entri nel mondo di contenitori di terze parti generici dall'hub Docker, l'immagine è ancora più complicata. La finestra mobile AFAIK esegue la verifica nessuna dei file contenitore di altre persone, quindi c'è un numero di potenziali problemi

• Il contenitore contiene malware reale. È probabile, nessuno lo sa. È possibile, sì.
• Il contenitore contiene software non sicuro. I Dockerfiles sono fondamentalmente come script batch che costruiscono una macchina. Ho visto diversi che fanno cose come scaricare i file su connessioni HTTP non criptate e poi eseguirli come root nel container. Per me non è un buon modo per ottenere un contenitore sicuro
• Il contenitore imposta impostazioni non protette. Docker si occupa di automatizzare l'impostazione del software, il che significa che sei, in una certa misura, fidato di tutte le persone che hanno fatto i dockerfiles a configurarli in modo sicuro come avresti desiderato.

Ovviamente puoi controllare tutti i dockerfile, ma poi, una volta fatto, sarebbe stato meglio semplicemente configurare la cosa da solo!

Sul fatto che questo valga "il rischio", temo che sia una decisione che solo tu puoi davvero fare. Stai scambiando il tempo necessario per sviluppare e mantenere le tue immagini, contro i maggiori rischi che qualcuno coinvolto nella produzione del software che scarichi sia dannoso o abbia commesso un errore in merito alla sicurezza del sistema.

Fidati di qualsiasi codice non firmato eseguito sui tuoi sistemi. I contenitori sono solo processi con alcune protezioni extra dello spazio dei nomi su di essi, quindi sono tutte le protezioni che ottengono. Parlano ancora con lo stesso kernel sotto.

È meglio considerare un contenitore Docker come uguale all'applicazione in esecuzione sul sistema host. Ci sono alcuni tentativi di bloccare il demone Docker rimuovendo le funzionalità del Kernel di Linux, ma questa non è davvero una garanzia. Se esegui Docker, ci sono alcune cose che puoi fare per mitigare parte di questo rischio.

• SELinux - l'abilitazione di questo genererà automaticamente un'etichetta MCS per ogni contenitore, limitando la sua capacità di fare danni.
• Sola lettura : puoi anche contrassegnare il contenitore in sola lettura, che può consentire di eseguire grandi letture dell'immagine del contenitore in sola lettura, il che può rendere più difficile per un utente malintenzionato implementare malware.
• Registro di auto-hosting - per ridurre il rischio di manomissioni delle immagini, caricamento di contenitori dannosi, perdita di segreti o altrimenti messa a rischio, è possibile ospitare un registro internamente. Il link è un esempio di uno che si trova in cima a S3, sebbene ci siano anche altre opzioni.

In sostanza, sostengo che è la stessa domanda se il software open source è affidabile. Tuttavia, ritengo che il rischio di utilizzare container Docker della community sia alquanto più elevato attualmente rispetto ai rischi legati all'uso di software open source.

Innanzitutto, come hai detto, ora non ci sono firme e verifiche. I buoni sistemi di packaging open source oggi includono questo , almeno quando si ottiene il software dai repository ufficiali. E anche i progetti one-off tendono ad includere i checksum nei pacchetti di download. Quindi nel mondo open source, non sai che il codice è sicuro, ma spesso sai che stai ricevendo il codice che dovresti ottenere. Con Docker, non sai nemmeno che il contenitore è inalterato tra la pubblicazione e il tuo download.

Il secondo è il problema del pacchetto stesso. Sei sicuro che il software non stia facendo qualcosa di brutto, come riportare le tue attività su qualche destinazione Internet? Questo era un comune timore del software open source . Al giorno d'oggi, molte grandi imprese non mettono in dubbio gli implementatori tecnici che incorporano software open source. Probabilmente, il software di closed source potrebbe essere peggio in questo modo. Ma per un contenitore Docker, specialmente uno che include un set completo di strumenti e librerie del sistema operativo, la "superficie di attacco" è molto più grande. Se pensi che potresti usare una brutta build di postfix, prendi il codice ufficiale e costruiscilo (e alcuni gestori di pacchetti lo fanno normalmente). Se pensi di avere un contenitore Docker scadente, spesso è un po 'un'avventura riprodurre l'immagine "dalla fonte".

Ti puoi fidare dei contenitori della finestra mobile SECURITY? Penso che la risposta a questo deve essere quasi sempre NO!

Nel mio caso, mi sto chiedendo di 'linuxserver / openvpn-as'. Accidenti, non sarebbe bello semplicemente inserire quella cosa in uno dei miei sciami docker, aprirlo alle mie reti private e lasciargli gestire l'accesso degli utenti remoti a quelle reti. Ma come posso fidarmi di qualcosa del genere per qualsiasi contenitore che esco dal web che non ha alcuna provenienza? Senza quello, non penso di poterlo fare.

Se avessi una provenienza, allora mi dovrei fidare del creatore per avere

1. iniziato con qualcosa di altrettanto affidabile (e così via e così via),
2. non ha fatto qualcosa di malevolo e
3. non ha reso una scelta non sicura per un passaggio di installazione o configurazione.

Questo è un ordine piuttosto alto in sé e per sé. In questo caso, devo fidarmi di linuxserver.io. Mai sentito parlare di loro. Ma guardandoli, sembra che tutto il loro lavoro sia creare contenitori. Quindi probabilmente sono davvero bravi in questo. E questo contenitore è stato presumibilmente scaricato da DockerHub oltre 500K volte. Sembra qualcosa di abbastanza sicuro.

Quindi potrei probabilmente sentirmi abbastanza bene se potessi essere sicuro che l'immagine che sto ottenendo

1. è stato creato da linuxserver.io e
2. è infatti l'immagine che è stata veramente scaricata 500K volte.

Bene, prima di tutto, (2) non è vero, giusto? Credo che contando tutte le versioni del container. Quindi forse il contenitore è stato al sicuro per anni, ma qualcuno ha rilasciato una versione con un serio buco di sicurezza. E poi c'è (1). Questo è il vero puzzone. Di quanti altri meccanismi devo fidarmi (DockerHub, l'hoster di DockerHub, l'infrastruttura di Internet, ...) per essere sicuro che il codice sorgente originale per il contenitore che linuxserver.io considera l'origine per il contenitore definisca veramente contenitore che sto effettivamente usando. Non c'è modo che io possa saperlo. E, davvero, dovrei sapere che non solo su questo contenitore, ma su tutti i sotto-contenitori usati per crearlo. Quindi non posso assolutamente usare questo contenitore.

Questo è un caso estremo, ma probabilmente non lo è per qualsiasi contenitore che coinvolga la sicurezza della rete. Mi aspetto che molti di quei 500.000 consumatori che hanno effettivamente utilizzato questa immagine abbiano fatto un comportamento spericolato, senza colpa di linuxserver.io.

La finestra mobile richiede un meccanismo di provenienza completo del contenitore. Anche allora, c'è un'enorme quantità di fiducia da radunare qui. Forse troppo grande. Forse il software di sicurezza non è semplicemente containerizzabile.

Puoi creare fiducia nell'origine con un'indagine rapida, ma una preoccupazione più importante è l'immaturità relativa del profilo di sicurezza generale, come suggerito dalla necessità di utilizzare l'accesso root per eseguire il tuo contenitore.

Dato che suggerisci di concentrarci su soluzioni popolari, consideriamo che stiamo utilizzando un repository Git controllato come Docker Hub per abbattere un famoso prodotto fornito dal fornitore. I meccanismi Git forniscono un buon livello di fiducia. Se ti fidi del provider indicato, puoi fidarti del loro prodotto Docker. Se ricordi che alcuni anni fa GitHub era stato compromesso, ma il codice sorgente era valido a causa del meccanismo di firma di integrità di Git e dei controlli di pubblicazione. Queste funzionalità proteggono anche i file pubblicati da Docker se si utilizzano prodotti di vendor popolari.

Il Dockerfile che costruisce il tuo contenitore può raggiungere e scaricare file tar ecc. che non sono ospitati su repository Git attendibili. Un semplice controllo di quel file di testo, il Dockerfile, può creare fiducia in quello spazio.

I meccanismi di sicurezza complessivi sono molto giovani quindi si prega di considerare le loro vulnerabilità oltre a problemi di controllo del codice sorgente. Dalla loro documentazione sulla sicurezza:

Ci sono tre aree principali da considerare quando si esamina la sicurezza di Docker:

• la sicurezza intrinseca del kernel e il suo supporto per namespace e cgroup
• la superficie di attacco del daemon Docker stesso
• scappatoie nel profilo di configurazione del contenitore, per impostazione predefinita, o quando personalizzate dagli utenti
• le caratteristiche di sicurezza "hardening" del kernel e il modo in cui interagiscono con i contenitori

Penso che il fatto che la loro prima pagina sulla sicurezza dica che ci sono tre aree principali e che l'elenco quattro è ancora un'ulteriore indicazione che le cose sono in flusso in quello spazio. Sembra essere una soluzione fantastica, ma potrebbe essere necessario un rafforzamento intelligente con perimetri e criteri forniti dall'utente a breve termine.

Con Docker in particolare, secondo la mia esperienza, puoi fidarti della stragrande maggioranza delle cose là fuori nella comunità open source (come roba su Github) per non essere deliberatamente dannoso. Puoi leggere il Dockerfile e verificare che stia recuperando il codice dai repository ufficiali, se ce n'è uno (rispetto all'utilizzo del fork di una persona a caso). Se si tratta di codice estraneo, ovviamente si può sempre dare un'occhiata a ciò che è diverso dal repository ufficiale in quella forcella specifica. È qui che si accede a software dannoso che non è intenzionalmente dannoso. È solo un crap code o una configurazione orribile o equivalente. Nella mia esperienza con Docker, il codice che usa le forche non ufficiali dovrebbe essere evitato, a meno che la forcella non fornisca una caratteristica specifica che si sta cercando. Il repository ufficiale verrà aggiornato più spesso della forcella, quasi ovunque. Inoltre, Docker utilizza ciò che viene chiamato "build affidabili" in modo che tu sappia che stai ricevendo quello che dice che stai ricevendo sul barattolo. Infine, Docker stesso ha avuto vulnerabilità. Sembra che tu abbia la mentalità giusta per sentirti bene se qualcosa sembra sbagliato.

In poche parole, in genere se le risorse Docker tirano FROM in una build ufficiale e dai repository ufficiali, questo è sicuro quanto è possibile ottenere usando il software. Lo stesso Docker ha avuto la sua parte di vulnerabilità, ma finché rimani aggiornato sulle patch della tua infrastruttura, andrà tutto bene.

Assumi la posizione predefinita di non fidarsi di qualsiasi cosa tu voglia portare nel tuo ambiente dall'esterno.

Se è qualcosa che vuoi veramente usare, minimizza il più possibile il rischio sequestrandolo, analizzandolo e assicurandoti che non faccia del male.

Dagli meno accesso possibile al tuo ambiente per consentirgli di fare ciò che ti serve.

Controlla su di esso. Aggiornalo e assicurati che gli aggiornamenti non introducano nuovi rischi.