コンテナオーケストレーションとコンテナアーキテクチャのセキュリティ設計

すでにコンテナを使用している場合は、大規模環境でのコンテナ化された複雑なワークロードの管理にコンテナオーケストレーションが欠かせないことはご存じでしょう。

しかし、コンテナオーケストレーションはコンテナ管理のためだけのものではありません。コンテナのセキュリティとも密接に関係し、非常に重要な役割を果たします。コンテナオーケストレーションは、コンテナアーキテクチャやコンテナ間の通信方法を定義する際に重要となり、どのようなアプローチをとるかによって、環境全体のデフォルトのセキュリティレベルや、1 つのコンテナでのセキュリティ侵害がクラスタ内に広がるリスクが決まってきます。

そのため、コンテナオーケストレーションのセキュリティ戦略を策定し、コンテナベースアーキテクチャにセキュリティを組み込むことが、コンテナの総合的なセキュリティを維持するために重要になります。この記事では、オーケストレーションレベルとアーキテクチャレベルでコンテナのセキュリティを確保する方法について説明します。

コンテナオーケストレーションの定義

コンテナオーケストレーションでは、自動化ツールを使用して、コンテナの運用に必要な操作を管理します。

Kubernetes、Amazon ECS、Docker Swarm などのコンテナオーケストレーションプラットフォームを使用することで、サーバークラスタ内で個々のコンテナをホストするノードの指定や、コンテナがクラッシュまたはフリーズしたときの再起動などのタスクを自動化できます。これらのタスクは手動で実行すると時間がかかるため、多数のノードに何十、何百、何千ものコンテナをデプロイする大規模なコンテナ環境ではオーケストレーションプラットフォームが欠かせません。

コンテナオーケストレーションとセキュリティ

コンテナオーケストレーションの主な目的はコンテナの保護ではなく、コンテナオーケストレーションプラットフォームはセキュリティソリューションではありません。コンテナ環境に関するセキュリティ要件の多くは、脅威を監視、検出、修復できる外部ツールで対応します。

それでも、オーケストレーションに対するアプローチや、使用するオーケストレーションプラットフォームの選択は、コンテナのセキュリティ体制全体に影響します。

そのため、コンテナ環境の設定や、コンテナを移動、デプロイ、管理するためのアーキテクチャを定義する際は、コンテナオーケストレーション戦略が重要な役割を果たします。オーケストレーション戦略とコンテナベースアーキテクチャのセキュリティの強度は、コンテナをどの程度分離するかや、コンテナ操作の管理に関するセキュリティ要件やガバナンス要件の適用にどのツールを使用するかなど、いくつかの要因によって決まります。

セキュアなコンテナアーキテクチャの構築

オーケストレーション戦略を策定し、環境のアーキテクチャを設計するときは、セキュリティに関するいくつかの重要事項を検討する必要があります。

コンテナ分離

検討すべき最も重要な要因は、アーキテクチャやオーケストレータで個々のコンテナを分離する度合いです。

コンテナは分離しすぎず、結合しすぎず、バランスを取ることが重要です。コンテナ同士が完全に分離されていて、ネットワークを介してデータを共有できず、同じデータストレージボリュームにもアクセスできず、いかなる方法でも相互に通信できないと、コンテナを使用したアプリケーションの活用は非常に難しくなります。特に、アプリケーションでマイクロサービスアーキテクチャを使用し、各マイクロサービスを独自のコンテナにデプロイする場合、コンテナ間の通信ができないとアプリケーション全体が機能しなくなります。

コンテナを分離しすぎたアーキテクチャでは、監視などのタスクの実行も難しくなります。コンテナ環境の監視ツールでは、多くの場合、「サイドカー」アーキテクチャが使用されます。このアーキテクチャでは、監視エージェントをホストするコンテナと、監視対象のアプリケーションコンテナが分けられます。監視エージェントがアプリケーションコンテナと通信できないと、監視に必要なログやメトリクスを収集できなくなります。

一方で、コンテナ間の分離の度合いが低すぎると、セキュリティの問題が生じます。各コンテナに過剰な権限を割り当てても、それが直接セキュリティ侵害の原因にはなることはありませんが、コンテナイメージに脆弱性があったり、ランタイムやホスト OS にセキュリティの問題があったりしたときに、問題が拡散して深刻化するおそれがあります。こうしたリスクは、Kubernetes のセキュリティコンテキストなどのコントロールによって、コンテナに実行を許可するアクションを制限することで防止できます。

コンテナ分離の安全策としては、コンテナに最小権限の原則を適用します。その状態で、各コンテナが、環境内での役割を果たすために必要な外部リソースにアクセスでき、それ以外のリソースにアクセスできないことを確認します。さらに、権限を詳細に定義するようにします。ネームスペースや（もっと悪いことに）クラスタ全体にセキュリティコンテキストを一括適用するといった安直な手は使わないでください。権限を詳細に定義すると設定や管理の手間は増えますが、全体的なセキュリティが向上します。

