👇🏾 💹 🗄️ Docker Container Securityの強化 👩🏿‍🤝‍👩🏼 📴 👩🏽‍🤝‍👨🏼

「先生、どうやってハッキングされたの？」

-方法ではなく、コンテナ内。

古いジョーク

コンピューターシステムの不要なコンポーネントはすべて、完全にオプションの脆弱性の原因となる可能性があります。したがって、コンテナイメージには、可能な限りアプリケーションが必要とするもののみを含める必要があります。そして、そのサイズは、配布の容易さだけでなく、所有コストとセキュリティの点でも重要です。この記事では、Dockerイメージのサイズと攻撃対象領域を最小化する方法と、脆弱性をスキャンするツールについて説明します。

Dockerを使用したことがある人なら、おそらく高山のイメージを聞いたことがあるでしょう。これは、 Alpine Linuxディストリビューションに基づいて作成されました。たとえば、ベースイメージサイズが5 MBのDebianやUbuntuと比較すると、攻撃者に攻撃の余地がほとんどありません。アプリケーションが高山で動作できる場合、これは最適化するのに最適な方法です。

バイナリファイルはどうですか？アプリケーションは自律的に機能しますか？もしそうなら、サイズの追加の縮小を期待する理由があります。 DebianやUbuntuのようなイメージのベースとして、通常はscratch

が使用されますが、golangアプリケーションを機能させることもできます。 Gianluca Arbezzanoは、最小サイズの既製のバイナリを含むリポジトリを作成しました。 linux_386を試してみましょう。

 curl -SsL https://github.com/gianarb/micro/releases/download/1.0.0/micro_1.0.0_linux_386 > micro

このDockerfileを使用して、このバイナリファイルをスクラッチイメージに含めることができます。

 FROM scratch ADD ./micro /micro EXPOSE 8000 CMD ["/micro"]

 docker build -t micro-scratch . docker run -p 8000:8000 micro-scratch

その結果、わずか5 MBのイメージでhttp-applicationを起動することができました。つまり、高山に基づいて作成されたイメージが占有する12 MBに比べて2倍以上削減しました。

どのアプリケーションでもスクラッチ画像を使用することはできませんが、オーバーヘッドを削減する価値はあります。

Rubyでは、ベースとしてruby：2.3-alpineを使用できます。その中のRubyは、Alpineパッケージからではなく、ソースからインストールされます。セマンティックバージョニングに従って、リリース2.3は開発者から直接セキュリティアップデートを受け取ります。

それ以外の場合は、ソースからRubyを自分でインストールして新しいバージョンのリリースを追跡するか、Alpineのパッケージを使用して、ディストリビューション開発者による更新を監視する必要があります。

通知とWebフック

ベースイメージに対してセキュリティ更新プログラムが発行された場合、それに基づいたイメージを更新する必要があります。 MicroScalingのスタッフが公式の高山とルビーの画像に対して行うように、たとえばSlackに送信できるMicroBadger通知がここで役立ちます。

また、ベースイメージが変更された場合に、アラートを使用してビルド/リアセンブリ手順を自動的に開始します。 Docker Hubにはそのような機能がありますが、MicroBallgerはWebフックをサポートするシステム（CIやセキュリティスキャナーなど）で使用できるため、MicroBadgerの方が優れていると主張しています。

一般ユーザー

仮想マシンとコンテナの主な違いの1つは、コアシステムの最新の使用です。デフォルトでは、Dockerコンテナはルート権限で実行されます。これは、ルートの下で実行されている侵害されたコンテナがメインシステムへのルートアクセスを取得できるため、分離が壊れた場合に深刻な問題につながる可能性があります。

ただし、コンテナを通常のユーザーとして実行することにより、リスクを軽減できます。 Railsアプリケーションでこれを行う方法は次のとおりです。

 #    WORKDIR /app #   Rails-   COPY . ./ #   ,      RUN addgroup rails && adduser -D -G rails rails \ && chown -R rails:rails /app USER rails

セキュリティスキャン

直接のストレージに加えて、コンテナレジストリは、そこにロードされたイメージの脆弱性をスキャンできます。たとえば、DockerはDocker Cloudにアップロードされた公式画像とユーザー画像のセキュリティをスキャンします。

Quay.ioは、CoreOSのオープンソース製品であるClairを使用して、画像セキュリティをスキャンします。最近では、AlpineのサポートがClairに追加されました。これは実際には非常にクールです。この機能がQuayですぐに利用できることを期待しましょう。 Clairに加えて、 TwistLockおよびAquaスキャナーがありますが、ほとんどの場合、それらの使用に対して料金を支払う必要があります。

Clairは、画像をアップロード、ダウンロード、および分析するためのHTTP APIのセットを実装するGolangアプリケーションです。脆弱性データは、 Debian Security TrackerやRedHat Security Dataなどのさまざまなソースからダウンロードされ、Postgresに保存されます。 Clairは静的アナライザーの原理で動作するため、コンテナーをスキャンするためにコンテナーを実行する必要はありません。イメージファイルシステムのみがチェックされます。

 docker run -it -p 5000:5000 registry

