Hello, Habr!
I den moderne virkelighed, på grund af den stigende rolle af containerisering i udviklingsprocesserne, står spørgsmålet om sikkerhed for forskellige faser og enheder relateret til containere ikke tilbage. At udføre kontroller manuelt er en besværlig opgave, så det ville være godt at tage mindst de første skridt mod automatisering af denne proces.
I denne artikel vil jeg dele færdige scripts til implementering af flere sikkerhedsudnyttelsesteknikker til Docker og en vejledning til at opsætte en lille demo-stand for at teste denne proces. Materialerne kan bruges til at eksperimentere med, hvordan man organiserer sikkerhedstestning af billeder og Dockerfile-instruktioner. Det er klart, at udviklings- og implementeringsinfrastrukturen er forskellig for alle, så nedenfor vil jeg give nogle mulige varianter.
Sikkerhedsværktøjer
Der findes et stort antal forskellige hjælpeprogrammer og scripts, der udfører kontroller af forskellige aspekter af Docker-infrastrukturen. Nogle af dem er allerede blevet beskrevet i den forrige artikel (), og i denne tekst vil jeg gerne fokusere på tre af dem, der dækker hovedparten af kravene til sikkerhed for Docker-billeder, der opbygges under udviklingsprocessen. Derudover vil jeg også vise et eksempel på, hvordan man kan samle disse tre værktøjer i en enkelt pipeline til udførelse af sikkerhedskontroller.
Hadolint
Et ganske enkelt konsolværktøj, der hjælper med først at vurdere korrektheden og sikkerheden af Dockerfile-instruktioner (for eksempel ved at bruge kun godkendte billedregistre eller ved at bruge sudo).
Dockle
Et konsolværktøj, der arbejder med et billede (eller en gemt tar-arkiv af billedet), som kontrollerer korrektheden og sikkerheden af det specifikke billede som sådan, ved at analysere dets lag og konfiguration – hvilke brugere der er oprettet, hvilke instruktioner der anvendes, hvilke volumener der er tilsluttet, tilstedeværelsen af et tomt kodeord osv. Indtil videre er antallet af kontroller ikke særlig stort og bygger på nogle få egne kontroller og anbefalinger for Docker.
Trivy
Dette værktøj er designet til at finde sårbarheder af to typer – OS-byggeproblemer (understøtter Alpine, RedHat (EL), CentOS, Debian GNU, Ubuntu) og problemer i afhængigheder (Gemfile.lock, Pipfile.lock, composer.lock, package-lock.json, yarn.lock, Cargo.lock). Trivy kan scanne både et billede i et repository og et lokalt billede samt udføre scanning baseret på en given .tar-fil med et Docker-billede.
Implementeringsmuligheder for værktøjer
For at prøve de beskrevne applikationer i et isoleret miljø, vil jeg give instruktioner til installation af alle værktøjer inden for en forenklet proces.
Hovedideen er at demonstrere, hvordan man kan implementere automatisk kontrol af indholdet i Dockerfile og Docker-billeder, der oprettes i udviklingsprocessen.
Selve kontrollen består af følgende trin:
- Kontrol af korrekthed og sikkerhed af Dockerfile-instruktioner – med et linter-værktøj Hadolint
- Kontrol af korrekthed og sikkerhed af endelige og mellemliggende billeder – med et værktøj Dockle
- Kontrol af eksisterende sårbarheder (CVE) i basisbilledet og en række afhængigheder – med et værktøj Trivy
Dernæst vil jeg i artiklen give tre implementeringsmuligheder for disse trin:
Den første – ved at konfigurere CI/CD-pipeline ved hjælp af eksemplet GitLab (med beskrivelse af processen for at oprette en testinstans).
Den anden – ved hjælp af et shell-script.
Den tredje – ved at bygge et Docker-billede til scanning af Docker-billeder.
Du kan vælge den mulighed, der passer dig bedst, overføre den til din infrastruktur og tilpasse den til dine behov.
Alle nødvendige filer og yderligere instruktioner findes også i repository:
Integration i GitLab CI/CD
I den første mulighed vil vi se på, hvordan man kan implementere sikkerhedskontroller ved hjælp af GitLab-repositoriesystemet. Her vil vi gennemgå trinene og forklare, hvordan man opsætter et testmiljø med GitLab fra bunden, etablerer scanningsprocessen og udfører værktøjerne til at kontrollere den testede Dockerfile og et vilkårligt billede – applikationen JuiceShop.
Installation af GitLab
1. Installer Docker:
sudo apt-get update && sudo apt-get install docker.io2. Tilføj den nuværende bruger til docker-gruppen, så du kan arbejde med Docker uden sudo:
sudo addgroup docker3. Find din IP:
ip addr4. Installer og start GitLab i containere, erstatt IP-adressen i hostname med din egen:
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:latestVi venter på, at GitLab udfører alle nødvendige installationsprocedurer (du kan overvåge processen gennem logfilens output: docker logs -f gitlab).
5. Åbn din lokale IP i browseren, og du vil se en side, der tilbyder at ændre adgangskoden for brugeren root:
Indstil en ny adgangskode og log ind på GitLab.
6. Opret et nyt projekt, f.eks. cicd-test, og initialiser det med en startfil. README.md:
7. Nu skal vi installere GitLab Runner: agenten, der vil køre alle nødvendige operationer efter behov.
Download den nyeste version (i dette tilfælde - til 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. Gør det eksekverbart:
sudo chmod +x /usr/local/bin/gitlab-runner9. Tilføj en OS-bruger til Runneren og start tjenesten:
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 startDet skulle se cirka sådan ud:
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. Nu registrerer vi Runneren, så den kan interagere med vores GitLab-instans.
For at gøre dette åbner vi siden Settings-CI/CD (http://OUR_IP_ADDRESS/root/cicd-test/-/settings/ci_cd) og finder URL'en og registreringstokenet under fanen Runners:
11. Registrer Runneren ved at indsætte URL'en og registreringstokenet:
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"Som resultat får vi et fuldt fungerende GitLab, hvor vi skal tilføje instruktioner til at starte vores værktøjer. I dette demonstrations tilfælde har vi ikke trin til applikationsbygning og containerisering, men i et reelt miljø vil disse komme før scanningstrin og danne billeder og Dockerfile til analyse.
Pipeline-konfiguration
1. Lad os tilføje filer til repositoryet mydockerfile.df (dette er en slags test-Dockerfile, som vi vil kontrollere) og konfigurationsfilen til GitLab CI/CD-processen .gitlab-cicd.yml, som angiver instruktioner til scannere (bemærk punktet i filnavnet).
YAML-konfigurationsfilen indeholder instruktioner til at køre tre værktøjer (Hadolint, Dockle og Trivy), som vil analysere den valgte Dockerfile og det billede, der er angivet i variablen DOCKERFILE. Alle nødvendige filer kan hentes fra repositoriet:
Uddrag fra mydockerfile.df (dette er en abstrakt fil med et sæt vilkårlige instruktioner kun til demonstration af værktøjets funktion). Direkte link til filen:
Indholdet af 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 rootYAML-konfigurationen ser således ud (selve filen kan hentes via dette direkte link: ):
Indholdet af .gitlab-ci.yml
variabler:
DOCKER_HOST: "tcp://docker:2375/"
DOCKERFILE: "mydockerfile.df" # navnet på Dockerfilen der skal analyseres
DOCKERIMAGE: "bkimminich/juice-shop" # navnet på Dockerbilledet der skal analyseres
# DOCKERIMAGE: "knqyf263/cve-2018-11235" # test Dockerbillede med flere KRI TISK CVE
SHOWSTOPPER_PRIORITY: "CRITICAL" # hvilken grad af kritikalitet der vil få Trivy-jobbet til at fejle
TRIVYCACHE: "$CI_PROJECT_DIR/.cache" # hvor Trivy-databasen med sårbarheder caches for hurtigere genbrug
ARTIFACT_FOLDER: "$CI_PROJECT_DIR"
tjenester:
- docker:dind # for at kunne bygge dockerbilleder inde i Runner
stadier:
- scan
- rapport
- offentliggør
HadoLint:
# Grundlæggende linseanalyse af Dockerfile-instruktioner
stage: scan
image: 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([^"]+)".*//1/')
- wget https://github.com/hadolint/hadolint/releases/download/v${VERSION}/hadolint-Linux-x86_64 && chmod +x hadolint-Linux-x86_64
# NB: hadolint vil altid afslutte med 0 exit-kode
- ./hadolint-Linux-x86_64 -f json $DOCKERFILE > $ARTIFACT_FOLDER/hadolint_results.json || exit 0
artefakter:
when: always # returnere artefakter selv efter jobfejl
paths:
- $ARTIFACT_FOLDER/hadolint_results.json
Dockle:
# Analyserer bedste praksis om dockerbillede (brugers tilladelser, instruktioner der blev fulgt, da billedet blev bygget, osv.)
stage: scan
image: 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([^"]+)".*//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
artefakter:
when: always # returnere artefakter selv efter jobfejl
paths:
- $ARTIFACT_FOLDER/dockle_results.json
Trivy:
# Analyserer dockerbillede og pakkeafhængigheder mod flere CVE-databaser
stage: scan
image: docker:git
script:
# henter den seneste 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([^"]+)".*//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
# viser alle sårbarheder uden at fejle bygningen
- ./trivy -d --cache-dir $TRIVYCACHE -f json -o $ARTIFACT_FOLDER/trivy_results.json --exit-code 0 $DOCKERIMAGE
# skrive sårbarhedsinfo til stdout i menneskeligt læsbart format (ren json er ikke sjovt, ikke?) Du kan fjerne dette, hvis du ikke har brug for det.
- ./trivy -d --cache-dir $TRIVYCACHE --exit-code 0 $DOCKERIMAGE
# fejler bygningen hvis SHOWSTOPPER-prioriteten findes
- ./trivy -d --cache-dir $TRIVYCACHE --exit-code 1 --severity $SHOWSTOPPER_PRIORITY --quiet $DOCKERIMAGE
artefakter:
when: always # returnere artefakter selv efter jobfejl
paths:
- $ARTIFACT_FOLDER/trivy_results.json
cache:
paths:
- .cache
Rapport:
# kombinerer værktøjsudgange til én HTML
stage: report
when: always
image: 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
artefakter:
paths:
- results.htmlHvis det er nødvendigt, kan man også scanne og gemme billeder som .tar-arkiver (dog skal indstillingerne i YAML-filen ændres for værktøjerne).
NB: Trivy kræver, at det er installeret for at kunne køre. rpm og gitEllers vil det give fejl, når der scannes RedHat-baserede billeder og hentes opdateringer til sårbarhedsbasen.
2. Efter at have tilføjet filer til repositoriet, vil GitLab automatisk starte bygge- og scanningsprocessen i henhold til instruktionerne i vores konfigurationsfil. Under fanen CI/CD → Pipelines kan man se udførelsesforløbet af instruktionerne.
Som et resultat har vi fire opgaver. Tre af dem arbejder direkte med scanning, og den sidste (Report) samler en simpel rapport fra de forskellige scanningsresultater.
Som standard stopper Trivy sin udførelse, hvis der opdages KRITISKE sårbarheder i billedet eller afhængighederne. Samtidig returnerer Hadolint altid en Success kode, da der altid er bemærkninger fra dets udførelse, hvilket medfører, at byggeprocessen stopper.
Afhængigt af de specifikke krav kan udgangskoden konfigureres, så disse værktøjer stopper byggeprocessen, hvis der opdages problemer af en bestemt kritikalitet. I vores tilfælde vil byggeprocessen kun stoppe, hvis Trivy opdager en sårbarhed med den kritikalitet, vi har angivet i variablen SHOWSTOPPER i. .gitlab-ci.yml.
Resultatet af hver værktøjs udførelse kan ses i loggen for hver scanningsopgave, direkte i json-filerne i artifacts-sektionen eller i en simpel HTML-rapport (om den lidt senere):
3. For at præsentere rapporter fra værktøjerne i en mere læsevenlig form bruges et lille Python-script til at konvertere tre json-filer til én HTML-fil med en fejloversigt.
Dette script køres som en separat opgave Report, og dens endelige artifact er en HTML-fil med rapporten. Kildeteksten til scriptet findes også i repositoriet og kan tilpasses efter behov, farver osv.
Shell-script
Den anden mulighed er velegnet til situationer, hvor det er nødvendigt at kontrollere Docker-billeder uden for CI/CD-systemet, eller når det er nødvendigt at have alle instruktioner i en udførelsesvenlig form direkte på værten. Denne mulighed dækkes af et klarlagt shell-script, der kan køres på en ren virtuel (eller endda en fysisk) maskine. Scriptet udfører de samme instruktioner som det tidligere nævnte gitlab-runner.
For at scriptet fungerer korrekt, skal Docker være installeret på systemet, og den nuværende bruger skal være i docker-gruppen.
Selve scriptet kan hentes her:
I begyndelsen af filen angives variablerne for hvilket billede, der skal scannes, og hvilke kritikalitetsniveauer for defekter der vil medføre, at Trivy-nyttigudstyret afsluttes med den angivne fejlkode.
Under udførelsen af scriptet vil alle nyttigudstyr blive downloaded til mappen docker_tools, og resultaterne af deres arbejde - til mappen docker_tools/json, mens HTML-rapporten findes i filen results.html.
Eksempel på scriptudgang
~ /docker_cicd $ ./docker_sec_check.sh
[+] Indstiller miljøvariabler
[+] Installerer nødvendige pakker
[+] Forbereder nødvendige mapper
[+] Henter eksempel Dockerfile
2020-10-20 10:40:00 (45.3 MB/s) - 'Dockerfile' gemt [8071/8071]
[+] Henter billede til scanning
seneste: Henter fra bkimminich/juice-shop
[+] Kører Hadolint
...
Dockerfile:205 DL3015 Undgå yderligere pakker ved at angive `--no-install-recommends`
Dockerfile:248 DL3002 Sidste BRUGER bør ikke være root
...
[+] Kører Dockle
...
WARN - DKL-DI-0006: Undgå seneste tag
* Undgå 'seneste' tag
INFO - CIS-DI-0005: Aktivér indholdstillid for Docker
* eksportér DOCKER_CONTENT_TRUST=1 før docker pull/build
...
[+] Kører Trivy
juice-shop/frontend/package-lock.json
=====================================
Total: 3 (UNKNOWN: 0, LOW: 1, MEDIUM: 0, HIGH: 2, CRITICAL: 0)
+---------------------+------------------+----------+---------+-------------------------+
| BIBLIOTEK | VULNERABILITET ID | SVÆRHED | VERSION | TITEL |
+---------------------+------------------+----------+---------+-------------------------+
| object-path | CVE-2020-15256 | HØJ | 0.11.4 | Prototype forurening i |
| | | | | object-path |
+---------------------+------------------+ +---------+-------------------------+
| tree-kill | CVE-2019-15599 | | 1.2.2 | Kodeinjektion |
+---------------------+------------------+----------+---------+-------------------------+
| webpack-subresource | CVE-2020-15262 | LAV | 1.4.1 | Ubeskyttede dynamisk |
| | | | | indlæste chunk |
+---------------------+------------------+----------+---------+-------------------------+
juice-shop/package-lock.json
============================
Total: 20 (UNKNOWN: 0, LOW: 1, MEDIUM: 6, HIGH: 8, CRITICAL: 5)
...
juice-shop/package-lock.json
============================
Total: 5 (CRITICAL: 5)
...
[+] Fjerner rester
[+] Gør outputtet pænt
[+] Konverterer JSON-resultater
[+] Skriver resultater HTML
[+] Ren afslutning ============================================================
[+] Alt er færdigt. Find den resulterende HTML-rapport i results.htmlDocker-image med alle værktøjer
Som et tredje alternativ har jeg lavet to enkle Dockerfile til opbygning af et image med sikkerheds værktøjer. Den ene Dockerfile hjælper med at samle et sæt til billedscanning fra et repository, den anden (Dockerfile_tar) — at samle et sæt til scanning af tar-filer med et billede.
1. Tag den relevante Docker-fil og scripts fra repositoryet .
2. Kør det for at bygge:
docker build -t dscan:image -f docker_security.df .
3. Når bygningen er færdig, opretter vi en container fra billedet. Her videregiver vi miljøvariablen DOCKERIMAGE med navnet på det billede, vi er interesseret i, og monterer Dockerfile, som vi ønsker at analysere, fra vores maskine til filen /Dockerfile (vær opmærksom på, at der kræves en absolut sti til denne fil):
docker run --rm -v $(pwd)\/results:\/results -v $(pwd)\/docker_security.df:\/Dockerfile -e DOCKERIMAGE="bkimminich\/juice-shop" dscan:image
[+] Indstiller miljøvariable
[+] Kører Hadolint
\/Dockerfile:3 DL3006 Tag altid versionen af et image eksplicit
[+] Kører Dockle
WARN - DKL-DI-0006: Undgå den nyeste tag
* Undgå 'latest' tag
INFO - CIS-DI-0005: Aktivér indholdstillid for Docker
* eksportér DOCKER_CONTENT_TRUST=1 før docker pull\/build
INFO - CIS-DI-0006: Tilføj HEALTHCHECK-instruktionen til containerbilledet
* ikke fundet HEALTHCHECK-udsagn
INFO - DKL-LI-0003: Sæt kun nødvendige filer
* unødvendig fil: juice-shop\/node_modules\/sqlite3\/Dockerfile
* unødvendig fil: juice-shop\/node_modules\/sqlite3\/tools\/docker\/architecture\/linux-arm64\/Dockerfile
* unødvendig fil: juice-shop\/node_modules\/sqlite3\/tools\/docker\/architecture\/linux-arm\/Dockerfile
[+] Kører Trivy
...
juice-shop\/package-lock.json
============================
Total: 20 (UNKNOWN: 0, LOW: 1, MEDIUM: 6, HIGH: 8, CRITICAL: 5)
...
[+] Gør outputtet pænt
[+] Starter hovedmodulet ============================================================
[+] Konverterer JSON-resultater
[+] Skriver resultater HTML
[+] Ren exit ============================================================
[+] Alt er færdigt. Find den resulterende HTML-rapport i results.htmlResultater
Vi har kun set på et grundlæggende sæt værktøjer til scanning af Docker artefakter, som efter min mening dækker en god del af kravene til sikkerhed af billeder. Der findes mange flere betalte og gratis værktøjer, der kan udføre de samme kontroller, lave flotte rapporter eller fungere rent i konsoltilstand, dække container management systemer, osv. En oversigt over disse værktøjer og måder at integrere dem på vil måske komme senere.
En positiv side ved værktøjsættet, der beskrives i artiklen, er, at alle er bygget på open source, og du kan eksperimentere med dem og andre lignende værktøjer for at finde præcis, hvad der opfylder dine krav og infrastrukturens karakteristika. Selvfølgelig skal alle sårbarheder, der findes, undersøges for relevans under specifikke forhold, men det er emnet for en fremtidig større artikel.
Jeg håber, at denne vejledning, scripts og værktøjer vil hjælpe dig og blive et udgangspunkt for at skabe en mere sikker infrastruktur inden for containerisering.
Kilde: habr.com