コンテナランタイム

コンテナランタイムは、個々のコンテナを実行するソフトウェアです。containerd や runC など、さまざまなランタイムが提供されています。いずれもコンテナの実行という役割は同じですが、その方法はランタイムによって多少異なります。

オーケストレータによってサポートされるランタイムが異なるため、コンテナをデプロイするコンテナランタイムは、使用するオーケストレーションソリューションによって決まります。たとえば、Kubernetes では主要なコンテナランタイムの多くがサポートされますが、Amazon ECS では Amazon 独自のコンテナランタイムしかサポートされません。

全体として、このコンテナランタイムなら安心と言えるようなものはありません。主要なコンテナはいずれも、過去にセキュリティ上の深刻な脆弱性が見つかっています。

一方で、Kata Containers など、ランタイムアーキテクチャ自体に変更を加えることによって設計レベルでランタイムの安全性を高めているプロジェクトもあります。たとえば Kata の場合は、コンテナ間でカーネルを共有しないことにより、特権エスカレーション攻撃や不適切なアクセス制御によるリスクを大幅に低減しています。

コンテナオーケストレーション戦略やコンテナアーキテクチャ全体で、セキュリティを重視したコンテナランタイムの活用を促進することで、標準的なランタイムを使用するよりもセキュリティを向上できます。

オペレーティングシステムのサポート

今日、ほとんどのコンテナが Linux で動作し、通常、どの Linux ディストリビューションでもコンテナをホストできます。そして、Linux 上のコンテナはホストの OS や構成に関係なく同じように動作します。

コンテナ化したアプリケーションを Windows にデプロイしたい場合は、Windows コンテナもあります。

ただし、Windows をどの程度サポートしているかはオーケストレーションソリューションによって異なります。Kubernetes では Windows マシンをワーカーノードとして管理できるだけで、マスターノードとしては管理できません。そのため、Kubernetes でも Windows コンテナのオーケストレーションは可能ですが、管理には Linux ベースのツールを使用する必要があります。これに対して、Docker Swarm では Windows コンテナのサポートが比較的充実しています。

では、オペレーティングシステムのサポートがコンテナのセキュリティとどのように関係するのでしょうか。実のところ、あまり大きな関係はありません。ただし、Windows コンテナは Linux コンテナよりも安全だと考える人もいます。その理由は、Windows コンテナが Linux コンテナほど普及しておらず、攻撃のターゲットになりにくいためです。（デスクトップソフトウェアの場合は Linux の方が Windows よりもターゲットになりにくいのに皮肉な現象です。しかし、多くのコンテナは、デスクトップアプリケーションではなくサーバーサイドのワークロードをホストすることを目的としています。）

そのため、手軽なセキュリティ戦略として、Windows コンテナを使用するコンテナアーキテクチャの構築を検討するのも 1 つの方法です。

サードパーティのプラグイン

コンテナアーキテクチャのセキュリティ戦略として重要な最後の鍵は、環境を充実させるためにサードパーティのプラグインをどの程度使用するかです。

Kubernetes など、一部のオーケストレータは、高度にモジュール化されています。Kubernetes では、データ管理やネットワーク管理などに、サードパーティプロジェクトが提供するプラグインを使用するのが一般的です。

一方、Amazon ECS など、アーキテクチャがあまりモジュール化されていないオーケストレータもあります。これらは通常、必要なツールが内蔵され、他のソリューションで代替することはほとんどできません。

セキュリティの観点では、サードパーティのプラグインにはメリットとデメリットがあります。優れたプラグインであれば、オーケストレータの内蔵ツールよりもセキュリティ監視と可視化を強化できます。

しかし、サードパーティのプラグインを使用しすぎると、攻撃にさらされやすくなり、追跡および管理すべき脆弱性も増えます。オーケストレータの内蔵ツールのみを使用する場合、リスクになるのは、そのツールに関連する脆弱性のみです。Kubernetes を多数の外部プラグインとともに使用する場合は、Kubernetes 自体を保護すると同時に、各プラグインのセキュリティリスクを管理する必要があります。

全体として、モジュールアーキテクチャのメリットはリスクを上回るでしょう。一方、構成をシンプルに保ちたい場合は、モジュールを無理に増やす必要はありません。

コンテナアーキテクチャとオーケストレーションのセキュリティ戦略を適用したからといって、脅威がまったくなくなるわけではありません。イメージのマルウェア感染や OS レベルのエクスプロイトなどの脅威によって、さまざまなリスクが環境内に潜り込みます。それでも、アーキテクチャとオーケストレータのセキュリティを向上させれば、脅威を効果的に隔離して対応することができます。