Lavoro nell'IT da oltre 20 anni, ma finora non mi sono mai occupato di container. In teoria capivo come erano strutturati e come funzionavano. Ma poiché non li avevo mai incontrati nella pratica, non ero sicuro di come girassero e funzionassero le ingranaggi sotto il cofano.
Inoltre, non avevo idea di come fosse la loro sicurezza. Ma anche in questo caso, la teoria suona bene, e la vecchia canzone "con l'aumento della sicurezza diminuisce la facilità d'uso" mi è rimasta impressa. Così ho pensato che siccome era così facile lavorare con i container, la sicurezza fosse a livelli molto bassi. Come si è rivelato, avevo ragione.
Per un rapido avvio, mi sono iscritto a un corso 2020 dal titolo "».
Il corso, tenuto da Sheila A. Berta e Sol Ozzan, è iniziato subito con la descrizione di come funzionano i container Docker e quale percorso seguono quando vengono distribuiti in Kubernetes. È stata un'attività completamente pratica: gli studenti dovevano installare Docker e microk8s sulle proprie macchine prima delle lezioni. È stato un ottimo modo per vedere l'interazione degli strumenti tra di loro, trovare i punti deboli e, soprattutto, provare a bloccarli.
Sfortunatamente, anche se il corso prometteva di trasformarti in un "potere" dopo due giorni, sentivo che tutto era appena iniziato e che avevo ancora molto da imparare.
Prima di immergermi nelle mie alte osservazioni, è importante spiegare cosa sia un container. Nel mondo dello sviluppo, è considerato normale che il codice scritto sulla tua macchina personale funzioni perfettamente, ma quando provi a eseguirlo su un server, semplicemente non funziona. I container cercano di superare questo problema fornendo macchine autonome, che puoi facilmente trasferire da un server all'altro, sapendo che funzioneranno sempre. Come suggerisce il nome, contengono codice, librerie e altro software necessario all'operatività. Kubernetes, d'altra parte, è . In sostanza, con il suo aiuto puoi gestire senza soluzione di continuità centinaia o migliaia di diversi container.
Di seguito sono alcune delle mie considerazioni dal punto di vista della squadra rossa e della squadra blu.
Squadra rossa
La maggior parte del contenuto dei container viene eseguito con i permessi di root: significa che se comprometti il container, otterrai accesso completo al container. Questo rende i passaggi successivi notevolmente più facili.
Il montaggio di docker.sock all'interno del container è pericoloso: se hai ottenuto accesso root all'interno del container e hai anche installato Docker all'interno del container che ha il socket Docker (\/var\/run\/docker.sock), hai la potenziale possibilità di esplorare l'intero cluster, incluso l'accesso a qualsiasi altro container. Questo accesso non può essere prevenuto né dall'isolamento di rete né in altri modi.
Le variabili di ambiente spesso contengono dati sensibili: nella maggior parte dei casi, le persone inviano password nel container utilizzando normali variabili di ambiente. Quindi, se hai accesso all'account, puoi visualizzare queste variabili di ambiente per cercare di ampliare le tue autorizzazioni in seguito.
L'API di Docker può fornire molte informazioni: l'API di Docker, con le impostazioni predefinite, funziona senza autorizzazione e può fornire molte informazioni. Utilizzando Shodan, è facile trovare un elenco di porte aperte, poi ottenere informazioni dettagliate sul cluster — e procedere alla sua completa acquisizione. TrendMicro ha scritto art. .
Team blu
Non eseguire il contenuto dei container come root: anche se eseguire come root è più semplice, non dovresti farlo. Invece, esegui le applicazioni con privilegi ridotti, specificando l'uid o utilizzando l'opzione -user quando lavori con la CLI, o specificando USER nel Dockerfile.
Non consentire l'installazione di programmi nei container: quasi ogni attacco inizia con l'installazione di qualcosa. Dall'inizio di nmap fino a ifconfig e Docker stesso (all'interno del container), installare qualcosa nel container è stato comune. Per questo motivo, è sempre necessario bloccare tutte le porte non utilizzate. Questo aiuta anche a prevenire l'invio di comandi di controllo in caso di compromissione della tua macchina. Oltre a prevenire l'installazione di programmi, è importante assicurarsi che nel container ci siano il minor numero possibile di applicazioni necessarie per svolgere il compito.
Proteggi docker.sock: deve essere protetto, poiché attraverso questo socket viene gestita la comunicazione tra il container e il cluster. Poiché non voglio entrare nei dettagli in questo articolo, leggi , cosa potrebbe succedere e come bloccare tutto questo.
Usa i segreti di Docker invece delle variabili d'ambiente: I segreti ci sono . Anche se non è sicuro, è comunque meglio delle variabili d'ambiente per la trasmissione di dati riservati nei container.
Se l'articolo ha suscitato il tuo interesse per i container, puoi installare facilmente Docker oppure microk8s (una versione ridotta di Kubernetes). Ci sono istruzioni per l'installazione di Docker per Linux e MacOS, e — istruzioni per l'installazione di microk8s per Windows, Linux e MacOS.
Dopo l'installazione, puoi seguire di Docker, una variante simile esiste anche per microk8s.
Se desideri o hai bisogno di seguire un corso completo su Docker, in cui relatori esperti analizzano tutti i suoi strumenti: dalle astrazioni fondamentali alle opzioni di rete, alle particolarità del lavoro con vari sistemi operativi e linguaggi di programmazione, prova «». Ti familiarizzerai con la tecnologia e capirai dove e come utilizzare meglio Docker. E nel contempo riceverai casi di best practice: è meglio imparare in sicurezza e con il supporto di professionisti raccontando storie sui propri errori, piuttosto che imparare dagli errori con manici appuntiti.
Fonte: habr.com
