Hej, Habr!

I den moderna verkligheten, på grund av den ökande rollen av containerisering i utvecklingsprocesserna, är frågan om att säkerställa säkerheten för olika faser och enheter relaterade till containrar av stor vikt. Att genomföra kontroller manuellt är en mödosam uppgift, så det skulle vara bra att ta åtminstone de första stegen mot att automatisera denna process.

I den här artikeln kommer jag att dela färdiga skript för att implementera flera säkerhetsverktyg för Docker och en instruktion för hur man ställer in en liten demo-miljö för att testa denna process. Materialen kan användas för att experimentera med hur man organiserar testprocessen för säkerheten i Docker-bilder och Dockerfile-instruktioner. Det är tydligt att infrastrukturen för utveckling och implementering varierar, så nedan kommer jag att ge några möjliga alternativ.

Säkerhetskontrollverktyg

Det finns ett stort antal olika hjälpprogram och skript som utför kontroller av olika aspekter av Docker-infrastruktur. En del av dem beskrevs i den tidigare artikeln (https://habr.com/ru/company/swordfish_security/blog/518758/#docker-security), och i detta material vill jag fokusera på tre av dem som täcker huvuddelarna av säkerhetskraven för Docker-bilder som byggs under utvecklingsprocessen. Utöver detta kommer jag också att visa ett exempel på hur man kan samla dessa tre verktyg i en pipeline för att utföra säkerhetskontroller.

Hadolint
https://github.com/hadolint/hadolint

Ett ganska enkelt kommandoradsverktyg som hjälper till att initialt bedöma korrektheten och säkerheten i Dockerfile-instruktioner (till exempel att endast använda godkända bildregister eller använda sudo).

Dockle
https://github.com/goodwithtech/dockle

Ett kommandoradsverktyg som arbetar med en bild (eller med en sparad tar-arkiv av bilden), som kontrollerar korrektheten och säkerheten för en specifik bild genom att analysera dess lager och konfiguration – vilka användare som har skapats, vilka instruktioner som används, vilka volymer som är monterade, förekomsten av ett tomt lösenord, etc. Även om antalet kontroller för tillfället inte är stort, är det baserat på några egna kontroller och rekommendationer. CIS (Center for Internet Security) Benchmark för Docker.


Trivy
https://github.com/aquasecurity/trivy

Det här verktyget syftar till att hitta sårbarheter av två typer – problem med operativsystemets byggnationer (stöder Alpine, RedHat (EL), CentOS, Debian GNU, Ubuntu) och problem med beroenden (Gemfile.lock, Pipfile.lock, composer.lock, package-lock.json, yarn.lock, Cargo.lock). Trivy kan skanna både en bild i ett register och en lokal bild, samt genomföra skanning baserat på en överförd .tar-fil med Docker-bilden.

Alternativ för implementering av verktyg

För att prova de beskrivna applikationerna i en isolerad miljö kommer jag att ge instruktioner för installation av alla verktyg inom ramen för en något förenklad process.

Huvudidén är att demonstrera hur man kan implementera automatisk kontroll av innehållet i Dockerfile och Docker-bilder som skapas under utvecklingsprocessen.

Själva kontrollen består av följande steg:

1. Kontroll av korrekthet och säkerhet hos instruktioner i Dockerfile – med verktyget linter Hadolint
2. Kontroll av korrekthet och säkerhet hos slutliga och mellanliggande bilder – med verktyget Dockle
3. Kontroll av kända sårbarheter (CVE) i basbilden och ett antal beroenden – med verktyget Trivy

Därefter i artikeln kommer jag att ge tre alternativ för implementering av dessa steg:
Det första – genom att konfigurera CI/CD-pipeline med ett exempel från GitLab (med beskrivning av processen för att sätta upp en testinstans).
Det andra – med användning av ett shell-skript.
Det tredje – med byggandet av en Docker-bild för att skanna Docker-bilder.
Du kan välja det alternativ som passar dig bäst, överföra det till din infrastruktur och anpassa det efter dina behov.

Alla nödvändiga filer och ytterligare instruktioner finns också i registret: https://github.com/Swordfish-Security/docker_cicd

Integration i GitLab CI/CD

I det första alternativet kommer vi att titta på hur man kan implementera säkerhetskontroller med exemplet på GitLabs paketregister. Här går vi genom stegen och beskriver hur man installerar en testmiljö med GitLab från grunden, sammanställer en skanningsprocess och kör verktygen för att kontrollera test-Dockerfile och en slumpmässig bild – applikationen JuiceShop.

Installation av GitLab
1. Installera Docker:

sudo apt-get update && sudo apt-get install docker.io

2. Lägg till den aktuella användaren i docker-gruppen så att du kan arbeta med Docker utan sudo:

sudo addgroup  docker

3. Ta reda på din IP:

ip addr

4. Installera och starta GitLab i en container, och ersätt 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:latest

Vi väntar på att GitLab ska utföra alla nödvändiga installationsprocedurer (man kan följa processen genom att kolla loggfilen: docker logs -f gitlab).

5. Öppna din lokala IP-adress i webbläsaren och se sidan med förslag att ändra lösenordet för användaren root:

Ange ett nytt lösenord och logga in på GitLab.

6. Skapa ett nytt projekt, till exempel cicd-test, och initiera det med en startfil. README.md:

7. Nu måste vi installera GitLab Runner: agenten som ska starta alla nödvändiga operationer på begäran.
Ladda ner den senaste versionen (i detta fall för Linux 64-bit):

sudo curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64

8. Gör den körbar:

sudo chmod +x /usr/local/bin/gitlab-runner

9. Lägg till en OS-användare för Runner och starta tjänsten:

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 start

Det bör se ungefär ut så här:

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 registrerar vi Runner så att den kan interagera med vår GitLab-instans.
För detta öppnar vi sidan Inställningar-CI/CD (http://OUR_IP_ADDRESS/root/cicd-test/-/settings/ci_cd) och på fliken Runners hittar vi URL och Registration token:

11. Registrera Runner genom att ange URL och Registration token:

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 ett resultat får vi en fungerande GitLab där vi behöver lägga till instruktioner för att starta våra verktyg. I detta demonstrationsfall har vi inga steg för byggandet av applikationen och dess containerisering, men i en verklig miljö kommer dessa att föregå stegen för skanning och skapa bilder och Dockerfile för analys.

Pipelinekonfiguration

1. Låt oss lägga till filer i repot mydockerfile.df (detta är en slags test-Dockerfile som vi kommer att kontrollera) och konfigurationsfilen för GitLab CI/CD processen .gitlab-cicd.yml, som listar instruktionerna för skannrarna (observera punkten i filnamnet).

YAML-konfigurationsfilen innehåller instruktioner för att köra tre verktyg (Hadolint, Dockle och Trivy) som analyserar den valda Dockerfilen och bilden som anges i variabeln DOCKERFILE. Alla nödvändiga filer kan tas från repot: https://github.com/Swordfish-Security/docker_cicd/

Utdrag från mydockerfile.df (detta är en abstrakt fil med en uppsättning godtyckliga instruktioner endast för att demonstrera verktygets funktion). Direktlänk till filen: mydockerfile.df

Innehållet i 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 root

YAML-konfigurationen ser ut på följande sätt (själva filen kan hämtas direkt här: .gitlab-ci.yml):

Innehållet i .gitlab-ci.yml

variabler:
    DOCKER_HOST: "tcp://docker:2375/"
    DOCKERFILE: "mydockerfile.df" # namn på Dockerfile att analysera
    DOCKERIMAGE: "bkimminich/juice-shop" # namn på Dockerbild att analysera
    # DOCKERIMAGE: "knqyf263/cve-2018-11235" # test Dockerbild med flera KRI
    SHOWSTOPPER_PRIORITY: "KRI" # vilken nivå av kritikalitet som får Trivy-jobbet att misslyckas
    TRIVYCACHE: "$CI_PROJECT_DIR/.cache" # var man cacher Trivy-databasen för sårbarheter för snabbare återanvändning
    ARTIFACT_FOLDER: "$CI_PROJECT_DIR"
 
tjänster:
    - docker:dind # för att kunna bygga Dockerbilder inuti Runnern
 
steg:
    - skanna
    - rapportera
    - publicera
 
HadoLint:
    # Grundläggande lintanalys av Dockerfile-instruktioner
    steg: skanna
    bild: docker:git
 
    efter_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 kommer alltid att avsluta med 0 exit-kod
    - ./hadolint-Linux-x86_64 -f json $DOCKERFILE > $ARTIFACT_FOLDER/hadolint_results.json || exit 0
 
    artefakter:
        när: alltid # returnera artefakter även efter jobbmisslyckande
        sökvägar:
        - $ARTIFACT_FOLDER/hadolint_results.json
 
Dockle:
    # Analyserar bästa praxis kring Dockerbild (användarbehörigheter, instruktioner som följdes när bilden byggdes, etc.)
    steg: skanna 
    bild: docker:git
 
    efter_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:
        när: alltid # returnera artefakter även efter jobbmisslyckande
        sökvägar:
        - $ARTIFACT_FOLDER/dockle_results.json
 
Trivy:
    # Analyserar Dockerbild och paketberoenden mot flera CVE-databaser
    steg: skanna 
    bild: docker:git
 
    script:
    # hämtar den senaste 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
     
    # visar alla sårbarheter utan att misslyckas i bygget
    - ./trivy -d --cache-dir $TRIVYCACHE -f json -o $ARTIFACT_FOLDER/trivy_results.json --exit-code 0 $DOCKERIMAGE    
    
    # skriver sårbarhetsinformation till stdout i ett läsbart format (att läsa ren json är inte kul, eller hur?). Du kan ta bort detta om du inte behöver det.
    - ./trivy -d --cache-dir $TRIVYCACHE --exit-code 0 $DOCKERIMAGE    
 
    # misslyckas bygget om SHOWSTOPPER-prioritet hittas
    - ./trivy -d --cache-dir $TRIVYCACHE --exit-code 1 --severity $SHOWSTOPPER_PRIORITY --quiet $DOCKERIMAGE
         
    artefakter:
        när: alltid # returnera artefakter även efter jobbmisslyckande
        sökvägar:
        - $ARTIFACT_FOLDER/trivy_results.json
 
    cache:
        sökvägar:
        - .cache
 
Rapport:
    # kombinerar verktygens utdata till en HTML
    steg: rapportera
    när: alltid
    bild: 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:
        sökvägar:
        - results.html

Om det behövs kan man också skanna och spara bilder som .tar-arkiv (men det kommer att kräva att ingångsparametrarna ändras i YAML-filen för verktygen)

Obs: Trivy kräver installerade rpm och git. Annars kommer det att ge fel vid skanning av RedHat-baserade bilder och vid hämtning av uppdateringar för sårbarhetsdatabasen.

2. Efter att filerna har lagts till i repositoryt, kommer GitLab automatiskt att påbörja bygg- och skanningsprocessen enligt instruktionerna i vår konfigurationsfil. Under fliken CI/CD → Pipelines kan man se hur instruktionerna genomförs.

Som ett resultat har vi fyra uppgifter. Tre av dem fokuserar på själva skanningen och den sista (Report) sammanställer en enkel rapport från de olika filerna med skanningsresultat.

Som standard stoppar Trivy sin körning om det upptäcker CRITICAL sårbarheter i bilden eller dess beroenden. Samtidigt ger Hadolint alltid en Success-kod som resultat, eftersom det alltid finns anmärkningar, vilket leder till att byggprocessen stoppas.

Beroende på specifika krav kan man konfigurera exitkoden så att dessa verktyg stoppar byggprocessen vid upptäckta problem av viss kritikalitet. I vårt fall stannar byggprocessen bara om Trivy upptäcker en sårbarhet med den kritikalitet som vi angav i variabeln SHOWSTOPPER i .gitlab-ci.yml.


Resultatet av varje verktags körning kan ses i loggen för varje skanningsuppgift, antingen i json-filerna under artifacts eller i en enkel HTML-rapport (mera om det snart):


3. För att presentera rapporterna från verktygen i en något mer läsbar form används ett litet Python-skript för att konvertera tre json-filer till en HTML-fil med en felstabell.
Detta skript körs som en separat Report-uppgift, och dess slutliga artefakt är en HTML-fil med rapporten. Källkoden till skriptet finns också i repositoryt och kan anpassas efter egna behov, färger etc.

Shell-skript

Det andra alternativet är lämpligt för situationer där det är nödvändigt att kontrollera Docker-bilder utanför CI/CD-systemet eller där alla instruktioner behöver vara i ett format som kan köras direkt på värden. Detta alternativ täcks av ett färdigt shell-skript som kan köras på en ren virtuell (eller till och med fysisk) maskin. Skriptet kör samma instruktioner som det ovan nämnda gitlab-runner.

För att skriptet ska fungera korrekt måste Docker vara installerat i systemet och den aktuella användaren måste vara i docker-gruppen.

Själva skriptet kan hämtas här: docker_sec_check.sh

I början av filen anges med variabler vilken bild som ska skannas och vilka typer av sårbarheter som kommer att orsaka att Trivy lämnar med den angivna felkoden.

Under skriptets körning kommer alla verktyg att laddas ner till katalogen docker_tools, resultaten från deras arbete — till katalogen docker_tools/json, och HTML-rapporten kommer att ligga i filen results.html.

Exempel på skriptutdata

~\/docker_cicd$ .\/docker_sec_check.sh

[+] Sätter miljövariabler
[+] Installerar nödvändiga paket
[+] Förbereder nödvändiga kataloger
[+] Hämtar exempel Dockerfile
2020-10-20 10:40:00 (45.3 MB/s) - ‘Dockerfile’ sparad [8071/8071]
[+] Hämtar bild för skanning
latest: Hämtar från bkimminich/juice-shop
[+] Kör Hadolint
...
Dockerfile:205 DL3015 Undvik extra paket med `--no-install-recommends`
Dockerfile:248 DL3002 Sista användare ska inte vara root
...
[+] Kör Dockle
...
WARN    - DKL-DI-0006: Undvik latest-tag
        * Undvik 'latest' tag
INFO    - CIS-DI-0005: Aktivera innehållsutbyte för Docker
        * export DOCKER_CONTENT_TRUST=1 innan docker pull/build
...
[+] Kör Trivy
juice-shop/frontend/package-lock.json
=====================================
Totalt: 3 (UNKNOWN: 0, LOW: 1, MEDIUM: 0, HIGH: 2, CRITICAL: 0)

+---------------------+------------------+----------+---------+-------------------------+
|       BIBLIOTEK     | SÄKERHETS-ID      | SVARIGHET| VERSION |             TITEL       |
+---------------------+------------------+----------+---------+-------------------------+
| object-path         | CVE-2020-15256   | HÖG      | 0.11.4  | Prototypförorening i   |
|                     |                  |          |         | object-path             |
+---------------------+------------------+          +---------+-------------------------+
| tree-kill           | CVE-2019-15599   |          | 1.2.2   | Kodinjektion          |
+---------------------+------------------+----------+---------+-------------------------+
| webpack-subresource | CVE-2020-15262   | LÅG      | 1.4.1   | Oskyddade dynamiskt    |
|                     |                  |          |         | laddade chunks         |
+---------------------+------------------+----------+---------+-------------------------+

juice-shop/package-lock.json
============================
Totalt: 20 (UNKNOWN: 0, LOW: 1, MEDIUM: 6, HIGH: 8, CRITICAL: 5)

...

juice-shop/package-lock.json
============================
Totalt: 5 (CRITICAL: 5)

...
[+] Tar bort överblivna filer
[+] Gör utdata snygg
[+] Konverterar JSON-resultat
[+] Skriver resultat HTML
[+] Ren avslutning ============================================================
[+] Allt är klart. Hitta den resulterande HTML-rapporten i results.html

Docker-image med alla verktyg

Som ett tredje alternativ har jag skapat två enkla Dockerfile för att skapa en bild med säkerhetsverktyg. Den första Dockerfile hjälper till att bygga ett kit för att skanna bild från ett förråd, den andra (Dockerfile_tar) - att bygga ett kit för att skanna en tar-fil med bilden.

1. Ta motsvarande Docker-fil och skripten från förrådet https://github.com/Swordfish-Security/docker_cicd/tree/master/Dockerfile.
2. Kör den för att bygga:

docker build -t dscan:image -f docker_security.df .

3. Efter byggandet skapar vi en container från bilden. Under tiden skickar vi miljövariabeln DOCKERIMAGE med namnet på den bild vi är intresserade av och monterar Dockerfile som vi vill analysera från vår maskin på filen /Dockerfile (observera att absolut sökväg till denna fil krävs):

docker run --rm -v $(pwd)/results:/results -v $(pwd)/docker_security.df:/Dockerfile -e DOCKERIMAGE="bkimminich/juice-shop" dscan:image

[+] Ställer in miljövariabler
[+] Kör Hadolint
/Dockerfile:3 DL3006 Märk alltid versionen av en bild explicit
[+] Kör Dockle
WARN - DKL-DI-0006: Undvik senaste taggen
 * Undvik 'latest' tagg
INFO - CIS-DI-0005: Aktivera innehållsförtroende för Docker
 * export DOCKER_CONTENT_TRUST=1 innan docker pull/build
INFO - CIS-DI-0006: Lägg till HEALTHCHECK-instruktion i containerbilden
 * hittades inte HEALTHCHECK-sats
INFO - DKL-LI-0003: Sätt bara nödvändiga filer
 * onödig fil : juice-shop/node_modules/sqlite3/Dockerfile
 * onödig fil : juice-shop/node_modules/sqlite3/tools/docker/architecture/linux-arm64/Dockerfile
 * onödig fil : juice-shop/node_modules/sqlite3/tools/docker/architecture/linux-arm/Dockerfile
[+] Kör Trivy
...
juice-shop/package-lock.json
============================
Totalt: 20 (UNKNOWN: 0, LOW: 1, MEDIUM: 6, HIGH: 8, CRITICAL: 5)
...
[+] Gör utdata vackrare
[+] Startar huvudmodulen ============================================================
[+] Konverterar JSON-resultat
[+] Skriver resultat HTML
[+] Ren avslutning ============================================================
[+] Allt är klart. Hitta den resulterande HTML-rapporten i results.html

Resultat

Vi har bara täckt ett grundläggande kit av verktyg för att skanna Docker-artifakter, som jag tycker effektivt täcker en ganska stor del av säkerhetskraven för bilder. Det finns många fler betalda och gratis verktyg som kan utföra samma kontroller, skapa vackra rapporter eller fungera helt i kommandoradsläge, täcka containerhanteringssystem osv. En översikt över dessa verktyg och sätt att integrera dem kan komma senare.

En positiv aspekt av verktygssatsen som beskrivs i artikeln är att alla bygger på öppen källkod, vilket gör att du kan experimentera med dem och andra liknande verktyg för att hitta vad som passar dina krav och infrastrukturen. Självklart bör alla sårbarheter som upptäcks undersökas för tillämplighet i specifika omständigheter, men det är ett ämne för en framtida stor artikel.

Jag hoppas att denna instruktion, skript och verktyg hjälper dig och blir en utgångspunkt för att skapa en säkrare infrastruktur inom containerisering.

Källa: habr.com