‫Il prossimo.
‫Questo è grande.
‫Non eseguire le app come root nel contenitore se è
‫possibile evitarlo.
‫Se lo faccio velocemente, su una piccola
‫demo qui.
‫Tutto ok. Ho Docker in esecuzione,
‫almeno dovrei. Tutto ok.
‫E se corro solo ...
‫Se ho appena eseguito Nginx, giusto, e faccio una
‫finestra mobile in alto su
‫quel contenitore.
‫Cosa vediamo qui?
‫All'interno del contenitore, Nginx ha avviato un
‫processo alla radice, quindi ha creato
‫un nuovo processo come utente non
‫root. Scopri come l'utente ha 101 anni.
‫Questo è comune a molti programmi basati su demoni
‫come MySQL, Postgres, Nginx.
‫Molti di quelli che non sono linguaggi di programmazione
‫lo faranno automaticamente. Quindi, questo è sicuro.
‫Ciò che sta facendo è consentire a Nginx di
‫generare processi di lavoro che non funzionano come root
‫per svolgere la maggior parte del lavoro.
‫Quindi, hanno un processo principale che funziona come root, ma non è
‫questo che accetta le connessioni e fa la maggior
‫parte del lavoro. La maggior parte di
‫questi è in questi processi di lavoro. Funzionano come un normale utente,
‫il che significa che se c'è una vulnerabilità in Nginx,
‫è probabile che le connessioni in
‫entrata stiano arrivando e qualcuno sta cercando di sfruttare
‫il protocollo HTTP Nginx, verrà bloccato o imprigionato in questo utente
‫in .. il più delle volte a meno che
‫non ci sia una grave vulnerabilità che è quassù.
‫Quaggiù, e poi sono limitati a ciò che
‫possono fare, giusto. Anche se dovessero assumere
‫quel processo in qualche modo, sono comunque limitati come l'utente.
‫Quindi va bene.
‫Questo non è ancora in esecuzione come root
‫vero all'interno del contenitore. Quello di cui sto davvero parlando
‫è se dovessi eseguire un'app
‫Python, o un'app Node o qualcosa del
‫genere in cui è un linguaggio di programmazione, allora sarà qualcosa che
‫per impostazione predefinita è root perché il linguaggio
‫di programmazione nel contenitore non lo fa ' so come funziona
‫il tuo programma. Non sa cosa vuoi che faccia.
‫Quindi, eseguirà il root per impostazione predefinita, e questo
‫riguarda di più la compatibilità delle applicazioni.
‫Potremmo dire che vogliamo che questo sia sicuro per impostazione
‫predefinita, ma Docker ha scelto che tutti questi contenitori ufficiali funzionassero davvero come
‫root per i linguaggi di programmazione.
‫Andiamo a dare un'occhiata.
‫Ops. Non quello.
‫Firefox.
‫Quindi se andiamo, diciamo, su Hub.
‫Facciamo solo Node.
‫Questo è comune nella maggior parte delle lingue.
‫Vado a scegliere Node come esempio.
‫All'interno di
‫Node, se entro in uno dei Dockerfile qui.
‫Quindi cerco l'utente.
‫Noterai che in realtà non trovo nulla.
‫È solo questo utente che aggiunge qui.
‫Noterai che lo fa, giusto.
‫Tecnicamente sta aggiungendo un gruppo chiamato Nodo e sta
‫aggiungendo un utente chiamato Nodo.
‫Se cerchi il resto di questo file, ti rendi conto che non
‫cambia mai a quell'utente con la stanza U S
‫E R, giusto.
‫Dovresti vedere il nodo utente lì dentro da qualche parte come una linea.
‫Non lo fanno perché è il tuo lavoro.
‫Quindi, cosa dovresti fare nel Dockerfile
‫di livello inferiore. Quindi, qualsiasi file
‫Docker che stai creando da queste immagini
‫ufficiali per i linguaggi di programmazione, dovresti sfruttare gli utenti
‫che stanno creando per te. Se non stanno creando quegli utenti, puoi crearne uno
‫tu stesso allo stesso modo. Puoi semplicemente rubare
‫questa piccola cosa a due righe e passare a qualsiasi
‫utente tu voglia che sia. Se è per
‫Python, potresti semplicemente chiamarlo utente Python, comunque.
‫Se lo stai facendo, le applicazioni
‫che esegui non verranno eseguite come root nel
‫contenitore. Per
‫impostazione predefinita, se si esegue semplicemente un'app Node standard, utilizzerà l'utente
‫root in un contenitore.
‫Perché è così importante?
‫Bene, due cose.
‫Uno, se qualcuno è in grado di sfondare la
‫tua applicazione e hackerare la tua applicazione e ottenere l'accesso
‫al file system, se ... se tale applicazione è root,
‫quindi nel contenitore, possono fare quello che vogliono
‫nel contenitore, giusto. Possono scrivere
‫file nel file system. Possono installare più programmi in quel contenitore
‫che possono essere eseguiti ogni volta che vogliono in quel contenitore.
‫Quindi, non vogliamo davvero che lo facciano.
‫Preferiremmo che fossero molto limitati.
‫Quindi, se le tue applicazioni lo
‫supportano, sai, fallo. Fondamentalmente ti assicuri di avere
‫l'utente disponibile.
‫Quindi ho un esempio da DockerCon qui.
‫Alla DockerCon, ho avuto un intero discorso su Node. js e
‫uno degli argomenti riguardava l'utente.
‫Fammi vedere se riesco a trovarlo.
‫Vedi cosa ho fatto qui? È un file piuttosto semplice.
‫Ho intenzione di collegare questo e inserirlo.
‫In questo Dockerfile.
‫Quindi, in questo Dockerfile ho ...
‫Non ho creato un utente perché l'immagine del nodo
‫l'ha già creata per me. Sto solo passando al nodo utente.
‫Quindi sto installando i miei pacchetti con queste due linee e,
‫successivamente, lo eseguirò.
‫Noterai che devo iniziare a usare
‫l'opzione chown nei miei comandi di copia per assicurarmi che i miei
‫file siano ora lo stesso utente dell'utente su cui verrà eseguito
‫il mio programma. Altrimenti, potrebbero esserci problemi,
‫giusto. La mia applicazione probabilmente ... se
‫non riesce a leggere i file, non può eseguirlo, giusto.
‫Quindi, ho bisogno delle modifiche quelle autorizzazioni.
‫Posso farlo con una sola riga su un comando di copia.
‫Vedrai anche qui che sto creando la directory e la
‫chown in modo che ogni volta che l'app viene copiata,
‫voglio solo assicurarmi, in più, che le autorizzazioni
‫siano lì in modo che possa scrivere.
‫Perché nel momento in cui cambio questo utente,
‫questo comando di copia, o in particolare questo comando di esecuzione, verrà
‫eseguito come quell'utente. Se non ha
‫le autorizzazioni per scrivere nelle directory, fallirà anche.
‫Quindi, la ragione per cui Docker non fa questo per te è
‫perché sanno che probabilmente le tue cose si romperanno.
‫Quindi, devi prendere questi passaggi extra.
‫Ma non è così difficile. Non lo è davvero.
‫Probabilmente puoi fare tutti questi test in un giorno, quindi
‫vorrai eseguire i tuoi sistemi attraverso CI completi e test completi
‫sui tuoi server perché a volte, e PHP è uno di quelli
‫che non vanno bene in questo.
‫A PHP piace eseguire un sacco di file di registro e
‫scrivere un sacco su disco.
‫Davvero, tutto ciò che consente il caricamento da parte degli utenti
‫scriverà sul disco. Quindi, devi assicurarti che
‫quelle autorizzazioni siano corrette in modo che quando le persone scrivono file, ad esempio
‫diciamo che stiano eseguendo un blog WordPress.
‫Quel blog WordPress scriverà su disco quando gli utenti
‫caricheranno le immagini sul loro blog.
‫Vuoi assicurarti che quelle autorizzazioni funzionino.
‫Quindi dovrai assolutamente fare dei test.
‫Dopo averlo fatto, ora l'applicazione non
‫funzionerà come root. Quindi, non può avere il
‫pieno controllo nel contenitore. L'altra ragione per
‫cui vuoi farlo è se c'è una vulnerabilità
‫in Linux, che è rara, o Docker, che è
‫anche molto rara, quindi c'è meno probabilità che
‫usciranno da questo contenitore. È successo solo una volta che
‫ne sono molto consapevole, e in realtà ne ho documentato
‫un po 'qui.
‫MUCCA sporca. Dirty COW era
‫una vulnerabilità in Linux che ti permetteva di
‫uscire
‫da un container, giusto. Il cambio del tuo utente
‫proprio qui,
‫non necessariamente risolverebbe l'intero problema, ma
‫certamente non ha danneggiato questo problema.
‫Altre vulnerabilità, probabilmente proteggerebbero da.
‫Ma questa è una buona pratica.
‫Penso che se hai un team di sicurezza,
‫insisteranno sul fatto che non gestisci le cose come root.
‫Quindi, lo faresti.