Dockerコンテナ実践：コンテナセキュリティ分析

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

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

​​https://ost..com​​

コンテナは、オペレーティング システムに基づく仮想化です。従来の物理ホストや仮想マシンと比較すると、セキュリティ上のリスクが高くなります。コンテナユーザーにとって、コンテナのセキュリティ関連の知識を学習し理解することは重要なタスクです。

この記事ではコンテナ セキュリティを主なテーマとして取り上げ、読者はこの記事を読んだ後、関連するアプリケーションをより深く理解できるようになります。

1. コンテナのセキュリティ上の脅威

コンテナ アプリケーションでは、カーネルをホストと共有するモードが最大のセキュリティ リスクとなります。このため、コンテナは軽量化できますが、攻撃に対してはより脆弱になります。

コンテナと仮想マシンを比較すると、これを理解するのは難しくありません。

仮想マシン環境では、各仮想マシンに独立したオペレーティング システムが含まれており、ホスト マシンとの対話型インターフェイスはごくわずかしか保持されず、ほとんどのトランザクション処理を独立して完了できます。これにより、それらの間の攻撃対象領域が非常に小さくなります。ハッカーが仮想マシンを介してホストマシンを攻撃したい場合、まずハイパーバイザー層の脆弱性を見つけてそれを破壊する必要があります。仮想マシンは優れた分離特性を備えているため、攻撃に対する保護が強化されるだけでなく、仮想マシンのクラッシュによってホスト マシンが影響を受けないことも保証されます。

コンテナ環境では、コンテナはアプリケーションと依存関係のみをカプセル化するため、ホストのカーネルを使用して動作する必要があります。そのため、コンテナの権限が取得されていれば、攻撃を含めてカーネルにアクセスすることができます。コンテナ内のアプリケーションがカーネルクラッシュを引き起こすと、ホストシステム全体がクラッシュします。

コンテナの弱点を理解した後、コンテナの使用中に直面するセキュリティ上の脅威について見てみましょう。

1. イメージ汚染

現在、Docker Hub にはサードパーティによってアップロードされたイメージが多数存在し、これらのイメージの品質はさまざまです。この中には、ハッカーが悪意のあるプログラムを含む画像をわざとアップロードし、それをビジネス画像のように偽装してユーザーにダウンロードさせて使用させるケースも考えられます。ユーザーが誤ってこのようなイメージを使用してコンテナを起動すると、コンテナは間違いなくハッキングされます。したがって、ユーザーは、コンテナで使用されるイメージが信頼できるものであることを確認し、信頼できないサードパーティのイメージの使用を可能な限り避ける必要があります。

2. サイバー攻撃

Docker はデフォルトでブリッジ ネットワークを使用し、仮想ブリッジを作成します。同じブリッジに接続されたコンテナは相互にアクセスできます。コンテナがハッキングされると、ハッカーはネットワークを介してホストマシン内の他のコンテナにアクセスできる可能性があります。同時に、攻撃者は DDos などの方法でコンテナ サービスを攻撃し、ホストのリソースを使い果たして、ホスト全体をクラッシュさせることもできます。

3. カーネル攻撃

ハッカーがコンテナにアクセスすると、共有カーネルにより、理論的にはカーネルを攻撃してホストを制御したり影響を与えたりできるようになります。たとえば、Linux カーネル 3.16 より前のバージョンには、メモリ オーバーフロー脆弱性 CVE-2014-7822 があります。 splice システム コールは、2 つのファイル間でデータをコピーするときにコピー サイズをチェックしないため、カーネル データがオーバーフローして上書きされる可能性があります。したがって、ローカルの権限のないユーザーがこの脆弱性を悪用してメモリの範囲外に書き込み、システムをクラッシュさせる可能性があります。

4. 不適切な操作

