Docker コンテナの実例: コンテナセキュリティのベストプラクティス

オープンソースの詳細については、以下をご覧ください。

51CTO オープンソース基本ソフトウェアコミュニティ

https://ost..com

1. コンテナの構成

1. 特権コンテナの使用を禁止する

--privileged を使用してコンテナを起動すると、すべてのカーネル機能がコンテナに付与され、Capability の機能制限が上書きされます。この場合、コンテナはホスト層が実行できるほとんどの操作を実行できるため、システムのセキュリティリスクが増大するため、禁止する必要があります。

 $ docker run -d - - 特権nginx

2. コンテナリソースの使用を制限する

デフォルトでは、ホスト上のコンテナはリソースに無制限にアクセスできます。このとき、コンテナが攻撃を受けたり、プログラムエラーが発生したりすると、過剰なリソース占有によりホストや他のコンテナの動作に影響を及ぼす可能性があります。

そのため、Cgroup の特性を通じてコンテナのリソース使用制限を設定することで、このような問題による影響を最小限に抑えることができます。

例 1: 使用できる CPU コアの最大数を 1 に制限します。

 $ docker run -d - - cpus 1 nginx

例 2: コンテナが特定の CPU を使用するように制限します。たとえば、ホストに 4 つの CPU がある場合、コンテナは最初の CPU のみを使用できます。次のように設定できます。

 $ docker run -d - -cpuset -cpus 0 nginx

例 3: コンテナの最大メモリ使用量を 512M に制限します。

 $ docker run -d -m 512 m nginx

3. コンテナネットワークを分離する

Docker はデフォルトでブリッジネットワークを使用し、仮想ブリッジを作成します。同じブリッジに接続されたコンテナは相互にアクセスできます。ネットワークセキュリティを強化するには、デフォルトの docker0 ネットワークに依存せず、カスタムネットワークを介してコンテナーネットワークを分割することをお勧めします。これにより、ホストマシン内のコンテナー間のアクセス分離を確保できます。

さらに、ネットワークのセグメンテーションは可能な限りホストレベルで実行する必要があります。異なるホストでは、セキュリティ要件が異なるコンテナを実行する必要があります。たとえば、開発環境、テスト環境、本番環境のホストは互いに分離する必要があります。

4. ホストシステムディレクトリをマウントしない

/boot、/dev、/etc、/proc、/sys、/usr など、ホスト上のシステム関連ディレクトリは、コンテナーへのマウントを明示的に禁止する必要があります。特に読み取り/書き込みモードでは、この状況によりコンテナがホストシステムを変更できるようになるため、ホストシステムに重大なセキュリティリスクが生じます。

残念ながら、現在、このような動作を制限するための Docker レベルの適切な技術的ソリューションは存在せず、監査などの手段を通じてのみ検出できます。

5. コンテナのルートファイルシステムを読み取り専用としてマウントする

コンテナのルートファイルシステムを読み取り専用モードでマウントします。このモードでは、ルートファイルシステムへの変更が回避されるため、コンテナーのセキュリティが確保されます。もちろん、読み取り専用モードも不便を伴い、出力コンテンツを永続ストレージに書き込むには、マウントされたストレージと組み合わせて使用する必要があります。

読み取り専用を設定する方法は非常に簡単です。次のように、コンテナを起動するときに --read only オプションを追加します。

 $ docker run -it - - 読み取り専用nginx sh  
 # echo 'test' > /root/1.txt
 sh : 2 : / root / 1 を作成できません。txt : 読み取り専用ファイルシステム

6. ホストのネットワークスタックの共有を禁止する

コンテナを起動するときに、--network host を使用して、コンテナがホストとネットワークスタックを共有できるようにします。このとき、コンテナはホストの IP とその他のネットワーク構成を使用し、コンテナのポートをホストに自動的にマップします。

