スッキリ、繋げて、コンテナセキュリティを得意分野に！ #2 root実行と特権コンテナの危険性

コンテナ実行を安全にする仕組み

root実行と特権コンテナのうち、まずはroot実行についてです。
ここでは、コンテナ実行を安全にする仕組みを3つほど紹介します。

① Linux Capabilities：
こちらは、プロセスに対して特権を細分化した単位（Capability）で取り扱えるようにした仕組みです。
もともとroot権限か一般ユーザ権限しか無かった時代には、root権限のほんの一部※を利用したい場合にもroot権限が必要でした。
 ※例えば、特権ポート（~1024番）の利用やシステムの停止／再起動などの実行などの特権行為。
この仕組みによって、一般ユーザに必要なCapabilityのみを付与することで、最小の権限委譲で済むようになります。

Dockerなどのコンテナは、Linux Capabilitiesの一部が付与されていない、制限された状態です。
あとから必要に応じてCapabilityを足したり引いたりできるようになっています。
rootユーザでコンテナが実行された場合、限定的に付与されたCapabilityのみが利用可能です。
非rootユーザでコンテナが実行された場合には、特にCapabilityは割り当てられず、明示的に必要なCapabilityを付与します。

② seccomp：
seccompはLinuxカーネル機能のひとつで、プロセスに対して利用できるシステムコールを制限する機能です。
Dockerではseccompのデフォルトプロファイルを用意しており、ホストに影響を及ぼすシステムコールなどが禁止されています。

③ 名前空間：
名前空間（Namespace）はカーネル機能で、コンテナ技術の中核のひとつ。様々な名前空間があります。
・マウント名前空間
・PID（プロセス番号）名前空間
・IPC（プロセス間通信）名前空間
・UTS（ホスト名やドメイン名）名前空間
・ネットワーク（アドレスやポート、フィルタなど）名前空間
・ユーザ（ユーザやグループ）名前空間
これらの名前空間をコンテナごとに区切ることで、各コンテナは干渉しない隔離空間を実現しています。

ただし、ユーザ名前空間は、まだ採用されていない（採用済でもデフォルトでない）コンテナランタイムが多いです。
ユーザ名前空間によって、空間の内外でユーザが別ユーザとしてマッピングされるようになります。
ユーザ名前空間を利用しない状態では、コンテナのrootユーザはホストのrootユーザと同一になります。

コンテナのプログラムは、ユーザの指定や定義が何もない状態だとrootユーザで実行されます。
（ユーザ名前空間が無いと）コンテナのrootユーザはホストのrootユーザと共通のものが使用されます。
それでも問題ないとされるのは、コンテナが他の様々な名前空間によって隔離状態を保っていること、Linux Capabilitiesやseccompのフィルタなどでコンテナの動作を制限しているから、となります。

では、なぜroot実行が危険とされているのかを次で見ていきます。

root実行の危険性

root実行が危険とされる所以を見ていきます。
コンテナブレイクアウト（コンテナエスケープ）の脆弱性が関係しています。

コンテナブレイクアウト（コンテナエスケープ）：コンテナエンジンなどの脆弱性を悪用し、コンテナの隔離領域を超えてホストや他コンテナを侵害する行為

以下はコンテナブレイクアウトのイメージとなります。

KubernetesやDockerなどが利用するコンテナエンジンにコンテナブレイクアウトの脆弱性があった際、コンテナ（プロセス）をrootで実行していることで、簡単にその穴を突ける状態となります。
非rootユーザで実行していれば、攻撃者は権限昇格を一段階挟む必要があり、ハードルが上がります。
このように、非rootユーザでの実行は、攻撃の容易性や脆弱性の影響を低減させる、多層防御に繋がります。

rootlessコンテナというニューフェイス

ここで、rootlessコンテナというものを紹介します。非rootユーザでの実行とは異なります。
rootlessコンテナとは、コンテナランタイムをホストの一般ユーザで実行できる仕組みです。
Dockerや他の多くのコンテナランタイムは従来、デーモンとしてrootで動作してきました。
コンテナランタイムを一般ユーザで実行可能となると、コンテナランタイムの脆弱性を突かれても、一般ユーザの権限の範囲のことしかできないため、よりセキュアになるというものです。
このrootlessコンテナの実装は、中核部分でユーザ名前空間に依存しています。
ユーザ名前空間では、空間の内外で異なるユーザがマッピングされるため、コンテナをrootで実行しても、実際には、ホスト上の一般ユーザとして実行されていることになります。

ただし、現在はまだ、rootlessコンテナをKubernetesではサポートされていません。
Dockerやruncなどではrootlessで動作させるモードをサポートしていますが、デフォルトというわけではありません。
ユーザのマッピングなどに起因する技術的制約などがハードルとなっているようです。

ということで、現時点においては、非rootユーザでのコンテナ実行を徹底することが肝心となります。
できるところで対策をするという点で、不必要にroot実行を選択しない（最小権限とする）ことを心掛けてください。

特権コンテナの危険性

さて、root実行と特権コンテナのうち、残りの特権コンテナについて説明していきます。
上記のroot実行の流れをおさえていると理解は容易です。
特権コンテナは、コンテナ内からホストへの干渉ができる特別なコンテナとなります。
特権コンテナでは、コンテナ環境に限定されない、全てのLinux Capabilitiesを持ちます。
また、seccompによるシステムコールのフィルタも適用されません。
そのため、特権コンテナは、脆弱性のあるときにリスクが顕在化するroot実行よりも危険性が高くなります。
以下では、特権コンテナ、root実行、非rootユーザでの実行を比較した図になります。

まとめ

上記を踏まえて、今回の結論は次のようになります。
コンテナ内のアプリをroot権限で実行する危険性はコンテナブレイクアウトのタイミングで顕在化するため、非rootユーザでの実行により攻撃の容易性や脆弱性の影響を低減させる、多層防御の観点で重要ということでした。
rootlessコンテナの台頭により危険性が緩和されることが期待されますが、不必要なroot実行を選択しないことは、最小権限の原則としても良いでしょう。
脆弱性が無くともコンテナの領域を超えた操作が可能な特権コンテナはroot実行の危険性よりも高いため利用は慎重に。

今回の話は、関連するLinux技術や現在のコンテナエンジンの状況など、深堀すると非常に奥が深いのですが、この記事ではまず、要点、大枠を掴んでいただき、面白さを感じてもらうところに留めております。

また、root実行や特権コンテナの利用について、ユーザの作り込み以外の対策として、弊社製品Trend Micro Cloud One - Container Security™では、デプロイ制御機能を有しており、root実行や特権モードでK8s上にデプロイされようとしているコンテナを検知・ブロックする仕組みを提供しています。
root実行や特権モードについては、ユーザの作り込みによって根本的な解決をする必要がありますが、実際にそうしたセキュアな作り込みを実施できているかをチェックする仕組みも、併せて検討いただければと思います。

主な参考情報：
Kubernetesドキュメント Podセキュリティの標準（Pod Security Standards）
Linux Capabilities
Dockerドキュメント ユーザ名前空間
rootlesscontaine.rsコミュニティ

本ブログシリーズでは、コンテナセキュリティについて、捉えづらい部分をスッキリ、理解の点と点を繋げて、全体像を捉えられるようにすることをテーマとしています。
皆さんがコンテナ分野を『苦手』から『面白い≒得意』にできるようなコンテンツをお届けしていきます！
※本ブログの内容はエンジニア個人の見解であり、弊社全体としての見解ではない点をご了承ください。