Lavoro nell'IT da oltre 20 anni, ma non mi ero mai occupato di container. In teoria capivo come erano fatti e come funzionavano. Ma dal momento che non avevo mai avuto esperienza pratica con loro, non ero sicuro di come effettivamente girassero i loro ingranaggi sotto il cofano.
Inoltre, non avevo idea di come fosse la loro sicurezza. Ma ancora una volta, la teoria suonava bene, e la vecchia storia "con l'aumento della sicurezza diminuisce la comodità d'uso" mi girava in testa. Così ho pensato che, dato che era così facile lavorare con i container, la sicurezza fosse molto bassa. Come si è rivelato, avevo ragione.
Per un avvio rapido mi sono iscritto a un corso 2020 intitolato "».
Il corso tenuto da Sheila A. Berta e Sol Ozzan è cominciato con una descrizione del funzionamento dei container Docker e del percorso che seguono durante il deployment in Kubernetes. È stata un'attività completamente pratica: gli studenti dovevano installare Docker e microk8s sui propri computer prima delle lezioni, un ottimo modo per vedere l'interazione degli strumenti, identificare eventuali vulnerabilità e, cosa più importante, provare a risolverle.
Purtroppo, anche se i corsi promettevano di diventare il "principe" dopo due giorni, sentivo che era solo l'inizio e che avevo ancora molto da imparare.
Prima di immergerti nelle mie osservazioni elevate, è importante spiegare cosa sia un container. Nel mondo dello sviluppo, è normale che il codice scritto sulla tua macchina personale funzioni alla perfezione, ma che, tentando di eseguirlo su un server, non funzioni affatto. 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 per operare. Kubernetes, d'altra parte, è . In sostanza, con esso puoi gestire senza interruzioni centinaia o migliaia di diversi container.
Di seguito sono riportate alcune delle mie considerazioni dalla prospettiva della squadra rossa e della squadra blu.
Squadra rossa
La maggior parte del contenuto dei container viene eseguito come root: questo significa che se comprometti un container, ottieni accesso completo al container. Ciò rende i passaggi successivi significativamente più facili.
Montare docker.sock all'interno del container è pericoloso: se hai ottenuto l'accesso root all'interno del contenitore e hai anche installato Docker all'interno di un contenitore con socket Docker (/var/run/docker.sock), hai la possibilità potenziale di esplorare l'intero cluster, inclusa la possibilità di accedere a qualsiasi altro contenitore. Tale accesso non può essere prevenuto né mediante isolamento di rete né con altri metodi.
Le variabili di ambiente contengono spesso dati sensibili: nella maggior parte dei casi, le persone inviano password al contenitore utilizzando normali variabili di ambiente. Pertanto, se hai accesso all'account, puoi visualizzare queste variabili di ambiente per poi espandere le tue autorizzazioni.
Docker API può fornire una grande quantità di informazioni: Docker API, quando configurato per impostazione predefinita, funziona senza autorizzazione e può fornire una grande quantità di informazioni. Utilizzando Shodan, è facile trovare un elenco di porte aperte, ottenere informazioni dettagliate sul cluster e passare al suo completo controllo. TrendMicro ha scritto un .
Team blu
Non eseguire il contenuto dei contenitori come root: nonostante sia più semplice avviare come root, non dovresti farlo. Invece, avvia le applicazioni con i privilegi ridotti visualizzando l’UID oppure usando il parametro —user quando lavori con la CLI, o specificando USER nel Dockerfile.
Non consentire l'installazione di programmi nei contenitori: quasi ogni attacco inizia con l'installazione di qualcosa. Dall’nmap a ifconfig e lo stesso Docker (all'interno del contenitore), installare qualcosa in un contenitore è 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 infezione della tua macchina. Oltre a prevenire l'installazione di programmi, è importante assicurarsi che all'interno del contenitore ci siano solo le applicazioni minime necessarie per completare il compito.
Proteggi docker.sock: deve essere protetto poiché attraverso questa socket avviene la comunicazione tra il contenitore e il cluster. Poiché non voglio entrare nei dettagli in questo articolo, leggi , cosa può succedere e come bloccare tutto ciò.
Utilizza i segreti di Docker invece delle variabili d'ambiente: I segreti esistono . Anche se non è sicuro, è comunque meglio rispetto all'utilizzo delle variabili d'ambiente per trasmettere dati sensibili nei container.
Se l'articolo ha suscitato il tuo interesse per i container, puoi facilmente installare Docker o microk8s (una versione leggera 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, che è simile anche per microk8s.
Se hai voglia o necessità di seguire un corso completo su Docker, in cui relatori pratici analizzano tutti i suoi strumenti: dalle astrazioni di base alle opzioni di rete, ai dettagli sul funzionamento con vari sistemi operativi e linguaggi di programmazione, prova "". Ti familiarizzerai con la tecnologia e capirai dove e come utilizzare al meglio Docker. Inoltre, riceverai casi di best practice: è meglio imparare in sicurezza e con il supporto di praticanti attraverso storie sugli errori piuttosto che affrontare i propri errori personalmente.
Fonte: habr.com
