コンテナの脅威

コンテナは、アプリケーションとその依存関係をまとめてパッケージ化し、どこでも同じように実行できるようにします。

Dockerなどのツールによってコンテナが普及したのは、仮想マシンと比べて起動が速く、軽量だからです。

仮想マシンとは異なり、同じホスト上のコンテナはオペレーティングシステムのカーネルを共有します。

攻撃者がコンテナから脱出すると、その共有カーネルがホストや他のコンテナへ侵入する経路になる可能性があります。

多くのチームは、パブリックレジストリからイメージを取得します。

不明な作成者によるイメージには、マルウェア、バックドア、隠れた暗号資産マイナーが含まれている可能性があります。イメージの入手元は必ず把握してください。

信頼できるイメージでも、古い場合は危険です。

数か月前に作成されたベースイメージには、上流でずっと前に修正されたライブラリの既知の脆弱性が残っている可能性があります。

よくある間違いは、イメージにパスワードやAPIキーをハードコードすることです。

イメージを取得できる人は誰でも、そのシークレットを読み取れます。レイヤーを調べれば簡単に見つかります。

デフォルトでは、コンテナ内のプロセスがrootとして実行されることがよくあります。

そのプロセスが侵害されると、攻撃者はコンテナ内でrootレベルの権限を得るため、コンテナから脱出された場合の危険性が大幅に高まります。

追加の権限を与えるフラグは、攻撃対象領域を広げます。

コンテナを特権モードで実行すると、分離機能のほとんどが失われます。

絶対に必要な場合を除き、使用しないでください。

コンテナでは、ネットワークポートを公開することがよくあります。

データベースをインターネットに公開する場合など、不要なポートが開いていると、攻撃者に直接狙われます。本当に必要なポートだけを公開してください。

暗号化も認証もされていないレジストリを介してイメージを転送すると、攻撃者に転送中のイメージを改ざんされる可能性があります。

TLSとアクセス制御を備えた、信頼できるレジストリを使用してください。

制限のないコンテナは、ホスト上のCPUやメモリをすべて消費する可能性があります。

これにより、他のワークロードがサービス拒否状態になります。一つのコンテナが他のコンテナのリソースを枯渇させないよう、リソース制限を設定してください。

コンテナのリスクは、ライフサイクル全体に及びます。

• ビルド元のイメージ
• イメージの取得元となるレジストリ
• 実行時に付与する権限
• 共有するホスト

各段階に注意を払う必要があります。

コンテナからの脱出が、VMからの脱出よりも深刻になりやすいのはなぜでしょうか。

コンテナの脅威には、信頼できないイメージ、古いベースイメージ、埋め込まれたシークレット、rootでの実行、特権モード、公開されたポート、共有カーネルなどがあります。

これらのリスクを把握することが、コンテナのデプロイを安全にするための第一歩です。