Hej Habra!
We współczesnej rzeczywistości, w związku z rosnącą rolą konteneryzacji w procesach deweloperskich, kwestia zapewnienia bezpieczeństwa poszczególnych etapów i podmiotów związanych z kontenerami nie jest sprawą najmniej istotną. Przeprowadzanie ręcznych kontroli jest czasochłonne, dlatego warto podjąć chociaż pierwsze kroki w kierunku automatyzacji tego procesu.
W tym artykule udostępnię gotowe skrypty do wdrożenia kilku narzędzi zabezpieczających Dockera oraz instrukcje, jak wdrożyć małe stanowisko demonstracyjne w celu przetestowania tego procesu. Możesz skorzystać z materiałów, aby poeksperymentować z organizacją procesu testowania bezpieczeństwa obrazów i instrukcji Dockerfile. Oczywiste jest, że infrastruktura programistyczna i wdrożeniowa każdego jest inna, dlatego poniżej przedstawię kilka możliwych opcji.
Narzędzia kontroli bezpieczeństwa
Istnieje wiele różnych aplikacji pomocniczych i skryptów, które sprawdzają różne aspekty infrastruktury Dockera. Niektóre z nich zostały już opisane w poprzednim artykule (), a w tym materiale chciałbym się skupić na trzech z nich, które obejmują większość wymagań bezpieczeństwa dla obrazów Dockera tworzonych w procesie programowania. Ponadto pokażę również przykład połączenia tych trzech mediów w jeden rurociąg w celu przeprowadzenia kontroli bezpieczeństwa.
Hadolint
Dość proste narzędzie konsolowe, które pomaga w pierwszym przybliżeniu ocenić poprawność i bezpieczeństwo instrukcji Dockerfile (na przykład przy użyciu wyłącznie autoryzowanych rejestrów obrazów lub przy użyciu sudo).
Dok
Narzędzie konsolowe pracujące z obrazem (lub zapisanym archiwum tar obrazu), które sprawdza poprawność i bezpieczeństwo konkretnego obrazu jako takiego, analizując jego warstwy i konfigurację – jacy użytkownicy są tworzeni, jakie instrukcje są używane, jakie zamontowane są woluminy, obecność pustego hasła itp. d. Jak dotąd liczba kontroli nie jest zbyt duża i opiera się na kilku naszych własnych kontrolach i zaleceniach dla Dockera.
Ciekawostki
Celem tego narzędzia jest znalezienie dwóch typów luk - problemów z kompilacjami systemów operacyjnych (obsługiwanych przez Alpine, RedHat (EL), CentOS, Debian GNU, Ubuntu) oraz problemów z zależnościami (Gemfile.lock, Pipfile.lock, Composer.lock, package -lock.json , przędza.lock, cargo.lock). Trivy może skanować zarówno obraz w repozytorium, jak i obraz lokalny, a także może skanować na podstawie przesłanego pliku .tar z obrazem Dockera.
Opcje wdrażania narzędzi
Aby wypróbować opisane aplikacje w izolowanym środowisku, udostępnię instrukcje dotyczące instalowania wszystkich narzędzi w nieco uproszczonym procesie.
Główną ideą jest pokazanie, w jaki sposób można zaimplementować automatyczną weryfikację zawartości plików Dockerfile i obrazów Docker tworzonych podczas programowania.
Samo sprawdzenie składa się z następujących kroków:
- Sprawdzenie poprawności i bezpieczeństwa instrukcji Dockerfile za pomocą narzędzia linter Hadolint
- Sprawdzanie poprawności i bezpieczeństwa obrazów końcowych i pośrednich za pomocą narzędzia Dok
- Sprawdzanie obecności publicznie znanych luk (CVE) w obrazie bazowym i szeregu zależności - za pomocą narzędzia Ciekawostki
W dalszej części artykułu podam trzy opcje wdrożenia tych kroków:
Pierwszy polega na skonfigurowaniu potoku CI/CD na przykładzie GitLaba (z opisem procesu wywoływania instancji testowej).
Drugie polega na użyciu skryptu powłoki.
Trzeci polega na zbudowaniu obrazu Dockera w celu skanowania obrazów Dockera.
Możesz wybrać opcję, która najbardziej Ci odpowiada, przenieść ją na swoją infrastrukturę i dostosować do swoich potrzeb.
Wszystkie niezbędne pliki i dodatkowe instrukcje znajdują się również w repozytorium:
Integracja z GitLab CI/CD
W pierwszej opcji przyjrzymy się, jak można wdrożyć kontrole bezpieczeństwa na przykładzie systemu repozytorium GitLab. Tutaj przejdziemy przez kolejne kroki i dowiemy się, jak od podstaw zainstalować środowisko testowe z GitLabem, stworzyć proces skanowania i uruchomić narzędzia do sprawdzania testowego pliku Dockerfile i losowego obrazu - aplikacji JuiceShop.
Instalowanie GitLaba
1. Zainstaluj Dockera:
sudo apt-get update && sudo apt-get install docker.io2. Dodaj bieżącego użytkownika do grupy doków, aby móc pracować z dokiem bez korzystania z sudo:
sudo addgroup <username> docker3. Znajdź swój adres IP:
ip addr4. Zainstaluj i uruchom GitLab w kontenerze, zastępując adres IP w nazwie hosta własnym:
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:latestCzekamy, aż GitLab zakończy wszystkie niezbędne procedury instalacyjne (możesz monitorować proces poprzez wynik pliku dziennika: docker logs -f gitlab).
5. Otwórz swój lokalny adres IP w przeglądarce i zobacz stronę z prośbą o zmianę hasła dla użytkownika root:
Ustaw nowe hasło i przejdź do GitLab.
6. Utwórz nowy projekt, np. cicd-test i zainicjuj go plikiem startowym README.md:
7. Teraz musimy zainstalować GitLab Runner: agenta, który na żądanie wykona wszystkie niezbędne operacje.
Pobierz najnowszą wersję (w tym przypadku dla systemu 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. Ustaw go jako wykonywalny:
sudo chmod +x /usr/local/bin/gitlab-runner9. Dodaj użytkownika systemu operacyjnego dla Runnera i uruchom usługę:
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 startPowinno to wyglądać mniej więcej tak:
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. Teraz rejestrujemy Runnera, aby mógł on wchodzić w interakcję z naszą instancją GitLab.
Aby to zrobić, otwórz stronę Ustawienia-CI/CD (http://OUR_IP_ADDRESS/root/cicd-test/-/settings/ci_cd) i w zakładce Biegacze znajdź adres URL i token rejestracji:
11. Zarejestruj Biegacza podając adres URL i token Rejestracji:
sudo gitlab-runner register
--non-interactive
--url "http://<URL>/"
--registration-token "<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"W rezultacie otrzymujemy gotowy działający GitLab, do którego musimy dodać instrukcje, aby uruchomić nasze narzędzia. W tej wersji demonstracyjnej nie mamy instrukcji tworzenia aplikacji i konteneryzacji jej, ale w rzeczywistym środowisku poprzedzałyby one etapy skanowania i generowałyby obrazy oraz plik Dockerfile do analizy.
konfiguracja rurociągu
1. Dodaj pliki do repozytorium mydockerfile.df (jest to testowy plik Dockerfile, który sprawdzimy) i plik konfiguracyjny procesu GitLab CI/CD .gitlab-cicd.yml, który zawiera instrukcje dotyczące skanerów (zwróć uwagę na kropkę w nazwie pliku).
Plik konfiguracyjny YAML zawiera instrukcje umożliwiające uruchomienie trzech narzędzi (Hadolint, Dockle i Trivy), które przeanalizują wybrany plik Dockerfile i obraz określony w zmiennej DOCKERFILE. Wszystkie niezbędne pliki można pobrać z repozytorium:
Fragment mydockerfile.df (jest to plik abstrakcyjny zawierający zestaw dowolnych instrukcji służących wyłącznie do zademonstrowania działania narzędzia). Bezpośredni link do pliku:
Zawartość pliku 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 <[email protected]>"
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 rootKonfiguracja YAML wygląda następująco (sam plik można znaleźć poprzez bezpośredni link tutaj: ):
Zawartość .gitlab-ci.yml
variables:
DOCKER_HOST: "tcp://docker:2375/"
DOCKERFILE: "mydockerfile.df" # name of the Dockerfile to analyse
DOCKERIMAGE: "bkimminich/juice-shop" # name of the Docker image to analyse
# DOCKERIMAGE: "knqyf263/cve-2018-11235" # test Docker image with several CRITICAL CVE
SHOWSTOPPER_PRIORITY: "CRITICAL" # what level of criticality will fail Trivy job
TRIVYCACHE: "$CI_PROJECT_DIR/.cache" # where to cache Trivy database of vulnerabilities for faster reuse
ARTIFACT_FOLDER: "$CI_PROJECT_DIR"
services:
- docker:dind # to be able to build docker images inside the Runner
stages:
- scan
- report
- publish
HadoLint:
# Basic lint analysis of Dockerfile instructions
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 will always exit with 0 exit code
- ./hadolint-Linux-x86_64 -f json $DOCKERFILE > $ARTIFACT_FOLDER/hadolint_results.json || exit 0
artifacts:
when: always # return artifacts even after job failure
paths:
- $ARTIFACT_FOLDER/hadolint_results.json
Dockle:
# Analysing best practices about docker image (users permissions, instructions followed when image was built, etc.)
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
artifacts:
when: always # return artifacts even after job failure
paths:
- $ARTIFACT_FOLDER/dockle_results.json
Trivy:
# Analysing docker image and package dependencies against several CVE bases
stage: scan
image: docker:git
script:
# getting the latest 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
# displaying all vulnerabilities w/o failing the build
- ./trivy -d --cache-dir $TRIVYCACHE -f json -o $ARTIFACT_FOLDER/trivy_results.json --exit-code 0 $DOCKERIMAGE
# write vulnerabilities info to stdout in human readable format (reading pure json is not fun, eh?). You can remove this if you don't need this.
- ./trivy -d --cache-dir $TRIVYCACHE --exit-code 0 $DOCKERIMAGE
# failing the build if the SHOWSTOPPER priority is found
- ./trivy -d --cache-dir $TRIVYCACHE --exit-code 1 --severity $SHOWSTOPPER_PRIORITY --quiet $DOCKERIMAGE
artifacts:
when: always # return artifacts even after job failure
paths:
- $ARTIFACT_FOLDER/trivy_results.json
cache:
paths:
- .cache
Report:
# combining tools outputs into one 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
artifacts:
paths:
- results.htmlW razie potrzeby możesz także zeskanować zapisane obrazy w formie archiwum .tar (konieczna będzie jednak zmiana parametrów wejściowych narzędzi w pliku YAML)
Uwaga: Trivy wymaga zainstalowania rpm и odrzutowiec. W przeciwnym razie będzie generować błędy podczas skanowania obrazów opartych na RedHat i odbierania aktualizacji do bazy danych luk.
2. Po dodaniu plików do repozytorium, zgodnie z instrukcją zawartą w naszym pliku konfiguracyjnym, GitLab automatycznie rozpocznie proces budowania i skanowania. W zakładce CI/CD → Pipelines możesz zobaczyć postęp realizacji instrukcji.
W rezultacie mamy cztery zadania. Trzy z nich zajmują się bezpośrednio skanowaniem, a ostatni (Raport) zbiera prosty raport z rozproszonych plików z wynikami skanowania.
Domyślnie Trivy przestaje działać, jeśli w obrazie lub zależnościach zostaną wykryte KRYTYCZNE luki. Jednocześnie Hadolint zawsze zwraca kod sukcesu, ponieważ zawsze skutkuje to komentarzami, co powoduje zatrzymanie kompilacji.
W zależności od konkretnych wymagań można skonfigurować kod zakończenia w taki sposób, aby w przypadku wykrycia przez te narzędzia problemów o określonej krytyczności zatrzymały także proces kompilacji. W naszym przypadku kompilacja zostanie zatrzymana tylko wtedy, gdy Trivy wykryje lukę o krytyczności, którą określiliśmy w zmiennej SHOWSTOPPER w .gitlab-ci.yml.
Wynik działania każdego narzędzia można wyświetlić w dzienniku każdego zadania skanowania, bezpośrednio w plikach json w sekcji artefaktów lub w prostym raporcie HTML (więcej na ten temat poniżej):
3. Aby przedstawić raporty narzędzi w formie nieco bardziej czytelnej dla człowieka, używany jest mały skrypt w języku Python do konwersji trzech plików JSON na jeden plik HTML z tabelą defektów.
Skrypt ten jest uruchamiany przez osobne zadanie Raport, a jego końcowym artefaktem jest plik HTML z raportem. Źródło skryptu znajduje się również w repozytorium i można je dostosować do własnych potrzeb, kolorów itp.
Skrypt powłoki
Druga opcja jest odpowiednia w przypadkach, gdy musisz sprawdzić obrazy Dockera poza systemem CI/CD lub potrzebujesz mieć wszystkie instrukcje w formie, którą można wykonać bezpośrednio na hoście. Tę opcję obsługuje gotowy skrypt powłoki, który można uruchomić na czystej maszynie wirtualnej (lub nawet rzeczywistej). Skrypt wykonuje te same instrukcje, co opisany powyżej gitlab-runner.
Aby skrypt mógł działać pomyślnie, w systemie musi być zainstalowany Docker, a bieżący użytkownik musi należeć do grupy Docker.
Sam skrypt można znaleźć tutaj:
Na początku pliku zmienne określają, który obraz wymaga przeskanowania i które defekty krytyczne spowodują zamknięcie narzędzia Trivy z określonym kodem błędu.
Podczas wykonywania skryptu wszystkie narzędzia zostaną pobrane do katalogu docker_tools, wyniki ich pracy znajdują się w katalogu docker_tools/json, a kod HTML z raportem będzie w pliku wyniki.html.
Przykładowe wyjście skryptu
~/docker_cicd$ ./docker_sec_check.sh
[+] Setting environment variables
[+] Installing required packages
[+] Preparing necessary directories
[+] Fetching sample Dockerfile
2020-10-20 10:40:00 (45.3 MB/s) - ‘Dockerfile’ saved [8071/8071]
[+] Pulling image to scan
latest: Pulling from bkimminich/juice-shop
[+] Running Hadolint
...
Dockerfile:205 DL3015 Avoid additional packages by specifying `--no-install-recommends`
Dockerfile:248 DL3002 Last USER should not be root
...
[+] Running Dockle
...
WARN - DKL-DI-0006: Avoid latest tag
* Avoid 'latest' tag
INFO - CIS-DI-0005: Enable Content trust for Docker
* export DOCKER_CONTENT_TRUST=1 before docker pull/build
...
[+] Running Trivy
juice-shop/frontend/package-lock.json
=====================================
Total: 3 (UNKNOWN: 0, LOW: 1, MEDIUM: 0, HIGH: 2, CRITICAL: 0)
+---------------------+------------------+----------+---------+-------------------------+
| LIBRARY | VULNERABILITY ID | SEVERITY | VERSION | TITLE |
+---------------------+------------------+----------+---------+-------------------------+
| object-path | CVE-2020-15256 | HIGH | 0.11.4 | Prototype pollution in |
| | | | | object-path |
+---------------------+------------------+ +---------+-------------------------+
| tree-kill | CVE-2019-15599 | | 1.2.2 | Code Injection |
+---------------------+------------------+----------+---------+-------------------------+
| webpack-subresource | CVE-2020-15262 | LOW | 1.4.1 | Unprotected dynamically |
| | | | | loaded chunks |
+---------------------+------------------+----------+---------+-------------------------+
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)
...
[+] Removing left-overs
[+] Making the output look pretty
[+] Converting JSON results
[+] Writing results HTML
[+] Clean exit ============================================================
[+] Everything is done. Find the resulting HTML report in results.htmlObraz Dockera ze wszystkimi narzędziami
Jako trzecią alternatywę skompilowałem dwa proste pliki Dockerfile, aby utworzyć obraz z narzędziami zabezpieczającymi. Jeden Dockerfile pomoże zbudować zestaw do skanowania obrazu z repozytorium, drugi (Dockerfile_tar) pomoże zbudować zestaw do skanowania pliku tar z obrazem.
1. Pobierz odpowiedni plik Dockera i skrypty z repozytorium .
2. Uruchamiamy go do montażu:
docker build -t dscan:image -f docker_security.df .
3. Po zakończeniu montażu tworzymy pojemnik z obrazu. Jednocześnie przekazujemy zmienną środowiskową DOCKERIMAGE z nazwą interesującego nas obrazu i montujemy do pliku Dockerfile, który chcemy przeanalizować z naszej maszyny /plikDockera (pamiętaj, że wymagana jest bezwzględna ścieżka do tego pliku):
docker run --rm -v $(pwd)/results:/results -v $(pwd)/docker_security.df:/Dockerfile -e DOCKERIMAGE="bkimminich/juice-shop" dscan:image
[+] Setting environment variables
[+] Running Hadolint
/Dockerfile:3 DL3006 Always tag the version of an image explicitly
[+] Running Dockle
WARN - DKL-DI-0006: Avoid latest tag
* Avoid 'latest' tag
INFO - CIS-DI-0005: Enable Content trust for Docker
* export DOCKER_CONTENT_TRUST=1 before docker pull/build
INFO - CIS-DI-0006: Add HEALTHCHECK instruction to the container image
* not found HEALTHCHECK statement
INFO - DKL-LI-0003: Only put necessary files
* unnecessary file : juice-shop/node_modules/sqlite3/Dockerfile
* unnecessary file : juice-shop/node_modules/sqlite3/tools/docker/architecture/linux-arm64/Dockerfile
* unnecessary file : juice-shop/node_modules/sqlite3/tools/docker/architecture/linux-arm/Dockerfile
[+] Running Trivy
...
juice-shop/package-lock.json
============================
Total: 20 (UNKNOWN: 0, LOW: 1, MEDIUM: 6, HIGH: 8, CRITICAL: 5)
...
[+] Making the output look pretty
[+] Starting the main module ============================================================
[+] Converting JSON results
[+] Writing results HTML
[+] Clean exit ============================================================
[+] Everything is done. Find the resulting HTML report in results.htmlwyniki
Przyjrzeliśmy się tylko jednemu podstawowemu zestawowi narzędzi do skanowania artefaktów Dockera, który moim zdaniem bardzo skutecznie spełnia przyzwoitą część wymagań bezpieczeństwa obrazu. Istnieje również duża liczba płatnych i bezpłatnych narzędzi, które mogą przeprowadzać te same kontrole, rysować piękne raporty lub pracować wyłącznie w trybie konsoli, pokrywać systemy zarządzania kontenerami itp. Przegląd tych narzędzi i sposobów ich integracji może pojawić się nieco później .
Zaletą zestawu narzędzi opisanych w tym artykule jest to, że wszystkie są open source i możesz eksperymentować z nimi i innymi podobnymi narzędziami, aby znaleźć to, co odpowiada Twoim potrzebom i infrastrukturze. Oczywiście wszystkie znalezione luki należy zbadać pod kątem zastosowania w określonych warunkach, ale jest to temat na przyszły duży artykuł.
Mam nadzieję, że ten przewodnik, skrypty i narzędzia pomogą Ci i staną się punktem wyjścia do stworzenia bezpieczniejszej infrastruktury w obszarze konteneryzacji.
Źródło: www.habr.com