サイバー脅威
サイドカーコンテナに対するインジェクション攻撃の手法と対策を解説
サイドカーコンテナはKubernetes（別称K8s）クラスタを複雑化します。複雑化により、管理が困難になるだけでなく、脅威の侵入検知も容易ではなくなります。本稿では、攻撃者が侵入後のステルス性維持のために使用する「サイドカーインジェクションテクニック」や、サイバー攻撃から「K8sクラスタを保護する方法」について解説します。
Kubernetesは、アプリケーションコンテナの展開、スケーリング、運用を自動化するために設計されたオープンソースのコンテナオーケストレーションプラットフォームです。
コンテナとは、ソフトウェアの実行に必要なもの（コード、ランタイム、システムツール、ライブラリ、設定等）をまとめた「軽量なスタンドアロン型ソフトウェアパッケージ」です。また、コンテナは、他のコンテナおよびホストシステムから隔離されています。理論上、各コンテナ内では、一つのプロセスのみが実行されます。これは、各コンテナ内においてメインアプリケーションのみが実行されることを意味します。複数のプロセスを実行する必要がある場合（Loggingやモニタリング等のため）には、同じコンテナ内で複数のプロセスを実行する代わりに、別のコンテナを展開します。この新しいコンテナが「サイドカーコンテナ」です。
オーケストレーション
Kubernetesやオーケストレーション（複数のコンテナの運用や管理）における「サイドカーコンテナ」とは、同じPod内のメインアプリケーションコンテナと並行して動作し、その機能を強化する「セカンダリコンテナ」を指します。なお、サイドカーコンテナおよびプライマリコンテナは、同じライフサイクルに従い、同一のローカルネットワークを共有します。
サイドカーコンテナは、プライマリコンテナにおけるアプリケーションの修正や拡張が難しい場合に、「効率的な動作のために必要な機能」をモジュール化するために利用されます。必要な機能ごとに異なるコンテナに分離することで、単一責任の原則（Single Responsibility Principle）が維持されます。また、システムメンテナンスが容易になります。
サイドカーコンテナを使用したLoggingには複数の方法が存在します。
- サイドカーコンテナを使用して標準出力したアプリケーションログを収集する方法（図１）
- アプリケーションログを収集するためにサイドカーコンテナをLoggingエージェントとして使用する方法（図２）
サイドカーコンテナの作成により実施可能となる事項は以下の通りです。
- 同一Pod内においてプライマリコンテナおよび補助コンテナ（サイドカー）を設置、運用すること
- 外部ソースからローカルストレージ（メインコンテナがアクセス）にデータを転送すること
- 共通のライフサイクル、リソース、ネットワーク環境を維持すること
メリットとデメリット
サイドカーコンテナを利用するメリットは以下の通りです。
- 分離（Isolation）：コアアプリケーションは、コンテナ内で自律的に動作します。そして、サイドカーコンテナは追加のプロセスやユーティリティを管理します。メインアプリケーションのコードを外部サービスから隠蔽することで、問題発生時に容易に分離することが可能となります。
- 迅速な展開：サイドカーコンテナは迅速に展開することができます。通常、追加機能をプライマリコンテナに組み込むよりもサイドカーコンテナを使用するほうが速やかな展開が可能となります。
- 拡張性：サイドカーコンテナが一度作成されると、コンテナの数にかかわらず、容易に複数のPodに対応させることができます。
サイドカーコンテナを利用するデメリットは以下の通りです。
- リソースの使用量：サイドカーコンテナの追加により、メモリおよびCPUの使用率が増加します。「効率的なリソースの使用」という観点からは、一般的に、すべてのプロセスを一つのコンテナ内で統合する場合や関連するタスクをノードレベルで実行する場合に効率が高まります。
- 複雑な運用：サイドカーコンテナの追加により、管理するコンテナ数が増加します。また、その結果として「相互関係の複雑性」も高まります。さらに、コンテナの故障時には、広域監視システム（Extensive Monitoring System）の使用が不可欠となります。このシステムは、メインアプリケーションに対する影響を把握するために用いられます。
- 同期：すべてのコンポーネントにおいてシームレスな更新を行うことは容易ではありません。同様に、メインアプリケーションコンテナとサイドカーコンテナ間においても「更新の整合性」を保つことは簡単ではありません。
インジェクション攻撃
Kubernetes Threat Matrixは、潜在的な攻撃者がKubernetesのセットアップに対して使用する恐れのあるTTPs（戦術、テクニック、手順）を構造的に理解するための脅威マトリクスです。MITRE ATT&CK（サイバー攻撃の戦術や技術を体系化したフレームワーク）にインスパイアされたこの脅威マトリクスは、TTPsのスナップショットやKubernetesシステムを保護するための「具体的なセキュリティ対策」を提供します。なお、サイドカーインジェクション（MS-TA9011）は、Kubernetesシステムに対するサイバー攻撃で使用されるテクニックの一つです。
「KubernetesのPodは、ストレージとネットワークリソースを共有するコンテナで構成されたグループです。また、サイドカーコンテナは、メインコンテナと並行して存在する追加のコンテナです。例えば、サービスメッシュプロキシ（Service-mesh Proxies）は、Pod内でサイドカーコンテナとして動作します。攻撃者は、クラスタ内で独自のPodを実行する代わりに、正規のPodにサイドカーコンテナを組み込むことでコードを実行します。また、その結果、攻撃者は不正な活動を隠蔽ことが可能となります」(Microsoft Threat Matrix for K8s)
このような攻撃手法は、「MITRE ATT&CK for Containers」 において掲載されているテクニック「Deploy Container (T1610) 」に関連します。「サイドカーインジェクションテクニック」は、ユーザの予期しない動作を引き起こすために、攻撃者が実行中のサイドカーコンテナへ侵入する際に使用されます。そして、このサイバー攻撃は、新しいソフトウェアをAPIまたはkubectlツールを介してインストールすることで実行可能となります。
サイドカーコンテナインジェクションは、ステルス性を維持することで、検知を回避する攻撃手法です。このステルス性は、マルウェアのサイドカーコンテナへの組み込み、または新しいコンテナの展開により維持されます。
攻撃方法
インジェクション攻撃によりクラスタ内のコンテナを侵害する方法は複数存在します。
Kubectlのインストール
攻撃者がkubectlをコンテナのうちの一つにインストールすることができる場合、パーミッションの設定によっては、このシンプルなスクリプトを実行することで、複数のコンテナが実行されている各ポッドの最後のコンテナにクリプトマイナーをインストールすることができます。このようなPodが実行されているクラスタの例が図3になります。
図4は、kubectlを使用してタスクを完了するために用いる「シンプルなシェルスクリプト」を示しています。
このスクリプトを実行する際の前提条件は以下の通りです。
- kubectlが正しくインストール、設定されている
- コンテナに「sh」バイナリがない場合、コマンドは機能しない
図5は、図4のスクリプトをAKS（Azure Kubernetes Service）クラスタ上で実行した結果を示しています。
前述のとおり、「sh」バイナリがコンテナ内に既にインストールされている場合に限り、スクリプトの実行が可能となります。インストールされていない場合には、「Executable file not found」というエラーを受信します。なお、改良版では「sh」やシェルバイナリがインストールされているか否かを事前にチェックすることで、これらのインストールの必要性を判断することができます。
Kubectlがインストールできない場合
kubectlをインストールできない場合であっても、攻撃者が必要なファイルにアクセスできる限り、「APIサーバ、curl、その他のコマンド」を利用してサイドカーインジェクションを実行することができます。このような攻撃の実行には、Kube API サーバのURL、Bearerトークン、そして、CA証明書のファイルパスが要求されます。
変数が正しく設定されている場合、このスクリプトは前回と同様の結果を生成します。また、当スクリプトは実行に際して「sh」バイナリがコンテナ内に存在することを前提条件としているため、該当するバイナリの確認に重きを置いています。なお、echoコマンドは、コマンドの実行結果を示すために用いられます。
対策
サイバーセキュリティ対策のために、クラスタ内のすべてのコンテナを適切にモニタリングする「ランタイムセキュリティソリューション」を導入することが推奨されます。Kubernetes環境におけるその他の重要なセキュリティ対策は以下の通りです。
- MS-M9003：「Least-privilege Principle （最小権限の原則）」の遵守。業務遂行に関連しないユーザやサービスアカウントによる新しいPodやコントローラの作成を阻止
- MS-M9013：パーミッシブコンテナ（Permissive Containers）の制限。クラスタ内のパーミッシブコンテナをアドミッションコントローラの使用により制限
- ms-m9005.003：Kubernetesクラスタ内で展開されるイメージの制限。信頼できるレジストリから取得したイメージのみ展開
ベストプラクティス
組織や企業は、サイドカーコンテナに対するサイバー脅威からKubernetesを保護するために、以下の「セキュリティに関する推奨事項」を適用することが大切です。
正当な理由によるコンテナの分離（サイドカーコンテナの作成）
正当な理由なきコンテナの分離は、クラスタの効率低下を招きます。サイドカーコンテナは、標準的なコンテナと同様に、モニタリング、更新、そして、リソースの割り当てが必要なため、コンテナが多数存在する場合には複雑化が加速します。
このような複雑化の影響を考慮すると、サイドカーコンテナの組み込みは、メインアプリケーションに具体的なメリットをもたらす場合に限るべきです。例えば、サイドカーコンテナを使用しなくとも、「Logging機能」や「異なるプログラミング言語で設計されたファイルシステム」を用いることでメインアプリケーションの機能を向上させることが可能です。つまり、サイドカーコンテナはアプリケーションのパフォーマンスを向上させるものであって、阻害するものであってはならないのです。
簡潔なモジュール設計
サイドカーコンテナは、機能を制限したシンプルなユニットとして設計することが推奨されます。シンプルなユニットは、メンテナンスが容易です。また、Pod内における迅速なバグ検出も可能になります。さらに、サイドカーコンテナがモジュール化することで、プライマリコンテナとのリソース競合も防ぐことができます。
リソースの制限
メインコンテナの機能を補強するために存在するサイドカーコンテナは、リソース消費に関して、メインコンテナに影響を及ぼさないことが重要です。そのため、サイドカーコンテナは、リソース使用を最小限に抑えるためにコンパクトな設計を採用しています。さらに、必要に応じて、リソースへのアクセス制限を設けることも大切です。サイドカーコンテナがリソース（特にメモリ）を無制限に消費した場合、Kubernetesクラスタのパフォーマンスが低下します。
潜在的な問題の一つは、ワークロードを管理するPodの数が不足していることです。クラスタ内のノードがメモリをすべて使用した場合、システムカーネルは最もメモリ集約率の高いコンテナを即座に終了させます。その結果、OOM（Out-of-memory）エラーが発生し、Podが終了します。このような事態を回避するために、サイドカーコンテナを適切に設定（リソース制限を含む）することが大切です。
まとめ
正式なアプローチではありますが、サイドカーコンテナの作成はKubernetesクラスタを複雑化します。その結果、管理が困難になるだけでなく、侵入検知の難易度も高まります。本稿では、侵入後のステルス性維持のために使用される「サイドカーインジェクションテクニック」やサイバー攻撃から「K8sクラスタを保護する方法」について解説しました。クラスタ内の標準的なコンテナと同様にサイドカーコンテナについても、不審な動作などを常時モニタリングすることは極めて重要です。
参考記事
Mitigating the Threat of Sidecar Container Injection
By: Magno Logan
翻訳：新井 智士（Core Technology Marketing, Trend Micro™ Research）