Хей Хабр!

В днешната реалност, поради нарастващата роля на контейнеризацията в процесите на разработка, въпросът за осигуряване на сигурността на различни етапи и обекти, свързани с контейнерите, не е на последно място. Извършването на проверки ръчно е трудоемка задача, така че би било хубаво да предприемете поне началните стъпки към автоматизирането на този процес.

В тази статия ще споделя готови скриптове за внедряване на няколко помощни програми за защита на Docker и инструкции как да настроите малък демонстрационен стенд, за да тествате този процес. Можете да използвате материалите, за да експериментирате как да организирате процеса на тестване на сигурността на изображения и инструкции на Dockerfile. Ясно е, че инфраструктурата за разработка и внедряване е различна за всеки, така че по-долу ще дам няколко възможни варианта.

Помощни програми за проверка на сигурността

Има голям брой различни помощни приложения и скриптове, които извършват проверки на различни аспекти на инфраструктурата на Docker. Някои от тях вече са описани в предишна статия (https://habr.com/ru/company/swordfish_security/blog/518758/#docker-security), и в тази статия бих искал да се съсредоточа върху три от тях, които покриват по-голямата част от изискванията за сигурност за Docker изображения, които се създават по време на процеса на разработка. Освен това ще покажа пример за това как тези три помощни програми могат да бъдат комбинирани в един конвейер за извършване на проверки за сигурност.

Хадолинт
https://github.com/hadolint/hadolint

Доста проста конзолна помощна програма, която помага в първо приближение да се оцени коректността и безопасността на инструкциите на Dockerfile (например използване само на разрешени регистри на изображения или използване на sudo).

Докъл
https://github.com/goodwithtech/dockle

Конзолна помощна програма, която работи върху изображение (или запаметен tarball на изображение), което проверява коректността и сигурността на конкретно изображение като такова чрез анализиране на неговите слоеве и конфигурация - какви потребители са създадени, какви инструкции се използват, какви томове са монтирани , наличие на празна парола и др. д. Въпреки че броят на проверките не е много голям и се основава на няколко собствени проверки и препоръки CIS (Център за интернет сигурност) Бенчмарк за докер.


Дребнав
https://github.com/aquasecurity/trivy

Тази помощна програма е насочена към намиране на два типа уязвимости - проблеми с изграждането на ОС (поддържат се Alpine, RedHat (EL), CentOS, Debian GNU, Ubuntu) и проблеми със зависимости (Gemfile.lock, Pipfile.lock, composer.lock, package-lock .json, yarn.lock, Cargo.lock). Trivy може да сканира както изображението в хранилището, така и локалното изображение, а също и да сканира въз основа на прехвърления .tar файл с изображението на Docker.

Опции за внедряване на помощни програми

За да изпробвам описаните приложения в изолирани условия, ще предоставя инструкции за инсталиране на всички помощни програми като част от опростен процес.

Основната идея е да демонстрирате как можете да приложите автоматична проверка на съдържанието за Dockerfiles и Docker изображения, които са създадени по време на разработката.

Самата проверка се състои от следните стъпки:

1. Проверка на правилността и безопасността на инструкциите на Dockerfile с помощна програма за linter Хадолинт
2. Проверка на коректността и сигурността на крайните и междинните изображения - помощна програма Докъл
3. Проверка за общоизвестни уязвимости (CVE) в базовото изображение и редица зависимости - от помощната програма Дребнав

По-късно в статията ще дам три варианта за изпълнение на тези стъпки:
Първият е чрез конфигуриране на CI / CD тръбопровода, използвайки примера на GitLab (с описание на процеса на повдигане на тестова инстанция).
Вторият е използването на shell скрипт.
Третият е със създаването на Docker изображение за сканиране на Docker изображения.
Можете да изберете опцията, която ви подхожда най-добре, да я прехвърлите във вашата инфраструктура и да я адаптирате към вашите нужди.

Всички необходими файлове и допълнителни инструкции също са в хранилището: https://github.com/Swordfish-Security/docker_cicd

GitLab CI/CD интеграция

В първия вариант ще разгледаме как проверките за сигурност могат да бъдат приложени с помощта на системата за хранилища GitLab като пример. Тук ще преминем през стъпките и ще видим как да настроим тестова среда с GitLab от нулата, да създадем процес на сканиране и да стартираме помощни програми за тестване на тестов Dockerfile и произволно изображение - приложението JuiceShop.

Инсталиране на GitLab
1. Инсталирайте Docker:

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

2. Добавете текущия потребител към докер групата, така че да можете да работите с докер, без да използвате sudo:

sudo addgroup <username> docker

3. Намерете своя IP:

ip addr

4. Инсталирайте и стартирайте GitLab в контейнера, като замените IP адреса в името на хоста с вашия собствен:

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

Чакаме GitLab да завърши всички необходими инсталационни процедури (можете да проследите процеса чрез изхода на лог файла: docker logs -f gitlab).

5. Отворете вашия локален IP в браузъра и вижте страница, предлагаща промяна на паролата за root потребител:

Задайте нова парола и отидете на GitLab.

6. Създайте нов проект, например cicd-test и го инициализирайте със стартов файл README.md:

7. Сега трябва да инсталираме GitLab Runner: агент, който ще изпълнява всички необходими операции при поискване.
Изтеглете най-новата версия (в този случай под 64-битов Linux):

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

8. Направете го изпълним:

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

9. Добавете потребител на ОС за Runner и стартирайте услугата:

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

Трябва да изглежда нещо подобно:

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. Сега регистрираме Runner, така че да може да взаимодейства с нашия екземпляр на GitLab.
За да направите това, отворете страницата Settings-CI/CD (http://OUR_IP_ADDRESS/root/cicd-test/-/settings/ci_cd) и в раздела Runners намерете URL адреса и токена за регистрация:

11. Регистрирайте Runner, като замените URL адреса и маркера за регистрация:

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"

В резултат на това получаваме готов работещ GitLab, в който трябва да добавим инструкции за стартиране на нашите помощни програми. В тази демонстрация нямаме стъпки за изграждане и контейнеризиране на приложения, но в реална среда те ще предхождат стъпките за сканиране и ще генерират изображения и Dockerfile за анализ.

конфигурация на тръбопровода

1. Добавете файлове към хранилището mydockerfile.df (това е тестов Dockerfile, който ще тестваме) и конфигурационния файл на GitLab CI/CD процес .gitlab-cicd.yml, който изброява инструкции за скенери (обърнете внимание на точката в името на файла).

Конфигурационният файл .yaml съдържа инструкции за стартиране на три помощни програми (Hadolint, Dockle и Trivy), които ще анализират избрания Dockerfile и изображението, указано в променливата DOCKERFILE. Всички необходими файлове могат да бъдат взети от хранилището: https://github.com/Swordfish-Security/docker_cicd/

Откъс от mydockerfile.df (това е абстрактен файл с набор от произволни инструкции, само за да демонстрира как работи помощната програма). Директен линк към файла: mydockerfile.df

Съдържание на 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 root

Конфигурацията YAML изглежда така (самият файл може да бъде взет от директната връзка тук: .gitlab-ci.yml):

Съдържание на .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.html

Ако е необходимо, можете също да сканирате запазени изображения като .tar архив (обаче ще трябва да промените входните параметри за помощните програми в YAML файла)

NB: Trivy изисква инсталиран оборота в минута и Git. В противен случай ще генерира грешки при сканиране на базирани на RedHat изображения и получаване на актуализации в базата данни за уязвимости.

2. След добавяне на файловете към хранилището, съгласно инструкциите в нашия конфигурационен файл, GitLab автоматично ще стартира процеса на изграждане и сканиране. В раздела CI / CD → Тръбопроводи можете да видите напредъка на инструкциите.

В резултат на това имаме четири задачи. Три от тях участват пряко в сканирането, а последният (Отчет) събира прост отчет от разпръснати файлове с резултати от сканиране.

По подразбиране Trivy спира изпълнението си, ако се открият КРИТИЧНИ уязвимости в изображението или зависимостите. В същото време Hadolint винаги връща успех в кода за изпълнение, тъй като изпълнението му винаги има забележки, което води до спиране на изграждането.

В зависимост от вашите специфични изисквания, можете да конфигурирате код за изход, така че тези помощни програми също да спрат процеса на изграждане, когато бъдат открити проблеми с определена критичност. В нашия случай изграждането ще спре само ако Trivy открие уязвимост със степен на сериозност, която сме посочили в променливата SHOWSTOPPER в .gitlab-ci.yml.


Резултатът от работата на всяка помощна програма може да се види в дневника на всяка задача за сканиране, директно в json файлове в секцията с артефакти или в обикновен HTML отчет (повече за това по-долу):


3. За представяне на отчетите за помощни програми в малко по-разбираема за хората форма се използва малък скрипт на Python за конвертиране на три json файла в един HTML файл с таблица с дефекти.
Този скрипт се стартира от отделна задача за отчет и последният му артефакт е HTML файл с отчет. Източникът на скрипта също е в хранилището и може да бъде адаптиран към вашите нужди, цветове и т.н.

Shell скрипт

Втората опция е подходяща за случаи, когато трябва да проверите изображения на Docker извън системата CI / CD или трябва да имате всички инструкции във форма, която може да се изпълни директно на хоста. Тази опция е покрита от готов shell скрипт, който може да се изпълнява на чиста виртуална (или дори реална) машина. Скриптът следва същите инструкции като gitlab-runner по-горе.

За да работи скриптът успешно, Docker трябва да е инсталиран в системата и текущият потребител трябва да е в групата на docker.

Самият скрипт можете да намерите тук: docker_sec_check.sh

В началото на файла променливите указват кое изображение трябва да бъде сканирано и каква сериозност на дефектите ще накарат помощната програма Trivy да излезе с посочения код за грешка.

По време на изпълнението на скрипта всички помощни програми ще бъдат изтеглени в директорията docker_tools, резултатите от работата им - в справочника docker_tools/json, а HTML с отчета ще бъде във файла резултати.html.

Примерен резултат от скрипта

~/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.html

Docker изображение с всички помощни програми

Като трета алтернатива, компилирах два прости Docker файла, за да създам изображение с помощни програми за сигурност. Един Dockerfile ще помогне за изграждането на набор за сканиране на изображението от хранилището, вторият (Dockerfile_tar) ще изгради набор за сканиране на tar файла с изображението.

1. Взимаме подходящия Docker файл и скриптове от хранилището https://github.com/Swordfish-Security/docker_cicd/tree/master/Dockerfile.
2. Пуснете го за сглобяване:

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

3. След като изграждането приключи, създайте контейнер от изображението. В същото време предаваме променливата на средата DOCKERIMAGE с името на изображението, което ни интересува, и монтираме Dockerfile, който искаме да анализираме от нашата машина към файла /докер файл (имайте предвид, че е необходим абсолютен път до този файл):

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.html

резултати

Покрихме само един основен набор от помощни програми за сканиране на артефакти на Docker, които според мен покрива доста ефективно доста изисквания за сигурност на изображенията. Има много други платени и безплатни инструменти, които могат да извършват същите проверки, да изготвят красиви отчети или да работят само в конзолен режим, да обхващат системи за управление на контейнери и т.н. Преглед на тези инструменти и как да ги интегрирате може да се появи малко по-късно.

Положителната страна на набора от инструменти, описани в статията, е, че всички те са изградени върху отворен код и можете да експериментирате с тях и други подобни инструменти, за да намерите какво точно отговаря на вашите изисквания и характеристики на инфраструктурата. Разбира се, всички открити уязвимости трябва да бъдат проучени за приложимост в конкретни условия, но това е тема за бъдеща голяма статия.

Надявам се, че тези инструкции, скриптове и помощни програми ще ви помогнат и ще станат отправна точка за създаване на по-сигурна инфраструктура в областта на контейнеризацията.

Източник: www.habr.com