この方法は一定の利便性をもたらしますが、コンテナにリスクももたらします。このモードでは、ホストのネットワークスタックをコンテナー内で操作できるため、推奨されません。

 $ docker run -d - - ネットワークホストnginx

2. 画像管理

1. 画像に機密情報を保存しない

コンテナ内のプログラムの通常の操作中は、通常、データベースアカウントのパスワード、アクセストークンなどの機密情報が必要になります。このような機密情報はイメージに保存しないでください。そうしないと、機密情報の漏洩のリスクが発生します。

構成センターなどのソリューションを使用して、この情報を管理のために外部の場所に移動できます。

2. 最小化されたベース画像を選択する

Dockerfile を使用してアプリケーションイメージを構築する場合は、ベースイメージとしてイメージを選択する必要があります。この画像を選択するときは、大きくて包括的な機能を持つ画像の使用を避け、最小限で満足のいくモードを採用する必要があります。

これには 2 つの利点があります:

セキュリティの脆弱性を最小限に抑えます。

リソースの使用量を削減します。

3. 画像をスキャンして検証する

2019年、セキュリティ企業Snykは、最も人気のある10個のDockerイメージのそれぞれに少なくとも30件のセキュリティ脆弱性があることを発見しました。これだけでも、画像のセキュリティについて注意を払うには十分です。

Docker イメージの脆弱性スキャンを実行することで、開発者や運用担当者はイメージのセキュリティ状態を把握し、見つかった問題を修正するための対策を講じることができ、より安全な展開を実現できます。

現在、イメージスキャンをサポートするオープンソースソリューションには、Docker scan、Clair、Anchore などがあります。Docker Scan は最新の Docker バージョンに統合されており、すぐに使用できます。

4. マルチステージビルドを使用する

旧バージョンでは、イメージをビルドする操作は通常、Dockerfile プロセスで完了します。このモードでビルドされたイメージには、ソースコードファイル、ダウンロードされた依存パッケージ、パッケージ化によって生成された一時ファイルなど、多くの冗長ファイルが含まれます。

この問題を解決するために、Docker はバージョン 17.05 でマルチステージビルドの使用をサポートするようになりました。このモードを使用してイメージを構築する場合、最初の段階でコードのパッケージ化やその他のワークフローを完了し、2 番目の段階で適切な実行イメージを選択し、前の段階で生成されたパッケージをイメージにコピーして構成および実行することができます。

多段階構造は、速度が速く、画像サイズが小さく、セキュリティが高いという特徴があります。イメージを構築するには、この方法を使用することをお勧めします。

例：

 #フェーズ1: コンパイルとパッケージ化
Maven から: 3.5.0 - jdk - 8 - alpine AS ビルダー
./pom.xml pom.xml を追加します
./src src /  を追加します。
 mvn clean package を実行します。
 # フェーズ2: 構成と操作
openjdk から: 8 - jre - alpine
 COPY - - from = builder target / my - app - 1.0 - SNAPSHOT 。 jar my - app - 1.0 - SNAPSHOT 。 瓶
エクスポーズ8080
 CMD [ "java" 、 "-jar" 、 "my-app-1.0-SNAPSHOT.jar" ]

III.管理基準

1. コンテナホストへのユーザーアクセスを制限する

コンテナを実行するホストは、マシンのセキュリティを物理的に確保できる、IDC コンピュータルームなどの安全で信頼性の高い環境に保管する必要があります。同時に、システムのログイン権限を適切に管理し、信頼できるユーザーのみがログインしてホストにアクセスできるようにする必要があります。これにより、人為的影響による障害を減らすことができます。

2. Dockerのバージョンを定期的に更新する

古いバージョンは、発見された脆弱性によりセキュリティ攻撃に対して脆弱です。新しいバージョンでは通常、古いバージョンのバグやプログラムエラーが修正されるため、コンテナのセキュリティがより確実に確保されます。コンテナ管理者は、Docker のバージョンを定期的に更新し、新しいバージョンを維持する必要があります。