このコマンドを使用して、独自のレジストリを起動し、スキャン用の画像のソースとして使用しました。 Gianluca Arbezzanoからmicro

画像を読み込んでみましょう：

 docker pull gianarb/micro:1.0.0 docker tag gianarb/micro:1.0.0 localhost:5000/gianarb/micro:1.0.0 docker push localhost:5000/gianarb/micro:1.0.0

次に、Clairをインストールします。

 mkdir $HOME/clair-test/clair_config cd $HOME/clair-test curl -L https://raw.githubusercontent.com/coreos/clair/v1.2.2/config.example.yaml -o clair_config/config.yaml curl -L https://raw.githubusercontent.com/coreos/clair/v1.2.2/docker-compose.yml -o docker-compose.yml

データベースに接続するための設定を$HOME/clair_config/config.yml

しますpostgresql://postgres:password@postgres:5432?sslmode=disable

Postgres and Clairを起動するには、次のコマンドを実行します。

 docker-compose up

テスト手順を容易にするために、Hyperclairと呼ばれるCLIを使用します（これはClairと連携するためのクライアントです）。 Mac OSのコマンドは次のとおりです（別のOSを使用している場合は、 https ： //github.com/wemanity-belgium/hyperclair/releasesを参照してください）。

 curl -SSl https://github.com/wemanity-belgium/hyperclair/releases/download/0.5.2/hyperclair-darwin-386 > ~/hyperclair chmod 755 ~/hyperclair

〜/ hyperclairに実行可能ファイルができました：

 ~/hyperclair pull localhost:5000/gianarb/micro:1.0.0 ~/hyperclair push localhost:5000/gianarb/micro:1.0.0 ~/hyperclair analyze localhost:5000/gianarb/micro:1.0.0 ~/hyperclair report localhost:5000/gianarb/micro:1.0.0

生成されるレポートは次のようになります。

Railsアプリケーションの潜在的に脆弱なビルド依存関係の削除

Rubyはインタープリター言語であるため、Rubyで作成されたアプリケーションを使用する場合、かなりの量の依存関係があります。アプリケーションに必要なすべてのRuby gem、およびこれらのgemに必要なすべてのオペレーティングシステムパッケージをインストールする必要があります。

スキャンによってlibxml2およびlibxsltの重大な脆弱性が特定されたとします。これらは、XMLおよびJSONパーサーであるNokogiri gemのビルド時の依存関係です。パフォーマンスを向上させるために、このgemはコンパイルが必要なCで書かれた拡張機能を使用します。ただし、gemのインストール後、libxml2とlibxsltは不要になりました。

すべてのビルド時の依存関係を削除しましょう。

 #     WORKDIR /tmp ADD Gemfile* /tmp/ #       #         apk- RUN apk update && apk upgrade && \ apk add --no-cache $RUBY_PACKAGES && \ apk add --no-cache --virtual build-deps $BUILD_PACKAGES && \ bundle install --jobs 20 --retry 5 && \ apk del build-deps

GemfileとGemfile.lockを/ tmpにキャッシュすることにより、Gemfileが変更された場合にのみ、 bundle install

コマンドが実行されます。それ以外の場合、Dockerキャッシュが使用されます。このような最適化により、実行時間とネットワーク負荷を削減できます。これは、gemのインストール時に非常に大きくなる可能性があります。

run

コマンドは複数行であるため、画像には1つのレイヤーのみが追加されることに注意してください。アセンブリに必要なパッケージは--virtualスイッチを使用してインストールされ、プロセスの完了後に簡単に削除できます。

自動組立

コンテナの安全性の観点から、イメージ自体またはそのベースにあるイメージの更新が表示されるたびに、コンテナを再構築することが非常に重要です。この手順の自動化は、gitリポジトリへのバインドに基づいて行うことができます。この場合、監視対象ブランチで新しいコミットを作成した後にアセンブリが開始されます。前述のように、アセンブリはベースイメージイベントの変更によってもトリガーできます。

Rubyの場合、作成プロセスで使用したのと同じDockerfileを使用できるため、状況は単純化されます。 Goのプログラムでは、最初にバイナリファイルをコンパイルしてから、イメージに追加する必要があります。これには、ローカルでmakefileを使用できます。

別の方法は、Dockerコンテナでイベントごとにバイナリファイルをコンパイルすることです。 CenturyLinkLabsとPrometheusのgolang-builderイメージをいくつか見ることをお勧めします。

ビルドプロセスを開始するには、ビルドフックを使用できます。これは、イメージに動的メタデータを追加する場合にも便利です。

おわりに

そこで、GoおよびRubyアプリケーションのDockerイメージを最小化する方法を簡単に検討し、通常のユーザーとしてコンテナーを実行する方法を学び、Clairを使用してセキュリティスキャンを設定し、自動再構築について少し話しました。これらの簡単な手順がDockerコンテナのセキュリティを向上させることを願っています。今のところすべてです。ご清聴ありがとうございました！

ソースのリスト：

Docker Container Securityの強化