Quali sono le pratiche migliori e complete da considerare quando si esegue la finestra mobile in produzione?

Infine, sei così innamorato di Docker che vuoi spostare i tuoi sistemi di produzione business-critical online con dati sensibili dei clienti su Docker Swarm. Alcuni potrebbero addirittura averlo già fatto. L'altra organizzazione non può permetterselo con una politica che vieta i processi di produzione in esecuzione in modalità root.

Quale potrebbe essere una lista di controllo di blocchi da considerare per un ambiente di produzione Docker? Uno non ha bisogno di tutti loro, ma tutti dovrebbero essere importanti per essere valutati.

Disclaimer: so che esiste una politica per evitare "grandi liste infinite", ma penso che questa lista di controllo non possa essere molto grande ... e infinita al giorno d'oggi.

Quindi - quali sono questi blocchi di edifici?

1. Se non è già stato implementato, prendere in considerazione l'esecuzione di un sistema host Linux con impostazioni di sicurezza avanzate - kernel rinforzato, SELinux ecc.
2. Prendi in considerazione l'utilizzo di una minuscola immagine di base Docker, come alpine, busybox o persino scratch, ad esempio inizia con un'immagine di base vuota
3. Utilizzare impostazioni USER diverse da root
4. Valutare attentamente per ridurre ulteriormente l'insieme già ridotto delle capacità del kernel concesse al contenitore
5. Considera di avere un solo file binario eseguibile per contenitore per avviare il processo, idealmente collegato staticamente
6. Coloro che vogliono rompere il sistema per ottenere l'accesso alla shell potrebbero chiedersi se hanno scoperto che il contenitore ha tutte le shell disabilitate
7. Montare volumi di sola lettura ove possibile

Domanda: cos'altro?

L'host su cui sono in esecuzione i contenitori

Esegui il banco di sicurezza della finestra mobile su ogni nodo che esegue i contenitori della finestra mobile https://github.com/docker/docker-bench-security

Esecuzione del comando seguente su un nodo che esegue contenitori docker:

docker run -it --net host --pid host --cap-add audit_control \
    -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \
    -v /var/lib:/var/lib \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -v /usr/lib/systemd:/usr/lib/systemd \
    -v /etc:/etc --label docker_bench_security \
    docker/docker-bench-security

restituisce un elenco di controlli:

[INFO] 1 - Host Configuration

[WARN] 1.1  - Ensure a separate partition for containers has been created

[NOTE] 4.2  - Ensure that containers use trusted base images

[PASS] 4.6  - Ensure HEALTHCHECK instructions have been added to the container image

Citazione dal repository README:

Docker Bench for Security è uno script che verifica dozzine di best practice comuni relative all'implementazione dei container Docker in produzione. I test sono tutti automatizzati e sono ispirati al CIS Docker Community Edition Benchmark v1.1.0 .

Alcuni dei problemi segnalati dal banco di sicurezza potrebbero essere risolti leggendo l'articolo sulla sicurezza della finestra mobile ufficiale e confrontandolo con i punti elenco definiti nella domanda anche le seguenti cose sono importanti:

• proteggere il socket daemon docker implementando ssl
• fiducia dei contenuti tramite notaio e DOCKER_CONTENT_TRUSTvariabile

Docker è ancora in fase di sviluppo.

Come per ogni altro software in-dev, si verificheranno bug, potrebbero essere aggiunte funzionalità non sicure, potrebbero esserci difetti architetturali che portano a violazioni della sicurezza. Non sottovalutare questo! Il tuo sistema potrebbe essere completamente sicuro oggi, ma con la patch della prossima settimana qualcuno trova un bug, scrive un exploit e improvvisamente il tuo sistema è completamente aperto.

A meno che non sia necessario, non aggiornare all'ultima versione. Utilizzare invece l'ultima versione ben collaudata.

Docker non è virtualizzazione

Se qualcuno fugge da un container Docker, quell'attaccante si trova immediatamente sulla macchina reale. Non esiste un secondo gate come la virtualizzazione che impedirà una violazione.

Tratta un container Docker come qualsiasi altro programma. Esegui con i diritti utente più bassi possibili, blocca tutto il traffico di rete non necessario, virtualizza l'intero host Docker se le prestazioni lo consentono.

Docker non è una protezione

