おい、ハブル！

現代の現実では、開発プロセスにおけるコンテナ化の役割が増大しているため、コンテナに関連するさまざまなステージやエンティティのセキュリティを確保するという問題は、決して重要な問題ではありません。 手動チェックの実行には時間がかかるため、少なくともこのプロセスを自動化するための最初の手順を実行することをお勧めします。

この記事では、いくつかの Docker セキュリティ ユーティリティを実装するための既製のスクリプトと、このプロセスをテストするための小さなデモ スタンドを展開する方法について説明します。 これらのマテリアルを使用して、Dockerfile イメージと手順のセキュリティをテストするプロセスを編成する方法を実験できます。 開発と実装のインフラストラクチャが人によって異なることは明らかなので、以下に考えられるオプションをいくつか示します。

セキュリティチェックユーティリティ

Docker インフラストラクチャのさまざまな側面のチェックを実行するさまざまなヘルパー アプリケーションやスクリプトが多数あります。 それらのいくつかはすでに前の記事で説明されています (https://habr.com/ru/company/swordfish_security/blog/518758/#docker-securityこの資料では、そのうちの XNUMX つに焦点を当てたいと思います。これらは、開発プロセス中に構築された Docker イメージのセキュリティ要件の大部分をカバーしています。 さらに、これら XNUMX つのユーティリティを XNUMX つのパイプラインに接続してセキュリティ チェックを実行する方法の例も示します。

ハドリント
https://github.com/hadolint/hadolint

最初の近似として、Dockerfile 命令の正確さと安全性を評価するのに役立つ、非常に単純なコンソール ユーティリティ (たとえば、承認されたイメージ レジストリのみを使用するか、sudo を使用するかなど)。

ドックル
https://github.com/goodwithtech/dockle

イメージ (またはイメージの保存された tar アーカイブ) を操作するコンソール ユーティリティ。特定のイメージ自体の正確性とセキュリティをチェックし、そのレイヤーと構成 (どのユーザーが作成され、どの命令が使用され、どのようなものであるか) を分析します。 d. これまでのところ、チェックの数はそれほど多くなく、いくつかの独自のチェックと推奨事項に基づいています。 CIS (インターネット セキュリティ センター) ベンチマーク ドッカー用。


雑学
https://github.com/aquasecurity/trivy

このユーティリティは、OS ビルドの問題 (Alpine、RedHat (EL)、CentOS、Debian GNU、Ubuntu でサポート) と依存関係の問題 (Gemfile.lock、Pipfile.lock、composer.lock、package) の XNUMX 種類の脆弱性を検出することを目的としています。 -lock.json、yarn.lock、cargo.lock)。 Trivy は、リポジトリ内のイメージとローカル イメージの両方をスキャンでき、Docker イメージで転送された .tar ファイルに基づいてスキャンすることもできます。

ユーティリティを実装するためのオプション

説明されているアプリケーションを隔離された環境で試すために、やや簡略化したプロセスですべてのユーティリティをインストールする手順を示します。

主なアイデアは、開発中に作成される Dockerfile と Docker イメージの自動コンテンツ検証を実装する方法を示すことです。

チェック自体は次の手順で構成されます。

1. リンター ユーティリティを使用した Dockerfile 命令の正確さと安全性のチェック ハドリント
2. ユーティリティを使用して最終イメージと中間イメージの正確性と安全性をチェックする ドックル
3. 基本イメージ内の公知の脆弱性 (CVE) と多数の依存関係の存在を確認する - ユーティリティを使用する 雑学

