CNDT2021、NTTデータのエンジニアがコンテナの乗っ取り方とその防ぎ方を解説

コンピュータシステムをセキュアに保つことは、システムの中のコンポーネントが多くなればなるほど困難になる。クラウドネイティブなシステムがモノリシックからマイクロサービスに移行したのは、柔軟性や可動性、スケーラビリティを高めるためだが、結果として守るべき領域、範囲が拡大し全体を見通して必要な防御を行うためには多くの労力が必要となってしまっているのが現状だ。

CNDT2021においてNTTデータのエンジニアが行った「乗っ取れコンテナ！！ ～開発者から見たコンテナセキュリティの考え方～」というタイトルのセッションは、実際に多層のシステムからコンテナを乗っ取る例とコンテナホストを乗っ取る例を解説して、悪意のあるハッカーが「どうやって攻撃するのか？」についての理解を深めた後に、それを防ぐために何をするべきか？を解説する内容だ。

動画：乗っ取れコンテナ！！～開発者から見たコンテナセキュリティの考え方～

セッションのスライド：https://speakerdeck.com/mochizuki875/container-dev-security

セッションを担当したのはNTTデータのエンジニアである望月敬太氏だ。

セッションを行う望月氏

最初に、セッションを聴いて欲しい対象者としてコンテナを利用する開発者を挙げ、インフラストラクチャーとしてKubernetesなどの運用管理を行う運用担当者ではないことを説明した。

このセッションを聴いて欲しいのはコンテナを利用する開発者

実際にはシステムのセキュリティには多くの要因が存在し、NISTのセキュリティガイドにもイメージ、レジストリー、コンテナ、オーケストレーター、ホストOSなどのカテゴリーが存在する。望月氏の経験として「雰囲気はわかるが具体的に捉え辛い」として、自らがまとめたレイヤーに分けた全体像を示したのが次のスライドだ。

望月氏によるセキュリティの全体像

ここでは開発者がアプリケーション、実行イメージ、それをパッケージとしたコンテナを生成し、インフラストラクチャーにあたるコンテナランタイム、オーケストレーター、ホストOS、ネットワークやレジストリーを運用担当者が責任を持つという区分になっている。コンテナオーケストレーションを行うKubernetesが開発者にとっては難しい、負担が大きいというのはよく言われる話だ。焦点が拡散しないように、敢えて上位のアプリケーションにおけるセキュリティを避けているのは良い判断だろう。

最初に攻撃の具体的な方法を解説

コンテナへの攻撃

ここからはコンテナへの攻撃について解説を行うフェースになった。特にコンテナへの攻撃、コンテナを実行するホストへの攻撃に絞って解説を行っている。

2種類の攻撃を具体的に解説

シンプルなWebアプリケーションに対して、2つのターミナルを使ってHTTPリクエストを用いてWebサイトのHTMLを書き換える例、コンテナ内でコマンドを実行してバックドアを作成する例などを、利用するコマンドを例に挙げながら説明した。

コマンドを実行してバックドアを作る例を説明

次にコンテナが実行されるホストOSへの侵入、悪意のあるコマンドの実行などについても解説を行った。

cgroupを使ってコンテナホストOSに侵入する例を解説

攻撃者が複数のターミナルを駆使して、さまざまなコマンドによって徐々にホストOSでコマンドを実行できるようになるまでを解説することで、「雰囲気はわかるが具体的にわかり辛い」という不満を解消しているといえる。

実際にIPアドレスを取得してコマンドを実行できるようすを解説

もう一度、レイヤーに分けたシステムの全体像から具体的な内容について解説を行い、コンテナイメージはDockerfile、コンテナについてはKubernetesの構成ファイルであるManifestファイルに対する対策の概要を解説した。

DockerfileとManifestを使って具体的な防御方法を解説

最初に解説したのは、コンテナにおけるセキュリティの考え方のひとつとして、イメージ自体に余計なものを詰め込まないということだ。

イメージに余計なものを含めないこと

ここではイメージをビルドする際、本当にそのライブラリーやパッケージがアプリケーションにとって必要なものなのかを再考するべきだと解説。自身が書いたコード以外のものが含まれれば脆弱性が発見される可能性も増えるし、たとえある時点では安全だと思われていたパッケージ・ライブラリーでも後日、脆弱性が発見されるかもしれないということを強調した。

イメージのサイズが小さいものを選ぶという経験則も

余計なものを入り込ませないために公式のイメージを使うという以外に、公式であってもイメージのサイズが小さいものを選ぶことで、脆弱性が入り込む可能性を下げることができると解説。

イメージスキャンを行うことで脆弱性を発見することもできる

ここではコンテナイメージのスキャンを行うツールとして、TrivyとDockleを挙げて説明した。しかしツールについてはエコシステムの中に多くのソフトウェアが存在しているため、ここで挙げたものだけが正解だとは認識しないで欲しいことを強調した。

コンテナホストへの攻撃

コンテナがホストに影響を及ぼさないようにするべき

コンテナホストへの攻撃の例でも解説されたように、プロセスが使う特権を必要最低限にするべきだとして、KubernetesのManifestに対してPrivilegedという記述を例に挙げて説明を行った。

コンテナのオーバーレイファイルシステムの持つリスクについても解説

ここでは悪意のあるファイルがホストOSのファイルシステムに保存されてしまうリスクを解説し、デフォルトでReadWriteとなっているKubernetesのルートファイルシステムの設定についても注意を喚起した形になった。

KubernetesのManifestに対するスキャンツールを紹介

イメージの中身ではなく実行をコントロールするKubernetesの設定ファイルに対しても、安全な設定内容になっているかを確認するためのスキャンツールがあることを紹介した。ここではKubesec、Kubeauditが紹介されているが、他にもポリシーベースのOPAなども簡単に紹介し、エコシステムには選択肢があることを説明した。

最後にまとめとして「開発者目線で何ができるか？」について「イメージに余分なものを含めない」「コンテナの隔離性を維持する」ことが大事だとしてセッションを終えた。

開発者目線ではあるものの、Kubernetesの設定ファイルにも言及していることから、望月氏は開発者自身がKubernetesの設定にも関わらざるを得ないことを認識していると言える。Kubernetesの複雑さを抽象化するために、アプリケーション開発者とインフラストラクチャー運用担当者の間にアプリケーションオペレーターというアプリに特化した運用担当を設けようとしているのがMicrosoftのやり方だが、セキュリティに関しても「誰がどこまでやるのか？」という線引きが必要な時期が来ているのかもしれない。

参考：分散型アプリの開発と運用を分離するOAMとDapr、そしてKubernetes上の実装であるRudrとは？