Здравей, Хабр!

В съвременната реалност, поради увеличаващата се роля на контейнеризацията в процесите на разработка, важен е въпросът за осигуряването на безопасността на различните етапи и елементи, свързани với контейнерите. Провеждането на проверки ръчно е трудоемка задача, затова е добре да се направят поне първоначални стъпки към автоматизация на този процес.

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

Инструменти за проверка на безопасността

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

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

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

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

Конзолна утилита, работеща с образа (или със запазен tar архив на образа), която проверява коректността и безопасността на конкретен образ, анализирайки неговите слоеве и конфигурация – какви потребители са създадени, какви инструкции се използват, какви томове са свързани, наличието на празна парола и т.н. В момента броят на проверките не е много голям и е базиран на няколко собствени проверки и препоръки. CIS (Център за интернет сигурност) Benchmark за Docker.


Trivy
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 образ.

Варианти за внедряване на утилити

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

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

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

1. Проверка на правилността и сигурността на инструкциите в Dockerfile с помощта на линтер утилита Hadolint
2. Проверка на правилността и сигурността на крайния и междинните образи с помощта на утилита Dockle
3. Проверка за наличието на обществено известни уязвимости (CVE) в основния образ и редица зависимости с помощта на утилита Trivy

По-надолу в статията ще представя три варианта за внедряване на тези стъпки:
Първият – чрез конфигуриране на CI/CD pipeline на примера на 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. Добавете текущия потребител в групата docker, за да можете да работите с Docker без sudo:

sudo addgroup  docker

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