ユーザーがコンテナを構成する際に、誤った操作を行うとホストが危険にさらされる可能性があります。たとえば、コンテナの起動時にホストのルート ディレクトリがコンテナにマップされている場合、理論上はコンテナがホストのファイル システムを任意に変更できるため、大きなセキュリティ リスクが発生します。

 $ docker run -d -v / : / ホストnginx

あるいは、コンテナを有効にするときに特権モード (--privileged) を使用します。この場合、Docker コンテナはホスト上のすべてのデバイスにアクセスし、多数のデバイス ファイルへのアクセス権を取得できます。

 $ docker run -d - - 特権nginx

5. Dockerデーモンへの攻撃

Docker は C/S アーキテクチャを使用します。サーバーとして機能する Docker デーモンは、CLI または REST API を介してクライアントから送信されたコマンドを受信し、コンテナーに対して対応する操作を実行します。ただし、リクエストは必ずしも信頼できるユーザーによって開始されるわけではありません。攻撃者はリクエストを偽造してデーモンを騙し、危険な操作を実行させる可能性があります。

6. Dockerの脆弱性攻撃

Docker 自体はアプリケーションであるため、コードに脆弱性が存在し、プログラムが攻撃される可能性は避けられません。

たとえば、2019 年に Docker はエスケープ脆弱性 CVE-2019-5736 にさらされました。この脆弱性により、攻撃者は特定のコンテナ イメージまたは exec 操作を通じてホスト マシンの runc 実行ファイルのファイル ハンドルを取得し、runc バイナリ ファイルを変更して、最終的にホスト マシンのルート実行権限を取得できるようになります。

2. Dockerのセキュリティ保護

コンテナがもたらすセキュリティ上の脅威に対応するため、Docker コミュニティは、ユーザーがコンテナをより安全に使用できるようにするためのさまざまなセキュリティ対策も講じています。

Docker の主なセキュリティ保護戦略は次のとおりです。

1. 名前空間

名前空間はネームスペースとも呼ばれます。 Linuxが提供するカーネルレベルの環境分離機能です。その主な目的は、コンテナのリソース アクセスの分離を提供することです。 Docker は、名前空間テクノロジーを最大限に活用して、コンテナとホストへの影響を可能な限り分離します。

現在、Namespace は、ファイル システムのマウント、ホスト名とドメイン名、プロセス間通信、プロセス アクセス、ネットワークの分離、ユーザーとグループの分離など、複数のリソースの分離をサポートしています。

2. Cグループ

Cgroup は Control Group の略で、Docker コンテナの重要な機能でもあります。名前空間を分離に使用する場合、Cgroup は、CPU、メモリ、ディスク/IO などのコンテナのリソース使用量を制限するために使用されます。この機能は非常に便利です。これにより、DDoS 攻撃やコンテナ自身のプログラムの問題によりコンテナが継続的にリソースを占有し、最終的にホスト マシンとその上で実行されている他のコンテナに影響が及び、「雪崩」災害が発生するのを防ぎます。

3. 能力

Capability は、きめ細かいアクセス制御を提供する Linux カーネルの強力な機能です。デフォルトでは、Docker によって起動されたコンテナの機能は厳しく制限されており、chown、net_bind_service、fowner、kill、setgid など、カーネル機能のサブセットのみが許可されます。

実際、ほとんどの場合、プログラムには実際のルート権限は必要ありません。コンテナーに必要なのは、いくつかの機能だけです。機能を細かく分割することで、コンテナが侵入された場合でも、より高いローカル権限を取得できず、発生する損害が制限されます。

さらに、ユーザーは --cap-add および --cap-drop パラメータを使用して機能を変更できます。次の例に示すように、コンテナの chown 機能を削除すると、コンテナ内でファイルの所有者を変更できなくなります。

 $ docker run -it - - cap -drop = chown centosを実行します。
 [ ルート@ 65 a55b893d3b / ] # /root/1.txt をタッチします
[ root @ 65 a55b893d3b / ] # ls -l /root/1.txt
 - rw - r - - r - - . 1 ルートルート0 7月3 日11:33 / ルート/ 1.txt
 [ root @ 65 a55b893d3b / ] # chownデーモン /root/1.txt
 chown : '/root/1.txt' の所有権を変更しています: 操作は許可されていません

