Dockerは開発と展開のサイクルを高速化するため、非常に短時間で既製のコードを配信できます。 しかし、このコインには欠点があります-セキュリティ。 Dockerによってセキュリティが影響を受ける多くの事項について知る価値があり、この記事で説明するのはそれらについてです。 Dockerにデプロイされたイメージが、あなたが考慮していないかもしれない新しいセキュリティ問題の原因となる5つの典型的な状況を見ていきます。 また、これらの問題を解決するためのクールなツールを検討し、展開時にすべてのハッチが閉じていることを確認するために使用できるアドバイスを提供します。
1.画像の信頼性
問題から始めましょう。これは、おそらくDocker自体の性質の不可欠な部分であり、イメージの信頼性です。
Dockerを使用したことがある場合は、NGINX、Redis、Ubuntu、Alpine Linuxなど、サポートされているリポジトリの公式リストの画像など、ほぼすべての画像にコンテナーを配置できることに注意してください。および他の。
その結果、私たちには膨大な選択肢があります。
1つのコンテナですべての問題が解決しない場合は、別のコンテナに交換できます。 しかし、そのようなアプローチは最も安全ですか？
あなたが私に同意しない場合、別の観点からこの問題を見てみましょう。
アプリケーションを開発するとき、パッケージマネージャーを使用すると、他の誰かのコードを簡単に使用できますが、開発中にその恐ろしいコードを使用する価値はありますか？ または、分析していないコードを健全なレベルの疑いで処理する必要がありますか？ セキュリティがあなたにとって何かを意味するのであれば、あなたの代わりに、コードをアプリケーションに統合する前に常に注意深くチェックします。
私は正しいですか
まあ、同じ疑いで、Dockerコンテナを考慮する必要があります。
コードの作成者がわからない場合、選択したコンテナに他の悪意のあるコードのバイナリが含まれていないことをどのようにして確認できますか？
確かに、ここには確実性はありません。
これらの条件下で、3つのヒントを提供できます。
プライベートまたは信頼できるリポジトリを使用する
まず、 信頼できるDocker Hubリポジトリなど、プライベートまたは信頼できるリポジトリを使用できます 。
公式リポジトリには次の画像があります。
- オペレーティングシステム（Ubuntuなど）
- プログラミング言語（PHPおよびRuby）
- サーバー（MySQL、PostgreSQL、Redis）
とりわけDocker Hubを他のリポジトリと区別するのは、画像が常にDockerのセキュリティスキャンサービスによってスキャンおよび表示されることです。
このサービスについて聞いたことがない場合は、そのドキュメントからの引用を以下に示します。
Docker CloudおよびDocker Hubは、プライベートリポジトリ内の画像をスキャンして、既知の脆弱性がないことを確認できます。 その後、各画像タグのスキャン結果に関するレポートを送信します。
その結果、公式リポジトリを使用すると、コンテナが安全であり、悪意のあるコードが含まれていないことがわかります。
このオプションは、すべての有料関税で利用できます。 無料の料金で、それもありますが、時間制限があります。 すでに有料の関税を使用している場合は、スキャン機能を使用して、カスタムコンテナーの安全性と、コンテナーに不明な脆弱性があるかどうかを確認できます。
これにより、プライベートリポジトリを作成し、組織内で使用できます。
Docker Content Trustを使用する
使用する価値のあるもう1つのツールは、 Docker Content Trustです。
これはDocker Engine 1.8で利用可能な新機能です。 画像の所有者を確認できます。
DockerのセキュリティスペシャリストであるDiogoMónicaによる新しいリリースに関する記事からの引用：
作成者がリモートレジストリに画像を公開する前に、Docker Engineは作成者の秘密キーでこの画像に署名します。 この画像を自分にアップロードすると、Docker Engineは公開キーを使用して、この画像が作成者が投稿したものであり、偽物ではなく、すべての最新の更新があることを確認します。
まとめると。 このサービスは、偽造、リプレイ攻撃、およびキーの侵害からユーザーを保護します。 この記事と公式ドキュメントを読むことを強くお勧めします。
Dockerベンチセキュリティ
最近使用した別のツールはDocker Bench Securityです。 これは、運用環境でのコンテナの展開に関する推奨事項の大規模な選択です。
このツールは、 CIS Docker 1.13 Benchmarkの推奨事項に基づいており、6つの分野で使用されています。
- ホスト構成
- Dockerデーモンの構成。
- Dockerデーモン構成ファイル。
- コンテナイメージとビルドファイル。
- ランタイムコンテナ。
- Dockerセキュリティ操作。
それをインストールするには、次を使用してリポジトリをクローン
git clone git@github.com:docker/docker-bench-security.git
次に、 cd docker-bench-secutity
と入力して、次のコマンドを実行します。
docker run -it --net host --pid host --cap-add audit_control \ -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \ -v /var/lib:/var/lib \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /etc:/etc --label docker_bench_security \ docker/docker-bench-security
したがって、コンテナを収集し、ホストマシンとそのコンテナのセキュリティをチェックするスクリプトを実行します。
以下は、あなたが途中で得るものの例です。
ご覧のとおり、出力は色分けされた明確な詳細であり、すべてのチェックとその結果を見ることができます。
私の場合、いくつかの修正が必要です。
この機能で特に気に入っているのは、自動化できることです。
その結果、継続的な文書化サイクルに含まれる機能を取得し、コンテナの安全性を検証するのに役立ちます。
2.追加のパワー
次の瞬間。 私が覚えている限り、余分な力の問題は常に事実でした。 Linuxディストリビューションをベアメタルサーバーにインストールする時点で、仮想マシン内にゲストオペレーティングシステムとしてインストールされるようになりました。
Dockerコンテナ内にインストールしたからといって、それらがより安全になったわけではありません。
さらに、Dockerでは難易度が次のように増加しました。 現在、ゲストとホストの境界は不明確です。 Dockerについては、2つのことに焦点を当てています。
- 特権モードコンテナー
- 追加のコンテナ権限
最初の点に関しては、特権オプションを使用してDockerコンテナーを実行できます。その後、このコンテナーは拡張特権を持ちます。
ドキュメントから引用：
コンテナはすべての機能へのアクセスを取得し、cgroup-controllerによって引き起こされたすべての制限も削除します。 つまり、コンテナはホストとほぼ同じことをすべて実行できるようになりました。 この手法により、Docker内でDockerを実行するなど、特定のシナリオが可能になります。
そのような機会のアイデアそのものがあなたを遅くさせないなら、私は驚き、心配さえするでしょう。
真実は、非常に特別な場合を除いて、細心の注意を払っても、なぜこのオプションを使用する必要があるのか想像できません。
このようなデータを使用する場合は、引き続き使用する場合は十分に注意してください。
アーミンブラウンからの引用：
ルートで実行されている他のプロセスと同じ方法で処理しない限り、特権コンテナを使用しないでください。
ただし、コンテナを特権モードで起動しない場合でも、1つ以上のコンテナに追加機能が含まれている場合があります。
デフォルトでは、Dockerはかなり限られた機能セットでコンテナを起動します。
ただし、これらの権限は、カスタムプロファイルを使用して拡張できます。
DigitalOcean、sloppy.io、dotCloud、Quay.ioなどのベンダーを含むDockerコンテナーをホストする場所に応じて、デフォルト設定はお客様のものとは異なる場合があります。
また、自分でホストすることもできます。この場合、コンテナの権限を検証することも重要です。
不要な特権と機会を放棄する
どこにホストされていても。 Dockerセキュリティガイドに記載されているとおり：
ユーザーがそれらを除くすべての機能をオプトアウトすることをお勧めします
それらはプロセスに必要です。
これらの質問について考えてください：
- アプリケーションにはどのようなネットワーク接続が必要ですか？
- ソケットに直接アクセスする必要がありますか？
- 彼はUDP要求を送受信する必要がありますか？
そうでない場合は、これらの機能を無効にします。
ただし、アプリケーションには、ほとんどのアプリケーションでデフォルトで必要とされない特別な機能が必要ですか？ はいの場合、これらの機能を接続します。
したがって、攻撃者はこれらの機能にアクセスできないため、システムを損傷する能力を制限します。
これを行うには、 --cap-drop
および--cap-add
オプションを使用します。
アプリケーションでプロセスの機能を変更したり、特権ポートをバインドしたりする必要はないが、カーネルモジュールをロードおよびアンロードする必要があるとします。 対応する機能は、次のように削除および追加できます。
docker run \ --cap-drop SETPCAP \ --cap-drop NET_BIND_SERVICE \ --cap-add SYS_MODULE \ -ti /bin/sh
詳細な手順については、Dockerのドキュメントを参照してください。「 ランタイム特権とLinux機能 」
3.システムのセキュリティ
さて、あなたは実績のあるイメージを使用しており、コンテナの過剰な許可を削減または削除しました。
しかし、このイメージはどれほど安全ですか？
たとえば、攻撃者がコンテナに突然アクセスした場合、どのような権利がありますか？ 言い換えれば、あなたはどのくらいあなたのコンテナを保護しましたか？
コンテナに入るのがとても簡単なら、それはあらゆる種類のことを同じように簡単にできるということですか？ もしそうなら、それはあなたのコンテナを強化する時です。
もちろん、名前空間 cgroup
amのおかげで、Dockerはデフォルトで安全ですが、これらの関数に cgroup
依存するべきではありません。
さらに進んで、 AppArmor 、 SELinux 、 grsecurity、 Seccompなどの他のLinuxセキュリティツールを利用できます。
これらの各ツールは熟考され、戦いでテストされており、コンテナのホストセキュリティをさらに強化するのに役立ちます。
これらのツールを使用したことがない場合、それぞれの簡単な概要を以下に示します。
防具
これは、システム管理者が個々のプログラムプロファイルを使用してプログラムの機能を制限できるLinuxカーネルセキュリティモジュールです。 プロファイルは、一致するパス上のファイルの読み取り、書き込み、実行などのアクションの許可を発行できます。 AppArmorは必須アクセス制御（MAC）を提供するため、従来のUnix（随意アクセス制御、DAC）制御モデルを補完する役割を果たします。 AppArmorは、バージョン2.6.36以降のメインLinuxカーネルに含まれています。
出典： ウィキペディア
SELinux
Security-Enhanced Linux（SELinux）-セキュリティが強化されたLinux）は、従来の選択的アクセス制御システムと並行して動作できる強制アクセス制御システムの実装です。
ソース- ウィキペディア 。
Grsecurity
これは、強制アクセス制御、主要なローカルおよびネットワーク情報データのランダム化、/proc
およびchroot()
jail
制限、ネットワークソケット制御、機能監視、追加の監査機能など、セキュリティ関連の改善を含むLinuxプロジェクトです。 典型的なアプリケーションは、ユーザーにシェルアクセスを提供するサーバーなど、疑わしい場所からのリモート接続を受け入れるWebサーバーおよびシステムです。
ソース- ウィキペディア 。
Seccomp
これは、Linuxカーネルのコンピューターセキュリティオブジェクトです。 2005年3月8日に公開されたバージョン2.6.12では、メインのLinuxカーネルとマージされました。 Seccompを使用すると、プロセスを「セーフ」モードにすることができます。このモードからwrite()
既に開いているファイル記述子のexit()
、sigreturn()
、read()
およびwrite()
以外のシステムコールを行うことはできません。 プロセスが他のシステムコールを行おうとすると、カーネルはプロセスをSIGKILL
強制終了します。 したがって、Seccompはシステムリソースを仮想化せず、単にプロセスを分離します。
出典： ウィキペディア
この記事はまだ他のことを扱っているので、これらの技術を実際の例で示したり、より詳細な説明をしたりすることはできません。
しかしそれにもかかわらず、それらについてさらに学び、私のインフラストラクチャに実装することを強くお勧めします。
4.利用可能なリソースの消費を制限する
アプリケーションには何が必要ですか？
これは、50Mbを超えるメモリを消費しない完全に軽量なアプリケーションですか？ それではなぜ彼にもっとあげるのでしょうか？ アプリケーションは、4 + CPUを必要とするより集中的な処理を実行しますか？ その後、彼にそれらへのアクセスを許可しますが、それ以上は許可しません。
進行中の開発プロセスに分析、プロファイリング、ベンチマークを含める場合、アプリケーションに必要なリソースを知っておく必要があります。
したがって、コンテナを展開するときは、最も必要なものにのみアクセスできるようにしてください。
これを行うには、Dockerで次のコマンドを使用します。
-m / --memory: # --memory-reservation: # --kernel-memory: # --cpus: # CPU --device-read-bps: #
公式のDockerドキュメントからの設定例は次のとおりです。
version: '3' services: redis: image: redis:alpine deploy: resources: limits: cpus: '0.001' memory: 50M reservations: memory: 20M
詳細については、 docker help run
を使用するか、Dockerドキュメントの「 リソースのランタイム制約 」セクションを参照してください。
5.大きな攻撃対象
考慮に値する最後のセキュリティの側面は、Dockerの動作方法の直接的な結果です。これは、潜在的に非常に大きな攻撃対象となります。 どのIT組織もこのようなリスクにさらされていますが、特にコンテナインフラストラクチャの一時的な性質に依存しているリスクにさらされています。
Dockerを使用すると、アプリケーションをすばやく作成およびデプロイし、それらを迅速に削除できるため、組織にデプロイされているアプリケーションを追跡することは困難です。
このような状況では、インフラストラクチャのより多くの要素が攻撃される可能性があります。
組織内のアプリケーション展開の統計情報は最新ですか？ 次に、次の質問を自問してください。
- 現在展開しているアプリケーションは何ですか？
- 誰がそれらを展開しましたか？
- それらはいつデプロイされましたか？
- なぜ展開されるのですか？
- 彼らはどれくらいの時間働くべきですか？
- それらの責任者は誰ですか？
- 安全性のテストが最後に行われたのはいつですか？
これらの質問に答えることはそれほど難しくないことを願っています。 いずれにせよ、実際に実行できるアクションを見てみましょう。
正しいログを使用して監査ログを展開します。
アプリケーション内では、通常、次のようなユーザーアクションが記録されます。
- ユーザーがアカウントを作成したとき
- 彼がそれを活性化したとき
- ユーザーが最後にパスワードを変更したときなど。
これらのアクションに加えて、組織で作成および展開された各コンテナのアクションを追跡する必要があります。
この会計を不必要に複雑にする必要はありません。 次のような活動の記録を保持する必要があります。
- アプリケーションがデプロイされたとき
- 誰がそれを展開しました
- なぜ展開されたのですか？
- 彼の意図は何ですか
- いつ止めるか
継続的な開発のためのツールのほとんどは、この情報を記録できるはずです。そのようなオプションは、ツール自体で、または特定のプログラミング言語のカスタムスクリプトの助けを借りて利用できるはずです。
さらに、メールまたはその他の方法（IRC、Slack、またはHipChat）で通知を実装する価値があります。 この手法により、何が展開されているかを全員が確認できるようになります。
したがって、何か不適切なことが発生した場合、それを隠すことはできません。
従業員への信頼をやめることはお勧めしませんが、何が起きているのかを常に認識しておくことをお勧めします。 この記事を終える前に、誤解しないでください。
あなたが船外に飛び込んで、多くの新しいプロセスの作成に動揺することはお勧めしません。
このようなアプローチは、おそらくコンテナの使用がもたらす利点を奪うだけであり、完全に不要です。
それでも、少なくともこれらの問題を熟考し、その後定期的にそれらに時間を割くと、より多くの情報を得て、外部の攻撃にさらされる可能性のある組織内のホワイトスポットの数を減らすことができます。
おわりに
そこで、5つのDockerセキュリティの問題と、それらの解決策をいくつか検討しました。
Dockerに切り替えているか、すでにDockerに切り替えていることを願っています。それらを念頭に置き、アプリケーションに必要なレベルの保護を提供できるようにしてください。 Dockerは驚くべき技術であり、これまで見られなかったことは残念です。
この記事に記載されている情報が、すべての予期しない問題から身を守るのに役立つことを願っています。
著者について
マシューセッターは、 独立した開発者およびテクニカルライターです。 彼はテストアプリケーションの作成を専門としており、継続的な開発、テスト、セキュリティなどの最新の開発方法について書いています。
この記事は、 Docker Security Best Practicesの翻訳です。