Lavoro nel settore IT da più di 20 anni, ma per qualche motivo non sono mai riuscito a utilizzare i container. In teoria avevo capito come erano strutturati e come funzionavano. Ma poiché non li avevo mai incontrati nella pratica, non ero sicuro di come girassero e girassero esattamente gli ingranaggi sotto il cofano.
Inoltre, non avevo idea di come fosse la loro sicurezza. Ma ancora una volta, la teoria suona bene e la vecchia canzone “all’aumentare della sicurezza, l’usabilità diminuisce” mi è rimasta in testa. Quindi ho pensato che, poiché tutto è così facile da fare con i container, la sicurezza lì è al di sotto della media. A quanto pare, avevo ragione.
Per iniziare rapidamente, mi sono iscritto ai corsi 2020 dal titolo "'.
Il corso, tenuto da Sheila A. Berta e Sol Ozzan, è iniziato immediatamente con una descrizione di come funzionano i contenitori Docker e del viaggio che intraprendono quando vengono distribuiti su Kubernetes. Si è trattato di una lezione completamente pratica: gli studenti dovevano installare Docker e microk8s sui loro computer prima della lezione, un ottimo modo per vedere come gli strumenti interagiscono tra loro, trovare punti deboli e, soprattutto, provare a bloccarli.
Purtroppo, nonostante i corsi promettessero di diventare “principali” dopo due giorni, sentivo che tutto era appena iniziato e avevo ancora molto da imparare.
Prima di addentrarci nelle mie nobili osservazioni, è importante spiegare cos'è un contenitore. Nel mondo dello sviluppo, è considerato normale che il codice scritto sul tuo computer personale funzioni perfettamente, ma quando provi a eseguirlo su un server da qualche parte, semplicemente non funziona. I container cercano di superare questo problema fornendo macchine autonome che puoi spostare facilmente da un server all'altro, sapendo che funzioneranno sempre. Come suggerisce il nome, contengono il codice, le librerie e altri software necessari per portare a termine il lavoro. Kubernetes, invece, lo è . In linea di principio, può essere utilizzato per gestire senza problemi centinaia o migliaia di contenitori diversi.
Di seguito sono riportate alcune delle mie scoperte dal punto di vista della squadra rossoblù.
Squadra Rossa
La maggior parte del contenuto del contenitore viene eseguito come root: Ciò significa che se il contenitore è compromesso, avrai pieno accesso al contenitore. Ciò rende i passaggi successivi molto più semplici.
Montare docker.sock all'interno di un contenitore è pericoloso: se hai root all'interno di un contenitore e hai installato Docker anche all'interno di un contenitore che dispone di un socket Docker (/var/run/docker.sock), hai la possibilità di esplorare l'intero cluster, incluso l'accesso a qualsiasi altro contenitore. Tale accesso non può essere impedito mediante l'isolamento della rete o altri mezzi.
Le variabili d'ambiente spesso contengono dati segreti: nella maggior parte dei casi, le persone inviano le password al contenitore utilizzando le normali variabili di ambiente. Quindi, se hai accesso all'account, puoi spiare queste variabili d'ambiente per espandere successivamente i tuoi poteri.
L'API Docker può fornire molte informazioni: L'API Docker, se configurata per impostazione predefinita, viene eseguita senza autorizzazione e può produrre moltissime informazioni. Utilizzando Shodan, puoi facilmente trovare un elenco di porte aperte, quindi ottenere informazioni dettagliate sul cluster e procedere alla sua acquisizione completa. TrendMicro ha scritto a riguardo .
Squadra blu
Non eseguire il contenuto del contenitore come root: Anche se è più semplice eseguirlo come root, non dovresti farlo. Esegui invece le applicazioni con autorizzazioni di reimpostazione visualizzando l'uid, utilizzando l'opzione --user durante l'esecuzione dalla CLI o specificando USER nel Dockerfile.
Non consentire l'installazione di software nei contenitori: Quasi ogni attacco inizia piantando qualcosa. Da nmap a ifconfig allo stesso Docker (all'interno di un contenitore), installare qualsiasi cosa in un contenitore è stato un luogo comune. Per lo stesso motivo dovresti sempre bloccare tutte le porte non utilizzate. Ciò aiuta anche a impedire la trasmissione dei comandi di controllo quando il computer è infetto. Oltre a impedire l'installazione dei programmi, è opportuno assicurarsi che nel contenitore stesso sia installato il numero minimo di applicazioni necessarie per completare l'attività.
Proteggi docker.sock: deve essere protetto perché la comunicazione tra il contenitore e il cluster viene elaborata tramite questo socket. Dato che non voglio entrare nei dettagli in questo articolo, leggi , cosa può succedere e anche come bloccare il tutto.
Utilizza i segreti Docker invece delle variabili di ambiente: Ci sono segreti . Sebbene questo non sia sicuro, è comunque migliore delle variabili di ambiente per passare dati segreti al contenitore.
Se l'articolo ha suscitato il tuo interesse per i container, puoi installare facilmente Docker o 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 andare da Docker, opzione simile e per microk8.
Se vuoi o devi seguire un corso completo su Docker, in cui relatori pratici esaminano tutti i suoi strumenti: dalle astrazioni di base ai parametri di rete, alle sfumature del lavoro con vari sistemi operativi e linguaggi di programmazione, quindi prova "" Acquisirai familiarità con la tecnologia e capirai dove e come utilizzare al meglio Docker. E allo stesso tempo, ottieni casi di buone pratiche: è meglio imparare in sicurezza e con il supporto dei professionisti dalle storie sui rastrelli che personalmente dai rastrelli stessi con manici chiodati.
Fonte: habr.com