4. Dockerデーモンのセキュリティ保護

Docker コミュニティは、Docker デーモンを非ルート権限で起動できるようにして、Docker のセキュリティを大幅に強化したいと考えています。ただし、コンテナを作成するには、ファイルシステムのマウントやネットワークの構成など、多くの特権操作を実行する必要があるため、この問題を解決するのは非常に困難です。ルートレス モードはバージョン 19.03 で実験的な機能として導入され、バージョン 20.10 で卒業しました。この機能には、オーバーレイ ネットワークや AppArmor 機能がサポートされていないなど、使用に関する制限が多数あります。同時に、このモードではカーネル バージョンに対する要件が高くなります。デフォルトの overlay2 ストレージ ドライバーを使用する場合は、少なくともカーネル バージョン 5.11 が必要です。

同時に、サーバーの保護を強化するために、Docker の REST API (クライアントがサーバーと通信するために使用するインターフェース) は、クロスサイト リクエスト フォージェリ攻撃に対してより脆弱であるため、0.5.2 以降では、元々 127.0.0.1 にバインドされていた TCP ソケットからローカル Unix ソケット メカニズムに変更されました。

 $ ネットスタット-lnpx
 アクティブなUNIX ドメインソケット( サーバーのみ)
 Proto RefCnt フラグタイプ状態I - ノードPID / プログラム名パス
unix G2 [ ACC ] ストリームリスニング644610 1 / systemd / var / run / docker.sock
 …… ​

5. その他のセキュリティメカニズム

上記のセキュリティ メカニズムに加えて、Docker は、AppArmor、SELinux、Seccomp などの既存のセキュリティ ソフトウェアまたはメカニズムを組み合わせて独自のセキュリティを強化することもサポートしています。

AppArmor と SElinux は MAC (強制アクセス制御) システムに属します。 AppArmor は主に Ubuntu や Debian などのオペレーティング システムに組み込まれていますが、SELinux は Redhat や Centos にプリインストールされています。 MAC システムは、カスタマイズされたセキュリティ ポリシーを通じてプロセスのリソースへのアクセスを制御できます。現在、SElinux をサポートするシステムでは、Docker の SElinux の使用はデフォルトで有効になっていないため、Docker デーモンを起動するときに --selinux-enabled=true パラメータを追加する必要があります。 AppArmor をサポートするシステムでは、Docker のセキュリティ保護機能がデフォルトで有効になっています。

Seccomp (セキュア コンピューティング モード) は、Linux カーネルによって提供されるセキュリティ機能であり、コンテナーの実行可能操作を制限するために使用できます。 Seccomp は、ホワイトリストまたはブラックリスト方式でプロセスによるシステムコールを制限します。プロセスが不要なシステム関数を呼び出すことを禁止することで、カーネルによって公開されるインターフェースの数を減らし、カーネルの攻撃対象領域を減らします。 Docker はコンテナを起動するときにデフォルトで Seccomp 保護を有効にします。これは次のコマンドで確認できます。デフォルトのホワイトリスト ルールでは、セキュリティが中程度の Linux では比較的一般的で安全なシステム コールのみが保持されます。

 $ grep CONFIG_SECCOMP = / boot / config - $ ( uname - r )
 CONFIG_SECCOMP = y

セキュリティ関連のコンテンツをさらに知りたい場合は、ここには記載されていない Docker の公式 Web サイトを参照してください。

要約:

コンテナは多くのセキュリティ上の脅威に直面していますが、ユーザーはそれについてあまり心配する必要はありません。この記事で説明したように、Docker にはすでにコンテナのセキュリティと信頼性を確保するための多くのセキュリティ対策が備わっています。

現在、Dockerは本番環境向けのコンテナ化製品として、大手企業で広く利用されています。

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

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

​​https://ost..com​​.