Ciao, Habr!
Nell'attuale contesto, data l'importanza crescente della containerizzazione nei processi di sviluppo, la questione della sicurezza in relazione ai vari stadi e alle entità associate ai container è di grande rilevanza. Compiere controlli manuali è un compito laborioso; pertanto, sarebbe utile iniziare almeno a automatizzare questo processo.
In questo articolo condividerò degli script pronti all'uso per l'implementazione di diverse utility di sicurezza per Docker, insieme a istruzioni su come allestire un piccolo ambiente di demo per testare questo processo. Puoi utilizzare il materiale per sperimentare con l'organizzazione del processo di testing della sicurezza delle immagini e delle istruzioni Dockerfile. È chiaro che l'infrastruttura di sviluppo e implementazione varia per ognuno, quindi di seguito presenterò alcune possibili varianti.
Utility di verifica della sicurezza
Esistono numerosi strumenti ausiliari e script che eseguono controlli su vari aspetti dell'infrastruttura Docker. Alcuni di essi sono stati già descritti in un articolo precedente (), e in questo materiale vorrei soffermarmi su tre di essi, che coprono la parte principale dei requisiti di sicurezza per le immagini Docker che vengono costruite durante il processo di sviluppo. Inoltre, mostrerò un esempio di come è possibile combinare queste tre utility in un unico pipeline per effettuare controlli di sicurezza.
Hadolint
Un'utilità da console piuttosto semplice, che aiuta a valutare in modo preliminare la correttezza e la sicurezza delle istruzioni dei Dockerfile (ad esempio, l'uso solo di registry autorizzati per le immagini o l'uso di sudo).
Dockle
Un'utilità da console che lavora con un'immagine (o con un archivio tar salvato dell'immagine), che verifica la correttezza e la sicurezza di una specifica immagine analizzando i suoi layer e la configurazione: quali utenti sono stati creati, quali istruzioni vengono utilizzate, quali volumi sono collegati, la presenza di password vuote, ecc. Attualmente, il numero di controlli non è molto grande e si basa su alcune proprie verifiche e raccomandazioni. per Docker.
Trivy
Questo strumento è progettato per individuare vulnerabilità di due tipi: problemi di compilazione del sistema operativo (supportati Alpine, RedHat (EL), CentOS, Debian GNU, Ubuntu) e problemi nelle dipendenze (Gemfile.lock, Pipfile.lock, composer.lock, package-lock.json, yarn.lock, Cargo.lock). Trivy è in grado di scansionare sia un'immagine nel repository che un'immagine locale, oltre a eseguire la scansione sulla base di un file .tar di un'immagine Docker.
Opzioni di implementazione dello strumento
Per provare le applicazioni descritte in ambienti isolati, fornirò istruzioni per l'installazione di tutti gli strumenti in un processo semplificato.
L'idea principale è dimostrare come sia possibile implementare il controllo automatico del contenuto dei Dockerfile e delle immagini Docker che vengono create durante il processo di sviluppo.
Il controllo stesso consiste nei seguenti passaggi:
- Controllo della correttezza e della sicurezza delle istruzioni Dockerfile tramite uno strumento di linting Hadolint
- Verifica della correttezza e della sicurezza delle immagini finali e intermedie tramite uno strumento Dockle
- Controllo della presenza di vulnerabilità note (CVE) nell'immagine di base e in alcune dipendenze tramite uno strumento Trivy
In seguito nell'articolo fornirò tre opzioni per implementare questi passaggi:
Primo — configurando il pipeline CI/CD utilizzando GitLab (con una descrizione del processo di creazione di un'istanza di test).
Secondo — utilizzando uno script shell.
Terzo — creando un'immagine Docker per la scansione delle immagini Docker.
Puoi scegliere l'opzione che meglio ti si addice, trasferirla sulla tua infrastruttura e adattarla alle tue esigenze.
Tutti i file necessari e ulteriori istruzioni sono anche disponibili nel repository:
Integrazione in GitLab CI/CD
Nel primo caso, vedremo come implementare controlli di sicurezza utilizzando il sistema di repository GitLab. Qui seguiremo i passaggi e vedremo come installare un ambiente di test da zero con GitLab, comporre il processo di scansione e avviare gli strumenti per controllare il Dockerfile di prova e un'immagine casuale — l'applicazione JuiceShop.
Installazione di GitLab
1. Installiamo Docker:
sudo apt-get update && sudo apt-get install docker.io2. Aggiungiamo l'utente corrente al gruppo docker, in modo da poter lavorare con Docker senza sudo:
sudo addgroup docker3. Troviamo il proprio IP:
ip addr4. Installiamo e avviamo GitLab in un container, sostituendo l'indirizzo IP in hostname con il proprio:
docker run --detach
--hostname 192.168.1.112
--publish 443:443 --publish 80:80
--name gitlab
--restart always
--volume /srv/gitlab/config:/etc/gitlab
--volume /srv/gitlab/logs:/var/log/gitlab
--volume /srv/gitlab/data:/var/opt/gitlab
gitlab/gitlab-ce:latestAspettiamo che GitLab completi tutte le procedure necessarie per l'installazione (è possibile monitorare il processo tramite l'output del file di log: docker logs -f gitlab).
5. Apriamo il nostro IP locale nel browser e vediamo una pagina che offre di cambiare la password per l'utente root:
Impostiamo una nuova password e accediamo a GitLab.
6. Creiamo un nuovo progetto, ad esempio cicd-test, e lo inizializziamo con un file di partenza. README.md:
7. Ora dobbiamo installare GitLab Runner: l'agente che eseguirà tutte le operazioni necessarie su richiesta.
Scarichiamo l'ultima versione (in questo caso — per Linux 64-bit):
sudo curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd648. Rendi eseguibile:
sudo chmod +x /usr/local/bin/gitlab-runner9. Aggiungi un utente del sistema operativo per Runner e avvia il servizio:
sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash
sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
sudo gitlab-runner startDovrebbe risultare più o meno così:
local@osboxes:~$ sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
Runtime platform arch=amd64 os=linux pid=8438 revision=0e5417a3 version=12.0.1
local@osboxes:~$ sudo gitlab-runner start
Runtime platform arch=amd64 os=linux pid=8518 revision=0e5417a3 version=12.0.1 10. Ora registriamo il Runner affinché possa interagire con la nostra istanza di GitLab.
Per fare ciò, apriamo la pagina Impostazioni-CI/CD (http://OUR_IP_ADDRESS/root/cicd-test/-/settings/ci_cd) e nella scheda Runners troviamo l'URL e il token di registrazione:
11. Registriamo il Runner, inserendo l'URL e il token di registrazione:
sudo gitlab-runner register
--non-interactive
--url "http:///"
--registration-token ""
--executor "docker"
--docker-privileged
--docker-image alpine:latest
--description "docker-runner"
--tag-list "docker,privileged"
--run-untagged="true"
--locked="false"
--access-level="not_protected"Alla fine abbiamo un GitLab pronto all'uso, a cui dobbiamo aggiungere istruzioni per avviare i nostri strumenti. In questo caso dimostrativo non abbiamo passi per la compilazione dell'applicazione e la sua containerizzazione, ma in un ambiente reale, questi precederebbero i passi di scansione e formerebbero le immagini e il Dockerfile per l'analisi.
Configurazione del pipeline
1. Aggiungiamo al repository i file mydockerfile.df (questo è un Dockerfile di test che andremo a verificare) e il file di configurazione del processo GitLab CI/CD .gitlab-cicd.yml, che elenca le istruzioni per gli scanner (nota il punto nel nome del file).
Il file di configurazione YAML contiene istruzioni per l'esecuzione di tre utilità (Hadolint, Dockle e Trivy), che analizzeranno il Dockerfile scelto e l'immagine specificata nella variabile DOCKERFILE. Tutti i file necessari possono essere presi dal repository:
Estratto da mydockerfile.df (questo è un file astratto con un insieme di istruzioni arbitrarie solo per dimostrare il funzionamento dell'utilità). Collegamento diretto al file:
Contenuto di mydockerfile.df
FROM amd64/node:10.16.0-alpine@sha256:f59303fb3248e5d992586c76cc83e1d3700f641cbcd7c0067bc7ad5bb2e5b489 AS tsbuild
COPY package.json .
COPY yarn.lock .
RUN yarn install
COPY lib lib
COPY tsconfig.json tsconfig.json
COPY tsconfig.app.json tsconfig.app.json
RUN yarn build
FROM amd64/ubuntu:18.04@sha256:eb70667a801686f914408558660da753cde27192cd036148e58258819b927395
LABEL maintainer="Rhys Arkins "
LABEL name="renovate"
...
COPY php.ini /usr/local/etc/php/php.ini
RUN cp -a /tmp/piik/* /var/www/html/
RUN rm -rf /tmp/piwik
RUN chown -R www-data /var/www/html
ADD piwik-cli-setup /piwik-cli-setup
ADD reset.php /var/www/html/
## ENTRYPOINT ##
ADD entrypoint.sh /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]
USER rootLa configurazione YAML appare in questo modo (il file stesso può essere scaricato tramite il link diretto qui: ):
Contenuto di .gitlab-ci.yml
variabili:
DOCKER_HOST: "tcp://docker:2375/"
DOCKERFILE: "mydockerfile.df" # nome del Dockerfile da analizzare
DOCKERIMAGE: "bkimminich/juice-shop" # nome dell'immagine Docker da analizzare
# DOCKERIMAGE: "knqyf263/cve-2018-11235" # immagine Docker di test con diversi CVE CRITICI
SHOWSTOPPER_PRIORITY: "CRITICO" # quale livello di criticità farà fallire il lavoro di Trivy
TRIVYCACHE: "$CI_PROJECT_DIR/.cache" # dove memorizzare il database di vulnerabilità di Trivy per un riutilizzo più veloce
ARTIFACT_FOLDER: "$CI_PROJECT_DIR"
servizi:
- docker:dind # per poter costruire immagini docker all'interno del Runner
stages:
- scan
- report
- publish
HadoLint:
# Analisi lint di base delle istruzioni del Dockerfile
fase: scan
immagine: docker:git
after_script:
- cat $ARTIFACT_FOLDER/hadolint_results.json
script:
- export VERSION=$(wget -q -O - https://api.github.com/repos/hadolint/hadolint/releases/latest | grep '"tag_name":' | sed -E 's/.*"v([^"]+)".*//')
- wget https://github.com/hadolint/hadolint/releases/download/v${VERSION}/hadolint-Linux-x86_64 && chmod +x hadolint-Linux-x86_64
# NB: hadolint uscirà sempre con codice di uscita 0
- ./hadolint-Linux-x86_64 -f json $DOCKERFILE > $ARTIFACT_FOLDER/hadolint_results.json || exit 0
artifacts:
when: always # restituire gli artifact anche dopo il fallimento del lavoro
paths:
- $ARTIFACT_FOLDER/hadolint_results.json
Dockle:
# Analizzando le migliori pratiche riguardanti l'immagine docker (autorizzazioni degli utenti, istruzioni seguite quando è stata creata l'immagine, ecc.)
fase: scan
immagine: docker:git
after_script:
- cat $ARTIFACT_FOLDER/dockle_results.json
script:
- export VERSION=$(wget -q -O - https://api.github.com/repos/goodwithtech/dockle/releases/latest | grep '"tag_name":' | sed -E 's/.*"v([^"]+)".*//')
- wget https://github.com/goodwithtech/dockle/releases/download/v${VERSION}/dockle_${VERSION}_Linux-64bit.tar.gz && tar zxf dockle_${VERSION}_Linux-64bit.tar.gz
- ./dockle --exit-code 1 -f json --output $ARTIFACT_FOLDER/dockle_results.json $DOCKERIMAGE
artifacts:
when: always # restituire gli artifact anche dopo il fallimento del lavoro
paths:
- $ARTIFACT_FOLDER/dockle_results.json
Trivy:
# Analizzando l'immagine docker e le dipendenze dei pacchetti rispetto a diverse basi di CVE
fase: scan
immagine: docker:git
script:
# ottenendo l'ultima versione di Trivy
- apk add rpm
- export VERSION=$(wget -q -O - https://api.github.com/repos/knqyf263/trivy/releases/latest | grep '"tag_name":' | sed -E 's/.*"v([^"]+)".*//')
- wget https://github.com/knqyf263/trivy/releases/download/v${VERSION}/trivy_${VERSION}_Linux-64bit.tar.gz && tar zxf trivy_${VERSION}_Linux-64bit.tar.gz
# visualizzando tutte le vulnerabilità senza far fallire la build
- ./trivy -d --cache-dir $TRIVYCACHE -f json -o $ARTIFACT_FOLDER/trivy_results.json --exit-code 0 $DOCKERIMAGE
# scrivere informazioni sulle vulnerabilità in stdout in un formato leggibile (leggere json puro non è divertente, eh?). Puoi rimuovere questo se non ne hai bisogno.
- ./trivy -d --cache-dir $TRIVYCACHE --exit-code 0 $DOCKERIMAGE
# far fallire la build se viene trovata la priorità SHOWSTOPPER
- ./trivy -d --cache-dir $TRIVYCACHE --exit-code 1 --severity $SHOWSTOPPER_PRIORITY --quiet $DOCKERIMAGE
artifacts:
when: always # restituire gli artifact anche dopo il fallimento del lavoro
paths:
- $ARTIFACT_FOLDER/trivy_results.json
cache:
paths:
- .cache
Report:
# combinando le uscite degli strumenti in un unico HTML
fase: report
when: always
immagine: python:3.5
script:
- mkdir json
- cp $ARTIFACT_FOLDER/*.json ./json/
- pip install json2html
- wget https://raw.githubusercontent.com/shad0wrunner/docker_cicd/master/convert_json_results.py
- python ./convert_json_results.py
artifacts:
paths:
- results.htmlSe necessario, è possibile eseguire la scansione e salvare le immagini memorizzate come archivi .tar (tuttavia, sarà necessario modificare i parametri di input per gli strumenti nel file YAML)
NB: Trivy richiede l'installazione per l'avvio rpm e git. In caso contrario, genererà errori durante la scansione delle immagini basate su RedHat e nell'ottenere aggiornamenti del database delle vulnerabilità.
2. Dopo aver aggiunto i file al repository, in base alle istruzioni nel nostro file di configurazione, GitLab avvierà automaticamente il processo di costruzione e scansione. Nella scheda CI/CD → Pipelines sarà possibile vedere l'andamento dell'esecuzione delle istruzioni.
Di conseguenza, abbiamo quattro compiti. Tre di questi si occupano direttamente della scansione e l'ultimo (Report) raccoglie un semplice rapporto da file sparsi con i risultati della scansione.
Per impostazione predefinita, Trivy interrompe la propria esecuzione se vengono riscontrate vulnerabilità CRITICAL nell'immagine o nelle dipendenze. Allo stesso tempo, Hadolint restituisce sempre un codice di Success, poiché il suo risultato presenta sempre delle note, il che porta a fermare la costruzione.
A seconda delle specifiche esigenze, è possibile configurare il codice di uscita in modo che queste utility interrompano anche il processo di build quando rilevano problemi di certa criticità. Nel nostro caso, la build si fermerà solo se Trivy rileva una vulnerabilità con il livello di criticità che abbiamo specificato nella variabile SHOWSTOPPER in .gitlab-ci.yml.
È possibile visualizzare i risultati di ciascuna utility nel log di ogni task di scansione, direttamente nei file json nella sezione artifacts o in un semplice report HTML (di cui parleremo più avanti):
3. Per presentare i report delle utility in una forma leggermente più leggibile, viene utilizzato un piccolo script Python per convertire tre file json in un unico file HTML con una tabella di difetti.
Questo script viene eseguito come un task separato, Report, e il suo artefatto finale è un file HTML con il report. Il sorgente dello script si trova anch'esso nel repository ed è possibile adattarlo alle proprie necessità, colori, ecc.
Shell script
La seconda opzione è adatta per situazioni in cui è necessario controllare le immagini Docker al di fuori di un sistema CI/CD oppure si desidera avere tutte le istruzioni in un formato che può essere eseguito direttamente sull'host. Questa opzione è coperta da uno script shell pronto all'uso, che può essere eseguito su una macchina virtuale pulita (o anche reale). Lo script esegue le stesse istruzioni del gitlab-runner descritto sopra.
Per il corretto funzionamento dello script, Docker deve essere installato nel sistema e l'utente attuale deve appartenere al gruppo docker.
È possibile scaricare lo script qui:
All'inizio del file, si impostano le variabili che definiscono quale immagine scansionare e quali difetti di gravità causerebbero l'uscita dall'utility Trivy con il codice di errore specificato.
Durante l'esecuzione dello script, tutti gli strumenti verranno scaricati nella directory docker_tools, i risultati del loro lavoro saranno nella directory docker_tools/json, e l'HTML con il rapporto sarà contenuto nel file results.html.
Esempio di output dello script
~/docker_cicd$ ./docker_sec_check.sh
[+] Impostazione delle variabili ambiente
[+] Installazione dei pacchetti richiesti
[+] Preparazione delle directory necessarie
[+] Recupero del Dockerfile di esempio
2020-10-20 10:40:00 (45.3 MB/s) - 'Dockerfile' salvato [8071/8071]
[+] Recupero dell'immagine da esaminare
latest: Stiamo recuperando da bkimminich/juice-shop
[+] Esecuzione di Hadolint
...
Dockerfile:205 DL3015 Evitare pacchetti aggiuntivi specificando `--no-install-recommends`
Dockerfile:248 DL3002 L'ultimo USER non dovrebbe essere root
...
[+] Esecuzione di Dockle
...
WARN - DKL-DI-0006: Evitare il tag latest
* Evitare il tag 'latest'
INFO - CIS-DI-0005: Abilitare la fiducia dei contenuti per Docker
* esportare DOCKER_CONTENT_TRUST=1 prima di docker pull/build
...
[+] Esecuzione di Trivy
juice-shop/frontend/package-lock.json
=====================================
Totale: 3 (UNKNOWN: 0, LOW: 1, MEDIUM: 0, HIGH: 2, CRITICAL: 0)
+---------------------+------------------+----------+---------+-------------------------+
| BIBLIOTECA | ID VULNERABILITÀ | GRAVITÀ | VERSIONE| TITOLO |
+---------------------+------------------+----------+---------+-------------------------+
| object-path | CVE-2020-15256 | ALTA | 0.11.4 | Inquinamento del prototipo|
| | | | | object-path |
+---------------------+------------------+ +---------+-------------------------+
| tree-kill | CVE-2019-15599 | | 1.2.2 | Iniezione di codice |
+---------------------+------------------+----------+---------+-------------------------+
| webpack-subresource | CVE-2020-15262 | BASSA | 1.4.1 | Chunk caricati dinamicamente non protetti|
| | | | | |
+---------------------+------------------+----------+---------+-------------------------+
juice-shop/package-lock.json
============================
Totale: 20 (UNKNOWN: 0, LOW: 1, MEDIUM: 6, HIGH: 8, CRITICAL: 5)
...
juice-shop/package-lock.json
============================
Totale: 5 (CRITICAL: 5)
...
[+] Rimozione dei residui
[+] Rendi l'output elegante
[+] Conversione dei risultati in JSON
[+] Scrittura dei risultati in HTML
[+] Uscita pulita ============================================================
[+] Tutto è completato. Trova il report HTML risultante in results.htmlImmagine Docker con tutti gli strumenti
Come terza alternativa, ho creato due semplici Dockerfile per costruire un'immagine con gli strumenti di sicurezza. Un Dockerfile aiuterà a raccogliere un set per la scansione dell'immagine dal repository, l'altro (Dockerfile_tar) serve per raccogliere un set per la scansione di un file tar con l'immagine.
1. Prendiamo il Dockerfile e gli script appropriati dal repository .
2. Lo avviamo per la costruzione:
docker build -t dscan:image -f docker_security.df .
3. Al termine della costruzione, creiamo un contenitore dall'immagine. Durante questo passaggio, passiamo la variabile d'ambiente DOCKERIMAGE con il nome dell'immagine di nostro interesse e montiamo il Dockerfile che vogliamo analizzare dal nostro computer sul file /Dockerfile (nota che è richiesto il percorso assoluto per questo file):
docker run --rm -v $(pwd)/results:/results -v $(pwd)/docker_security.df:/Dockerfile -e DOCKERIMAGE="bkimminich/juce-shop" dscan:image
[+] Impostazione delle variabili d'ambiente
[+] Esecuzione di Hadolint
/Dockerfile:3 DL3006 Tagga sempre esplicitamente la versione di un'immagine
[+] Esecuzione di Dockle
WARN - DKL-DI-0006: Evita il tag latest
* Evita il tag 'latest'
INFO - CIS-DI-0005: Abilita la fiducia nei contenuti per Docker
* export DOCKER_CONTENT_TRUST=1 prima di docker pull/build
INFO - CIS-DI-0006: Aggiungi l'istruzione HEALTHCHECK all'immagine del container
* dichiarazione HEALTHCHECK non trovata
INFO - DKL-LI-0003: Metti solo i file necessari
* file non necessario: juice-shop/node_modules/sqlite3/Dockerfile
* file non necessario: juice-shop/node_modules/sqlite3/tools/docker/architecture/linux-arm64/Dockerfile
* file non necessario: juice-shop/node_modules/sqlite3/tools/docker/architecture/linux-arm/Dockerfile
[+] Esecuzione di Trivy
...
juice-shop/package-lock.json
============================
Totale: 20 (UNKNOWN: 0, LOW: 1, MEDIUM: 6, HIGH: 8, CRITICAL: 5)
...
[+] Rendi l'output più gradevole
[+] Avvio del modulo principale ============================================================
[+] Conversione dei risultati JSON
[+] Scrittura dei risultati HTML
[+] Uscita pulita ============================================================
[+] Tutto è fatto. Trova il report HTML risultante in results.htmlRisultati
Abbiamo esaminato solo un set di strumenti di base per la scansione degli artefatti Docker, che, a mio avviso, copre in modo abbastanza efficace una buona parte dei requisiti di sicurezza delle immagini. Ci sono anche molti altri strumenti a pagamento e gratuiti che possono eseguire le stesse verifiche, generare report dettagliati o funzionare esclusivamente in modalità console, coprendo sistemi di gestione dei container, ecc. Una panoramica di questi strumenti e dei modi per integrarli potrebbe arrivare in un secondo momento.
Un aspetto positivo del set di strumenti descritto nell'articolo è che tutti sono basati su codice sorgente aperto, quindi puoi sperimentare con essi e altri strumenti simili per trovare ciò che si adatta meglio alle tue esigenze e particolarità dell'infrastruttura. Naturalmente, tutte le vulnerabilità trovate devono essere esaminate per la loro applicabilità in condizioni specifiche, ma questo è un tema per un futuro grande articolo.
Spero che queste istruzioni, gli script e le utilità possano esserti utili e diventino un punto di partenza per creare un'infrastruttura più sicura nel campo della containerizzazione.
Fonte: habr.com