Qualunque codice venga eseguito all'interno dei contenitori Docker viene eseguito senza dubbio da Docker. Qualsiasi utente malintenzionato può semplicemente installare il proprio software all'interno del contenitore e Docker lo eseguirà come qualsiasi altro codice.

A parte le cose che hai menzionato nella domanda, considera l'utilizzo di metriche e avvisi per ricevere una notifica se un'immagine Docker sta facendo cose strane. C'è un improvviso picco di CPU in corso? Il programma sta eseguendo improvvisamente la scansione delle porte di rete? C'è un accesso al disco sospetto? Dovresti ricevere una notifica se ciò accade. Ci sono molti strumenti disponibili per misurare queste cose, dovresti usarle.

Immagini Docker stesse

Un'ulteriore opzione è usare Clair .

Clair è un progetto open source per l'analisi statica delle vulnerabilità nei contenitori di applicazioni (attualmente inclusi appc e docker).

A intervalli regolari, Clair ingerisce metadati di vulnerabilità da un set configurato di origini e li memorizza nel database.

I clienti usano l'API di Clair per indicizzare le loro immagini del contenitore; questo crea un elenco di funzionalità presenti nell'immagine e le memorizza nel database.

I client utilizzano l'API Clair per interrogare il database per le vulnerabilità di una particolare immagine; vulnerabilità e funzionalità correlate vengono eseguite per ogni richiesta, evitando la necessità di ripetere la scansione delle immagini.

Quando si verificano aggiornamenti ai metadati delle vulnerabilità, è possibile inviare una notifica ai sistemi di avviso in caso di modifica.

Il nostro obiettivo è consentire una visione più trasparente della sicurezza dell'infrastruttura basata su container. Pertanto, il progetto è stato chiamato Clair dopo il termine francese che si traduce in chiaro, luminoso, trasparente.

Oltre ai punti in questa discussione; la seguente sarebbe la mia raccomandazione:

• Ottieni il controllo su Docker PID1 con dumb-init
  • ref: PID1 e problema di raccolta degli zombi
• Non eseguire la finestra mobile in produzione senza un sistema di orchestrazione del contenitore
  • Scegli tra Kubernetes, Mesos, Swarm ecc.
• Usa gosu per il controllo utente all'interno di un'immagine docker
• Segui il paradigma dell'app a 12 fattori, se stai eseguendo app con stato in contenitori, modificalo.
  • Se hai davvero bisogno di eseguire app stateful (mysql, zookeeper, elasticsearch) in container, fai leva sui paradigmi dell'orchestratore come Kubernetes Statefulsets
• Esegui una solida gestione segreta / di configurazione con strumenti come hashicorp vault / console
• Spedisci lo stesso container creato dagli sviluppatori per produrre attraverso una pipeline CI che lo porta attraverso la messa in scena, i test di integrazione a fondo.
• Crea notifiche su CVE e patch, attiva build sulla notifica delle patch
• Avere una registrazione estesa per ottenere informazioni dettagliate sul contenitore in esecuzione, non si desidera dare agli sviluppatori SSH l'accesso all'host o ai contenitori
  • raccomandazione: fluentd
• Dispone di metriche sia per container che per host
  • raccomandazione: prometeo + nodo-esportatore

Se si sta riempiendo il punto di accesso alla finestra mobile con sedcomandi, considerare questa pratica:

• Utilizzare uno strumento come confd per gestire i file di configurazione delle immagini della finestra mobile e mantenerli aggiornati

Confd leggerà i dati da molti archivi di valori-chiave supportati e renderà dinamicamente modelli di configurazione.

Si potrebbe usare A2D per inserire un'app in un'immagine docker tenendo conto di alcune cose, ad esempio non root, permessi, posizione dell'app:

docker run -v $PWD:/projectName utrecht/a2d:1.0.0 \
       -projectName someProjectName -dockerfile /projectName/Dockerfile

ritorna:

FROM golang:1.12.4-alpine as builder
COPY . ./someProjectName/
WORKDIR someProjectName
RUN adduser -D -g '' someProjectName && \
    apk add git && \
    CGO_ENABLED=0 go build && \
    cp someProjectName /someProjectName && \
    chmod 100 /someProjectName

FROM scratch
COPY --from=builder /etc/group /etc/group
COPY --from=builder /etc/passwd /etc/passwd
COPY --from=builder --chown=someProjectName:someProjectName /someProjectName /usr/local/someProjectName
COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
USER someProjectName
ENTRYPOINT ["/usr/local/someProjectName"]