Eolh のご紹介～ Windows コンテナにおける Security Observability の実現に向けて

Summary

ＦＦＲＩセキュリティでは、既存のクラウド環境における Observability ツールがほとんど Linux コンテナ向けである事に注目しました。そこで Windows コンテナ向けの Eolh を開発し OSS として GitHub に公開いたしました。

Background

クラウドネイティブ時代において、注目を集めている概念が Observability です。 Observability とは、元は 1960 年に Kalman によって提唱された概念であり、制御システムにおいてその出力から内部状態を推定することに関する数学的な性質です[1]。今日では、Observability ツールの多くは次のように使われています。分散アプリケーションアーキテクチャにおいて、システム全体の状態やシステムコンポーネント間の相互作用をリアルタイムで観察しその依存関係、相互作用によって発生する問題を調査する、というものです[2]。特に Extended Berkeley Packet Filter (以下、eBPF) はその中核をなすテクノロジーとしてホットなトピックです。

eBPF はカーネルなどの特権的なコンテキストでサンドボックス化されたプログラムを実行できるテクノロジーであり、eBPF のユースケースには、eXpress Data Path (XDP)、トレーシング、ネットワーキングなどが含まれます[3]。

Security 上の脅威をリアルタイムに可視化する Security Observability を eBPF で実現するツールとしては、Falco や Tracee、Tetragon があります。これらを用いることで Kubernetes 上で動作するコンテナの Security Observability を向上できます^*1。

さて、ここで述べているコンテナとは Linux コンテナのことです。また今日多くのコンテナ技術の本が出版されていますが、その対象の多くもやはり Linux コンテナです。

では、Windows コンテナはどうなっているのでしょうか。

Windows コンテナ(ノード)は　2019 年 3 月にリリースされた Kubernetes 1.14 で正式にサポートされました[4]。今や EKS や AKS、GKE でも使用できます[5][6][7]。これを踏まえれば、Windows コンテナでも Security Observability を実現するツールを使いたいと考えるのは自然なことです。しかしながら、上記のツールはどれも Linux コンテナでしか動作しません。なぜでしょうか。

まず、Linux と Windows の構造的な違いがあげられます。例えば Linux の場合、containerd との通信には unix socket が使えますが、Windows にはありません。また Linux の場合、/proc ディレクトリを見ることでプロセス情報を得ることができますが、やはり Windows にはありません。

また最大の問題として、eBPF の存在があげられます。eBPF に基づいて作られたツールを動作させるには、eBPF が当然必要です。

ところで、Windows には eBPF がない、というと不正確です。Microsoft によって Windows 上で eBPF の実装が進められているからです^*2。しかしながら、(少なくとも Eolh を作り始めた段階では)まだ機能が足りていないように思われました。

そこで今回我々は eBPF の代わりとして Event Tracing for Windows (ETW) に目を付け、Eolh を作成しました。

Eolh: Bring Cloud Native Security Observability to Windows Containers

Eolh はクラウドネイティブな Security Observability を Windows コンテナでも実現するためのツールです。

端的に説明するならば、"Tracee - eBPF + ETW"という式が最も適当です。 Tracee を改変し、eBPF 使用箇所を ETW に置き換える形で Windows コンテナを監視しています。

Eolh は Windows に適合するよう作成されています。例えば、containerd との通信には unix socket の代わりに named pipe を使用します。/proc ディレクトリをみる代わりに Windows API を実行します。

そして、前述のとおり eBPF の代わりに ETW ログをソースとして利用します。

ETW は Windows OS に備わっているロギングシステムであり、アプリケーションやカーネルが使用します。そして Windows OS にはカーネルの情報を得ることのできる ETW Provider がデフォルトでいくつか存在します。これによりコンテナ内部のイベントを Eolh はホスト側から取得し、検知ルールと照合できます。検知結果は、そのままではノードレベルの情報ですが、Eolh は内部で containerd と通信し、どのコンテナで起こったかを特定できます。これにより、Security Observability を実現できます。