この記事の後半では、これらの手順を実装するための XNUMX つのオプションについて説明します。
XNUMX つ目は、例として GitLab を使用して CI/CD パイプラインを構成します (テスト インスタンスを生成するプロセスの説明付き)。
XNUMX つ目はシェルスクリプトを使用する方法です。
XNUMX 番目の方法には、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 を使用せずに docker を操作できるように、現在のユーザーを docker グループに追加します。

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 の OS ユーザーを追加し、サービスを開始します。

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 インスタンスと対話できるようにします。
これを行うには、設定 - CI/CD ページ (http://OUR_IP_ADDRESS/root/cicd-test/-/settings/ci_cd) を開き、[ランナー] タブで URL と登録トークンを見つけます。

11. 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 構成ファイルには、選択した Dockerfile と DOCKERFILE 変数で指定されたイメージを分析する XNUMX つのユーティリティ (Hadolint、Dockle、Trivy) を実行するための命令が含まれています。 必要なファイルはすべてリポジトリから取得できます。 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 をインストールする必要があります rpm и git。 そうしないと、RedHat ベースのイメージをスキャンし、脆弱性データベースの更新を受信するときにエラーが生成されます。

2. 設定ファイルの指示に従ってリポジトリにファイルを追加すると、GitLab は自動的にビルドとスキャンのプロセスを開始します。 [CI/CD] → [パイプライン] タブで、指示の進行状況を確認できます。

その結果、タスクは XNUMX つあります。 そのうちの XNUMX つはスキャンを直接処理し、最後のもの (レポート) は散在するファイルからスキャン結果を含む単純なレポートを収集します。

デフォルトでは、イメージまたは依存関係に重大な脆弱性が検出された場合、Trivy は実行を停止します。 同時に、Hadolint は常に成功コードを返します。これは、常にコメントが生成され、ビルドが停止するためです。

特定の要件に応じて、これらのユーティリティが特定の重大度の問題を検出したときにビルド プロセスも停止するように終了コードを構成できます。 この場合、ビルドは、Trivy が SHOWSTOPPER 変数で指定した重大度の脆弱性を検出した場合にのみ停止します。 .gitlab-ci.yml.


各ユーティリティの結果は、各スキャン タスクのログ、アーティファクト セクションの json ファイルで直接、または単純な HTML レポートで表示できます (詳細は以下を参照)。


3. ユーティリティ レポートをもう少し人間が読みやすい形式で表示するには、小さな Python スクリプトを使用して、XNUMX つの JSON ファイルを、欠陥のテーブルを含む XNUMX つの HTML ファイルに変換します。
このスクリプトは別のレポート タスクによって起動され、その最終成果物はレポートを含む HTML ファイルです。 スクリプト ソースもリポジトリにあり、ニーズや色などに合わせて調整できます。

シェルスクリプト

XNUMX 番目のオプションは、CI/CD システムの外部で Docker イメージをチェックする必要がある場合、またはホスト上で直接実行できる形式ですべての命令を用意する必要がある場合に適しています。 このオプションは、クリーンな仮想 (または実際の) マシン上で実行できる既製のシェル スクリプトでカバーされています。 このスクリプトは、上で説明した 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 イメージ

XNUMX 番目の代替案として、XNUMX つの単純な Dockerfile をコンパイルして、セキュリティ ユーティリティを備えたイメージを作成しました。 XNUMX つの Dockerfile はリポジトリからイメージをスキャンするためのセットの構築に役立ち、XNUMX つ目 (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 アーティファクトをスキャンするためのユーティリティの基本セットを XNUMX つだけ検討しました。私の意見では、これはイメージのセキュリティ要件のかなりの部分を非常に効果的にカバーしています。 同じチェックを実行したり、美しいレポートを作成したり、純粋にコンソール モードで動作したり、コンテナ管理システムをカバーしたりできる、有料および無料のツールも多数あります。これらのツールの概要とそれらの統合方法については、少し後になる可能性があります。 。

この記事で説明されているツール セットの良い点は、それらがすべてオープン ソース コードに基づいて構築されており、これらのツールや他の同様のツールを試して、要件やインフラストラクチャ機能に合ったものを見つけることができることです。 もちろん、見つかったすべての脆弱性は、特定の状況での適用可能性を調査する必要がありますが、これは将来の大規模な記事のトピックです。

このガイド、スクリプト、ユーティリティが役に立ち、コンテナ化の分野でより安全なインフラストラクチャを作成するための出発点となることを願っています。

出所： habr.com