ip addr

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

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: агент, който ще изпълнява необходимите операции при поискване.
Изтегляме последната версия (в този случай — за 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. Правим го изпълним:

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 и Registration token:

11. Регистрираме Runner, подставяйки URL и 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"

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

Конфигурация на pipeline

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 <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 изглежда по следния начин (самият файл може да бъде взет по пряка връзка тук: .gitlab-ci.yml):

Съдържание на .gitlab-ci.yml

променливи:
    DOCKER_HOST: "tcp://docker:2375/"
    DOCKERFILE: "mydockerfile.df" # име на Dockerfile за анализ
    DOCKERIMAGE: "bkimminich/juice-shop" # име на Docker изображение за анализ
    # DOCKERIMAGE: "knqyf263/cve-2018-11235" # тестово Docker изображение със сериозни CVE
    SHOWSTOPPER_PRIORITY: "КРИТИЧЕН" # какво ниво на критичност ще провали задачата на Trivy
    TRIVYCACHE: "$CI_PROJECT_DIR/.cache" # къде да кешираме Trivy базата данни за уязвимости за по-бързо повторно използване
    ARTIFACT_FOLDER: "$CI_PROJECT_DIR"

услуги:
    - docker:dind # за да можем да изграждаме docker изображения вътре в Runner

етапи:
    - сканиране
    - отчет
    - публикуване

HadoLint:
    # Основен анализ на инструкции в Dockerfile
    етап: сканиране
    изображение: docker:git

    след_скрипт:
    - cat $ARTIFACT_FOLDER/hadolint_results.json

    скрипт:
    - 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 винаги ще излезе с код на изход 0
    - ./hadolint-Linux-x86_64 -f json $DOCKERFILE > $ARTIFACT_FOLDER/hadolint_results.json || exit 0

    артефакти:
        когато: винаги # върнете артефакти дори след провал на задачата
        пътища:
        - $ARTIFACT_FOLDER/hadolint_results.json

Dockle:
    # Анализ на добри практики за Docker изображение (права на потребителите, инструкции следвани при изграждане на изображението и т.н.)
    етап: сканиране
    изображение: docker:git

    след_скрипт:
    - cat $ARTIFACT_FOLDER/dockle_results.json

    скрипт:
    - 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

    артефакти:
        когато: винаги # върнете артефакти дори след провал на задачата
        пътища:
        - $ARTIFACT_FOLDER/dockle_results.json

Trivy:
    # Анализ на Docker изображение и пакетни зависимости спрямо множество CVE бази
    етап: сканиране
    изображение: docker:git

    скрипт:
    # получаване на най-новия 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

    # показване на всички уязвимости без провал на изграждането
    - ./trivy -d --cache-dir $TRIVYCACHE -f json -o $ARTIFACT_FOLDER/trivy_results.json --exit-code 0 $DOCKERIMAGE

    # записване на информация за уязвимостите в стандартния изход в четим формат (четенето на чист json не е забавно, нали?). Можете да премахнете това, ако не ви е необходимо.
    - ./trivy -d --cache-dir $TRIVYCACHE --exit-code 0 $DOCKERIMAGE

    # провал на изграждането, ако се намери приоритет SHOWSTOPPER
    - ./trivy -d --cache-dir $TRIVYCACHE --exit-code 1 --severity $SHOWSTOPPER_PRIORITY --quiet $DOCKERIMAGE

    артефакти:
        когато: винаги # върнете артефакти дори след провал на задачата
        пътища:
        - $ARTIFACT_FOLDER/trivy_results.json

    кеш:
        пътища:
        - .cache

Отчет:
    # обединяване на изходите на инструментите в един HTML
    етап: отчет
    когато: винаги
    изображение: python:3.5

    скрипт:
    - 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

    артефакти:
        пътища:
        - results.html

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

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

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

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

По подразбиране Trivy спира изпълнението си, ако бъдат открити CRITICAL уязвимости в образа или зависимостите. В същото време Hadolint винаги връща код Success при изпълнение, тъй като след неговото изпълнение винаги има бележки, което води до спиране на изграждането.

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


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


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

Shell-скрипт

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

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

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

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

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

Примерен изход от скрипта

~\/docker_cicd$ .\/docker_sec_check.sh

[+] Настройване на променливи на средата
[+] Инсталиране на необходимите пакети
[+] Подготвяне на необходимите директории
[+] Изтегляне на пример Dockerfile
2020-10-20 10:40:00 (45.3 MB/s) - ‘Dockerfile’ спестен [8071/8071]
[+] Изтегляне на изображение за сканиране
latest: Изтегляне от bkimminich\/juice-shop
[+] Изпълнение на Hadolint
...
Dockerfile:205 DL3015 Избягвайте допълнителни пакети, като укажете `--no-install-recommends`
Dockerfile:248 DL3002 Последният USER не трябва да е root
...
[+] Изпълнение на Dockle
...
WARN    - DKL-DI-0006: Избягвайте последния таг
        * Избягвайте 'latest' тага
INFO    - CIS-DI-0005: Активирайте доверие в съдържанието за Docker
        * export DOCKER_CONTENT_TRUST=1 преди docker pull/build
...
[+] Изпълнение на Trivy
juice-shop\/frontend\/package-lock.json
=====================================
Общо: 3 (UNKNOWN: 0, LOW: 1, MEDIUM: 0, HIGH: 2, CRITICAL: 0)

+---------------------+------------------+----------+---------+-------------------------+
|       БИБЛИОТЕКА     | ID на Уязвимост   | СЕРИОЗНОСТ | ВЕРСИЯ |             НАЗВАНИЕ   |
+---------------------+------------------+----------+---------+-------------------------+
| object-path         | CVE-2020-15256   | ВИСОКА   | 0.11.4  | Замърсяване на прототипи |
|                     |                  |          |         | object-path             |
+---------------------+------------------+          +---------+-------------------------+
| tree-kill           | CVE-2019-15599   |          | 1.2.2   | Инжекция на код        |
+---------------------+------------------+----------+---------+-------------------------+
| webpack-subresource | CVE-2020-15262   | НИСКА    | 1.4.1   | Не защитени динамично  |
|                     |                  |          |         | заредени части         |
+---------------------+------------------+----------+---------+-------------------------+

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

...

juice-shop\/package-lock.json
============================
Общо: 5 (CRITICAL: 5)

...
[+] Премахване на остатъци
[+] Подреждане на изхода
[+] Преобразуване на JSON резултати
[+] Записване на резултати в HTML
[+] Чисто излизане ============================================================
[+] Всичко е готово. Намерете резултатния HTML отчет в results.html

Docker изображение с утилитами

Като трета алтернатива съставих два прости Dockerfile за създаване на изображение с инструменти за сигурност. Единият 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, който искаме да анализираме, от нашата машина на файла /Dockerfile (обърнете внимание, че е необходим абсолютен път до този файл):

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

[+] Настройване на променливи за среда
[+] Изпълнение на Hadolint
\/Dockerfile:3 DL3006 Винаги маркирайте версията на изображение явно
[+] Изпълнение на Dockle
WARN    - DKL-DI-0006: Избягвайте най-новата марка
        * Избягвайте 'latest' марка
INFO    - CIS-DI-0005: Включете доверие в съдържанието за Docker
        * експортирайте DOCKER_CONTENT_TRUST=1 преди docker pull\/build
INFO    - CIS-DI-0006: Добавете HEALTHCHECK инструкция към изображението на контейнера
        * не намерена инструкция HEALTHCHECK
INFO    - DKL-LI-0003: Поставяйте само необходими файлове
        * ненужен файл : juice-shop\/node_modules\/sqlite3\/Dockerfile
        * ненужен файл : juice-shop\/node_modules\/sqlite3\/tools\/docker\/architecture\/linux-arm64\/Dockerfile
        * ненужен файл : juice-shop\/node_modules\/sqlite3\/tools\/docker\/architecture\/linux-arm\/Dockerfile
[+] Изпълнение на Trivy
...\njuice-shop\/package-lock.json
============================
Общo: 20 (UNKNOWN: 0, LOW: 1, MEDIUM: 6, HIGH: 8, CRITICAL: 5)
...
[+] Правим изхода да изглежда хубаво
[+] Стартиране на основния модул ============================================================
[+] Конвертиране на JSON резултати
[+] Записване на резултати HTML
[+] Чисто излизане ============================================================
[+] Всичко е готово. Намерете получения HTML доклад в results.html

Резултати

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

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

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

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