Еј Хабр!

Во денешната реалност, поради зголемената улога на контејнеризацијата во развојните процеси, прашањето за обезбедување безбедност на различни фази и ентитети поврзани со контејнерите не е на последно место. Рачното извршување на проверките е макотрпна задача, па би било убаво да се преземат барем почетни чекори кон автоматизирање на овој процес.

Во оваа статија, ќе споделам готови скрипти за имплементација на неколку безбедносни алатки на Docker и упатства за тоа како да поставите мал демо штанд за тестирање на овој процес. Можете да ги користите материјалите за да експериментирате како да го организирате процесот на тестирање на безбедноста на сликите и упатствата на Dockerfile. Јасно е дека инфраструктурата за развој и имплементација е различна за секого, па подолу ќе дадам неколку можни опции.

Комунални услуги за проверка на безбедноста

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

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

Прилично едноставна алатка за конзола која помага прво да се процени исправноста и безбедноста на упатствата за Dockerfile (на пример, користејќи само дозволени регистри на слики или користење sudo).

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

Услужна алатка за конзола која работи на слика (или на зачувана слика tarball) која ја проверува исправноста и безбедноста на одредена слика како таква преку анализирање на нејзините слоеви и конфигурација - кои корисници се креирани, кои инструкции се во употреба, кои волумени се монтирани , присуство на празна лозинка, итн. д. Додека бројот на проверки не е многу голем и се заснова на неколку сопствени проверки и препораки ЗНД (Центар за Интернет безбедност) Репер за докер.


Триви
https://github.com/aquasecurity/trivy

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

Опции за имплементација на комунални услуги

За да ги испробам опишаните апликации во изолирани услови, ќе дадам упатства за инсталирање на сите комунални услуги како дел од поедноставен процес.

Главната идеја е да се демонстрира како можете да имплементирате автоматска проверка на содржината за Dockerfiles и Docker сликите што се создаваат за време на развојот.

Самата верификација се состои од следниве чекори:

1. Проверка на исправноста и безбедноста на упатствата на Dockerfile со помошна алатка за линтер Хадолинт
2. Проверка на исправноста и безбедноста на крајните и средните слики - алатка Dockle
3. Проверка за општо познати ранливости (CVE) во основната слика и голем број на зависности - од алатката Триви

Подоцна во статијата ќе дадам три опции за спроведување на овие чекори:
Првиот е со конфигурирање на гасоводот CI / CD користејќи го примерот на GitLab (со опис на процесот на подигање тест пример).
Вториот е користење на скрипта на школка.
Третиот е со изградба на 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 <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: агент кој ќе ги извршува сите потребни операции по барање.
Преземете ја најновата верзија (во овој случај, под Linux 64-битен):

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)

Напомена: Trivy бара инсталирано вртежи во минута и оди. Во спротивно, ќе генерира грешки при скенирање на слики базирани на RedHat и добивање ажурирања на базата на податоци за ранливост.

2. По додавањето на датотеките во складиштето, според упатствата во нашата конфигурациска датотека, GitLab автоматски ќе го започне процесот на градење и скенирање. На картичката CI / CD → Pipelines, можете да го видите напредокот на инструкциите.

Како резултат на тоа, имаме четири задачи. Три од нив се директно вклучени во скенирањето, а последниот (Извештај) собира едноставен извештај од расфрлани датотеки со резултати од скенирање.

Стандардно, Trivy го запира неговото извршување ако се најдат КРИТИЧНИ ранливости на сликата или зависностите. Во исто време, Hadolint секогаш го враќа Success во кодот за извршување, бидејќи неговото извршување секогаш има забелешки, што предизвикува изградбата да престане.

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


Резултатот од работата на секоја алатка може да се види во дневникот на секоја задача за скенирање, директно во json-датотеките во делот за артефакти или во едноставен HTML извештај (повеќе за тоа подолу):


3. За да се претстават извештаите за помошни услуги во малку почитлива форма, се користи мала Python скрипта за конвертирање на три json-датотеки во една HTML-датотека со табела на дефекти.
Оваа скрипта се активира со посебна задача за Извештај, а нејзиниот последен артефакт е HTML-датотека со извештај. Изворот на скриптата е исто така во складиштето и може да се прилагоди на вашите потреби, бои итн.

Скрипта на школка

Втората опција е погодна за случаи кога треба да ги проверите сликите на Docker кои не се во системот CI / CD, или треба да ги имате сите инструкции во форма што може да се изврши директно на домаќинот. Оваа опција е покриена со готова скрипта за школка што може да се изврши на чиста виртуелна (или дури и реална) машина. Скриптата ги следи истите инструкции како 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

Докер слика со сите комунални услуги

Како трета алтернатива, составив две едноставни Dockerfiles за да создадам слика со безбедносни алатки. Еден 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

[+] 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