Hallo, Habr!
In de huidige werkelijkheid, gezien de toenemende rol van containerisatie in ontwikkelingsprocessen, is de vraag naar de beveiliging van verschillende fasen en entiteiten in verband met containers niet onbelangrijk. Handmatige controles zijn tijdrovend, dus het zou goed zijn om ten minste de eerste stappen naar automatisering van dit proces te zetten.
In dit artikel deel ik kant-en-klare scripts voor het implementeren van verschillende beveiligingshulpmiddelen voor Docker en geef ik instructies over hoe je een kleine demo-omgeving kunt opzetten om dit proces te testen. De materialen kunnen worden gebruikt om te experimenteren met hoe je het proces van veiligheidsbeoordeling van Docker-images en Dockerfile-instructies kunt organiseren. Het is duidelijk dat de ontwikkelings- en implementatie-infrastructuur voor iedereen anders is, daarom geef ik hieronder een aantal mogelijke opties.
Beveiligingshulpmiddelen
Er zijn veel verschillende hulpmiddelen en scripts beschikbaar die controles uitvoeren op verschillende aspecten van de Docker-infrastructuur. Een deel van deze zijn al beschreven in het vorige artikel (), en in dit document wil ik me concentreren op drie van hen die een groot deel van de beveiligingseisen voor Docker-images, die in het ontwikkelingsproces worden opgebouwd, dekken. Daarnaast laat ik ook een voorbeeld zien van hoe deze drie hulpmiddelen in Ć©Ć©n pipeline kunnen worden samengevoegd voor het uitvoeren van beveiligingscontroles.
Hadolint
Een vrij eenvoudige consoletool die helpt om in eerste instantie de correctheid en veiligheid van Dockerfile-instructies te beoordelen (bijvoorbeeld het gebruik van alleen toegestane image registries of het gebruik van sudo).
Dockle
Een consoletool die werkt met een image (of met een opgeslagen tar-archief van een image), die de correctheid en veiligheid van een specifieke image controleert door zijn lagen en configuratie te analyseren - welke gebruikers zijn aangemaakt, welke instructies worden gebruikt, welke volumes zijn gekoppeld, de aanwezigheid van een leeg wachtwoord, enzovoort. Momenteel is het aantal controles nog niet zeer groot en is het gebaseerd op enkele eigen controles en aanbevelingen. voor Docker.
Trivy
Deze tool is gericht op het vinden van kwetsbaarheden van twee soorten ā problemen met besturingssysteembuilds (ondersteund worden Alpine, RedHat (EL), CentOS, Debian GNU, Ubuntu) en afhankelijkheidsproblemen (Gemfile.lock, Pipfile.lock, composer.lock, package-lock.json, yarn.lock, Cargo.lock). Trivy kan zowel een afbeelding in de repository scannen als een lokale afbeelding, en kan ook scannen op basis van een doorgegeven .tar-bestand met een Docker-afbeelding.
Opties voor het implementeren van tools
Om de beschreven toepassingen in een geĆÆsoleerde omgeving uit te proberen, geef ik instructies voor het installeren van alle tools binnen een vereenvoudigd proces.
Het hoofddoel is om aan te tonen hoe automatische controle van de inhoud van Dockerfile en Docker-afbeeldingen, die tijdens de ontwikkeling worden gemaakt, kan worden geĆÆmplementeerd.
De controle zelf bestaat uit de volgende stappen:
- Controle van de juistheid en veiligheid van de instructies in de Dockerfile met behulp van een linter Hadolint
- Controle van de juistheid en veiligheid van de eind- en tussenoplossingen met behulp van een tool Dockle
- Controle op bekende kwetsbaarheden (CVE) in de basisafbeelding en een reeks afhankelijkheden met behulp van een tool Trivy
Verder in het artikel geef ik drie opties voor het implementeren van deze stappen:
De eerste is door het configureren van een CI/CD-pijplijn aan de hand van een voorbeeld van GitLab (met een beschrijving van het proces om een testinstantie op te zetten).
De tweede is met behulp van een shell-script.
De derde is door een Docker-afbeelding te bouwen voor het scannen van Docker-afbeeldingen.
U kunt de optie kiezen die het best bij u past, deze overdragen naar uw infrastructuur en aanpassen aan uw behoeften.
Alle benodigde bestanden en aanvullende instructies zijn ook beschikbaar in de repository:
Integratie in GitLab CI/CD
In de eerste optie bekijken we hoe we beveiligingscontroles kunnen implementeren aan de hand van het voorbeeld van de GitLab-repositorysysteem. Hier lopen we door de stappen en bespreken hoe we vanaf nul een testomgeving met GitLab kunnen opzetten, het scanningproces kunnen samenstellen en de tools kunnen uitvoeren voor het controleren van een test-Dockerfile en een willekeurige afbeelding - de applicatie JuiceShop.
Installatie van GitLab
1. Installeer Docker:
sudo apt-get update && sudo apt-get install docker.io2. Voeg de huidige gebruiker toe aan de docker-groep, zodat u met Docker kunt werken zonder sudo:
sudo addgroup docker3. Vind uw IP:
ip addr4. Installeer en start GitLab in een container, vervang het IP-adres in hostname door het uwe:
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:latestWe wachten tot GitLab alle noodzakelijke installatiestappen heeft uitgevoerd (je kunt het proces volgen via de loguitvoer: docker logs -f gitlab).
5. Open in je browser je lokale IP en zie de pagina met de optie om het wachtwoord voor de gebruiker root te wijzigen:
Stel een nieuw wachtwoord in en log in op GitLab.
6. Maak een nieuw project aan, bijvoorbeeld cicd-test, en initialiseer dit met een startbestand. README.md:
7. Nu moeten we GitLab Runner installeren: de agent die op verzoek alle noodzakelijke handelingen uitvoert.
Download de laatste versie (in dit geval voor 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. Maak het uitvoerbaar:
sudo chmod +x /usr/local/bin/gitlab-runner9. Voeg een besturingssysteemgebruiker toe voor de Runner en start de service:
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 startHet zou er ongeveer zo uit moeten zien:
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. Registreer nu de Runner zodat deze met onze GitLab-instantie kan communiceren.
Open hiervoor de pagina Instellingen-CI/CD (http://OUR_IP_ADDRESS/root/cicd-test/-/settings/ci_cd) en vind de URL en registratie-token op het tabblad Runners:
11. Registreer de Runner door de URL en het registratie-token in te vullen:
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"Uiteindelijk hebben we een werkende GitLab dat klaar is om instructies voor het starten van onze tools toe te voegen. In dit demonstratiet geval hebben we geen stappen voor het bouwen van de applicatie en de containerisatie, maar in een echte omgeving zullen deze voorafgaan aan de scanstappen en zullen ze beelden en Dockerfiles voor analyse creƫren.
Pijplijnconfiguratie
1. Voeg bestanden toe aan de repository mydockerfile.df (dit is een test-Dockerfile die we gaan controleren) en het configuratiebestand GitLab CI/CD-proces .gitlab-cicd.yml, dat instructies voor de scanners opsomt (let op de punt in de bestandsnaam).
Het YAML-configuratiebestand bevat instructies voor het starten van drie hulpprogramma's (Hadolint, Dockle en Trivy) die de geselecteerde Dockerfile en de afbeelding, opgegeven in de variabele DOCKERFILE, analyseren. Alle benodigde bestanden kunnen uit de repository worden gehaald:
Uittreksel uit mydockerfile.df (dit is een abstract bestand met een set willekeurige instructies alleen voor demonstreert het functioneren van het hulpprogramma). Rechtstreekse link naar het bestand:
Inhoud van 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 <rhys@arkins.net>"
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 rootDe YAML-configuratie ziet er als volgt uit (het bestand kan direct hier worden gedownload: ):
Inhoud van .gitlab-ci.yml
variabelen:
DOCKER_HOST: "tcp://docker:2375/"
DOCKERFILE: "mydockerfile.df" # naam van het te analyseren Dockerfile
DOCKERIMAGE: "bkimminich/juice-shop" # naam van de te analyseren Docker-image
# DOCKERIMAGE: "knqyf263/cve-2018-11235" # test Docker-image met verschillende CRITICAL CVE
SHOWSTOPPER_PRIORITY: "CRITICAL" # welk niveau van kritischheid de Trivy-taak zal laten falen
TRIVYCACHE: "$CI_PROJECT_DIR/.cache" # waar de Trivy-database van kwetsbaarheden wordt opgeslagen voor snellere hergebruik
ARTIFACT_FOLDER: "$CI_PROJECT_DIR"
diensten:
- docker:dind # om Docker-images binnen de Runner te kunnen bouwen
fases:
- scan
- rapport
- publiceer
HadoLint:
# Basis lint-analyse van Dockerfile-instructies
fase: scan
afbeelding: docker:git
na_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([^"]+)".*//1/')
- wget https://github.com/hadolint/hadolint/releases/download/v${VERSION}/hadolint-Linux-x86_64 && chmod +x hadolint-Linux-x86_64
# NB: hadolint zal altijd met exitcode 0 afsluiten
- ./hadolint-Linux-x86_64 -f json $DOCKERFILE > $ARTIFACT_FOLDER/hadolint_results.json || exit 0
artefacten:
wanneer: altijd # retourneer artefacten zelfs na fout van de taak
paden:
- $ARTIFACT_FOLDER/hadolint_results.json
Dockle:
# Analyse van beste praktijken voor Docker-image (gebruikersrechten, instructies gevolgd tijdens het bouwen van het image, enz.)
fase: scan
afbeelding: docker:git
na_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([^"]+)".*//1/')
- 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
artefacten:
wanneer: altijd # retourneer artefacten zelfs na fout van de taak
paden:
- $ARTIFACT_FOLDER/dockle_results.json
Trivy:
# Analyse van Docker-image en pakketafhankelijkheden tegen verschillende CVE-databases
fase: scan
afbeelding: docker:git
script:
# de nieuwste Trivy verkrijgen
- apk add rpm
- export VERSION=$(wget -q -O - https://api.github.com/repos/knqyf263/trivy/releases/latest | grep '"tag_name":' | sed -E 's/.*"v([^"]+)".*//1')
- wget https://github.com/knqyf263/trivy/releases/download/v${VERSION}/trivy_${VERSION}_Linux-64bit.tar.gz && tar zxf trivy_${VERSION}_Linux-64bit.tar.gz
# weergeven van alle kwetsbaarheden zonder de build te laten falen
- ./trivy -d --cache-dir $TRIVYCACHE -f json -o $ARTIFACT_FOLDER/trivy_results.json --exit-code 0 $DOCKERIMAGE
# schrijf kwetsbaarheden-informatie naar stdout in menselijk leesbaar formaat (het lezen van pure json is niet leuk, hĆØ?). Je kunt dit verwijderen als je het niet nodig hebt.
- ./trivy -d --cache-dir $TRIVYCACHE --exit-code 0 $DOCKERIMAGE
# de build laten falen als de SHOWSTOPPER-prioriteit wordt gevonden
- ./trivy -d --cache-dir $TRIVYCACHE --exit-code 1 --severity $SHOWSTOPPER_PRIORITY --quiet $DOCKERIMAGE
artefacten:
wanneer: altijd # retourneer artefacten zelfs na fout van de taak
paden:
- $ARTIFACT_FOLDER/trivy_results.json
cache:
paden:
- .cache
Rapport:
# combineren van tool-output in Ć©Ć©n HTML
fase: rapport
wanneer: altijd
afbeelding: 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
artefacten:
paden:
- results.htmlIndien nodig kunnen ook opgeslagen beelden worden gescand in de vorm van een .tar-archief (maar dan moeten de invoerparameters voor de tools in het YAML-bestand worden aangepast)
NB: Trivy vereist geĆÆnstalleerde rpm en git. Anders geeft het fouten bij het scannen van op RedHat-gebaseerde afbeeldingen en het verkrijgen van updates voor de kwetsbaarhedendatabase.
2. Na het toevoegen van bestanden aan de repository begint GitLab automatisch het bouw- en scanproces volgens de instructies in ons configuratiebestand. Op het tabblad CI/CD ā Pipelines kun je de voortgang van de instructies bekijken.
Hierdoor hebben we vier taken. Drie van hen zijn verantwoordelijk voor het scannen, en de laatste (Report) verzamelt een eenvoudig rapport uit de verschillende bestanden met scanresultaten.
Standaard stopt Trivy zijn uitvoering als er CRITICAL kwetsbaarheden in de afbeelding of afhankelijkheden worden ontdekt. Tegelijkertijd retourneert Hadolint altijd een Success uitvoercode, omdat zijn uitvoering altijd opmerkingen oplevert, wat leidt tot een stopzetting van de bouw.
Afhankelijk van de specifieke vereisten kan de exitcode worden aangepast, zodat deze tools ook het bouwproces stoppen als problemen van bepaalde kritiek worden ontdekt. In ons geval stopt de bouw alleen als Trivy een kwetsbaarheid met de kriticiteit ontdekt die we hebben opgegeven in de variabele SHOWSTOPPER in .gitlab-ci.yml.
Het resultaat van elke tool kan worden bekeken in de log van elke scanopdracht, rechtstreeks in de json-bestanden in de sectie artifacts of in een eenvoudig HTML-rapport (daarover hierna meer):
3. Voor de weergave van de rapporten van de tools in een iets leesbaardere vorm wordt een klein Python-script gebruikt om drie json-bestanden te converteren naar Ć©Ć©n HTML-bestand met een defectentabel.
Dit script wordt gestart als een aparte taak Report, en de uiteindelijke artifact is een HTML-bestand met het rapport. De bron van het script ligt ook in de repository en kan worden aangepast aan eigen behoeften, kleuren, enz.
Shell-script
De tweede optie is geschikt voor situaties waarin Docker-images moeten worden gecontroleerd buiten een CI/CD-systeem of wanneer alle instructies beschikbaar moeten zijn in een formaat dat direct op de host kan worden uitgevoerd. Deze optie wordt ondersteund door een kant-en-klaar shell-script dat kan worden uitgevoerd op een schone virtuele (of zelfs echte) machine. Het script voert dezelfde instructies uit als de hierboven beschreven gitlab-runner.
Voor een succesvolle werking van het script moet Docker in het systeem zijn geĆÆnstalleerd en moet de huidige gebruiker tot de docker-groep behoren.
Het script kan hier worden gedownload:
Aan het begin van het bestand worden variabelen ingesteld voor welk image moet worden gescand en welke defecten van welke ernst een exit uit de Trivy-tool met de aangegeven foutcode zullen veroorzaken.
Tijdens de uitvoering van het script worden alle tools gedownload naar de directory docker_tools, de resultaten van hun werk - naar de directory docker_tools/json, terwijl de HTML met het rapport zich zal bevinden in het bestand results.html.
Voorbeeld van de uitvoer van het script
~/docker_cicd$ ./docker_sec_check.sh
[+] Omgevingsvariabelen instellen
[+] Vereiste pakketten installeren
[+] Noodzakelijke directories voorbereiden
[+] Voorbeeld Dockerfile ophalen
2020-10-20 10:40:00 (45.3 MB/s) - āDockerfileā opgeslagen [8071/8071]
[+] Image downloaden om te scannen
latest: Trekken van bkimminich/juice-shop
[+] Hadolint uitvoeren
...
Dockerfile:205 DL3015 Vermijd extra pakketten door `--no-install-recommends` op te geven
Dockerfile:248 DL3002 Laatste USER mag niet root zijn
...
[+] Dockle uitvoeren
...
WAARSCHUWING - DKL-DI-0006: Vermijd de latest-tag
* Vermijd de 'latest'-tag
INFO - CIS-DI-0005: Schakel contentvertrouwen in voor Docker
* exporteer DOCKER_CONTENT_TRUST=1 voordat je docker pull/build
...
[+] Trivy uitvoeren
juice-shop/frontend/package-lock.json
=====================================
Totaal: 3 (UNKNOWN: 0, LOW: 1, MEDIUM: 0, HIGH: 2, CRITICAL: 0)
+---------------------+------------------+----------+---------+-------------------------+
| BIBLIOTHEEK | VULNERABILITEIT ID | SEVERITEIT | VERSIE | TITEL |
+---------------------+------------------+----------+---------+-------------------------+
| object-path | CVE-2020-15256 | HIGH | 0.11.4 | Prototype vervuiling in |
| | | | | object-path |
+---------------------+------------------+ +---------+-------------------------+
| tree-kill | CVE-2019-15599 | | 1.2.2 | Code-injectie |
+---------------------+------------------+----------+---------+-------------------------+
| webpack-subresource | CVE-2020-15262 | LOW | 1.4.1 | Onbeschermde dynamisch |
| | | | | geladen chunks |
+---------------------+------------------+----------+---------+-------------------------+
juice-shop/package-lock.json
============================
Totaal: 20 (UNKNOWN: 0, LOW: 1, MEDIUM: 6, HIGH: 8, CRITICAL: 5)
...
juice-shop/package-lock.json
============================
Totaal: 5 (CRITICAL: 5)
...
[+] Overblijfselen verwijderen
[+] De uitvoer mooi maken
[+] JSON-resultaten converteren
[+] Resultaten HTML schrijven
[+] Netjes afsluiten ============================================================
[+] Alles is gedaan. Je vindt het resulterende HTML-rapport in results.htmlDocker-image met alle tools
Als derde alternatief heb ik twee eenvoudige Dockerfiles gemaakt voor het creƫren van een image met beveiligingtools. EƩn Dockerfile helpt om een set te verzamelen voor het scannen van een image uit een repository, de andere (Dockerfile_tar) is om een set te verzamelen voor het scannen van een tar-bestand met een image.
1. Neem de relevante Dockerfile en scripts uit de repository .
2. Voer deze uit voor de bouw:
docker build -t dscan:image -f docker_security.df .
3. Na de bouw creƫren we een container vanuit de image. Hierbij geven we de omgevingsvariabele DOCKERIMAGE door met de naam van de image die we willen analyseren en mounten de Dockerfile die we willen analyseren van onze machine naar het bestand /Dockerfile (let op, het vereiste is een absoluut pad naar dit bestand):
docker run --rm -v $(pwd)/results:/results -v $(pwd)/docker_security.df:/Dockerfile -e DOCKERIMAGE="bkimminich/juice-shop" dscan:image
[+] Omgevingsvariabelen instellen
[+] Hadolint uitvoeren
/Dockerfile:3 DL3006 Tag altijd de versie van een image expliciet
[+] Dockle uitvoeren
WAARSCHUWING - DKL-DI-0006: Vermijd de latest tag
* Vermijd 'latest' tag
INFO - CIS-DI-0005: Schakel inhoudsvertrouwen in voor Docker
* exporteer DOCKER_CONTENT_TRUST=1 voor docker pull/build
INFO - CIS-DI-0006: Voeg een HEALTHCHECK-instructie toe aan de container image
* HEALTHCHECK-instructie niet gevonden
INFO - DKL-LI-0003: Plaats alleen noodzakelijke bestanden
* onnodig bestand: juice-shop/node_modules/sqlite3/Dockerfile
* onnodig bestand: juice-shop/node_modules/sqlite3/tools/docker/architecture/linux-arm64/Dockerfile
* onnodig bestand: juice-shop/node_modules/sqlite3/tools/docker/architecture/linux-arm/Dockerfile
[+] Trivy uitvoeren
...
juice-shop/package-lock.json
============================
Totaal: 20 (ONBEKEND: 0, LAAG: 1, GEMIDDELD: 6, HOOG: 8, CRITIEK: 5)
...
[+] De output er mooi uit laten zien
[+] Hoofdmodule starten ============================================================
[+] JSON-resultaten converteren
[+] Resultaten in HTML schrijven
[+] Schoon afsluiten ============================================================
[+] Alles is gedaan. Vind het resulterende HTML-rapport in results.htmlResultaten
We hebben slechts Ć©Ć©n basisset van tools voor het scannen van Docker-artifacten besproken, die naar mijn mening een aanzienlijk deel van de vereisten voor de beveiliging van images zeer effectief dekt. Er zijn nog veel meer betaalde en gratis tools die dezelfde controles kunnen uitvoeren, mooie rapporten kunnen genereren of puur in de consolemodus kunnen werken, containerbeheersystemen kunnen dekken, enzovoort. Een overzicht van deze tools en manieren om ze te integreren, zal misschien iets later verschijnen.
Een positief aspect van de toolkit die in dit artikel wordt beschreven, is dat al deze tools op open source zijn gebaseerd, waardoor u kunt experimenteren met hen en andere soortgelijke tools om te vinden wat precies past bij uw behoeften en infrastructuur. Uiteraard moeten alle kwetsbaarheden die gevonden worden, worden bestudeerd op toepasbaarheid in specifieke omstandigheden, maar dit is het onderwerp voor een toekomstige uitgebreide artikel.
Ik hoop dat deze instructie, scripts en tools u helpen en een startpunt vormen voor het creƫren van een veiligere infrastructuur op het gebied van containerisatie.
Bron: habr.com
