キーポイント
-
eBPFは、他の方法では取得が難しいマイクロサービス・コンテナ環境におけるオブザーバビリティデータへのアクセスを支援している。
-
開発者は、パフォーマンス監視、プロファイリング、トレーシングのための自動計測から恩恵を受けている。
-
ツールやプラットフォームの検証が必要であり、eBPFが有効なワークフローを検証するために、カオスエンジニアリングで本番環境を構築する。
-
eBPFによるセキュリティ監視は、悪意のある業者がセキュリティポリシーを回避する方法を学習しており、いたちごっこである。
-
カオスエンジニアリングは、eBPFプローブを使用して動作を操作することで利益を得ている。
この記事では、オブザーバビリティとセキュリティ・ワークフローを改善することを目的とした、新しいクラウド・ネイティブ技術であるeBPFを学ぶための知見を共有する。eBPFツールを使って本番環境でのデバッグを行うには、多くのステップを踏む必要がある。既存のツールの使い方を練習し、オブザーバビリティ・ストレージ、アラート、ダッシュボードを使用して課題に取り組む方法を学んだ。最良のツールはバックアップに似ており、動作が確認されなければ役に立たない。カオスエンジニアリングがどのように役立つかを学び、eBPFに基づくオブザーバビリティとセキュリティの使用例を把握する。専門的な方法でそれらを解決することは、カオスエンジニアリング自体の新しいアイデアも生まれる。やるべきこととリスクについても議論され、将来的な本番でのデバッグの改善のためのウィッシュリストを提供している。
eBPFを始める
eBPFのプログラムやツールを使い始めるには、様々な方法がある。多くの記事や提案に圧倒されるかもしれない。最初のステップは、使用事例と解決すべき問題の定義だ。製品インシデントのトラブルシューティングをより迅速に行うために、より下位レベルのモニタリング・メトリクスを得ることは有用か?もしかしたら、Kubernetesクラスタのセキュリティに不安があるかもしれない。最後は、マイクロサービス・コンテナ環境は、動作とデータを検査する良い方法だと考えてほしい。モノリシック・アプリケーションで稼働している仮想マシン上のファイルを読むのに比べて、アクセスを得るのが複雑な場合が多い。
デバッグとトラブルシューティング:eBPFの使用例
実用的な使用事例とツールを見て、デバッグの状況を把握し、それらが適切に機能しているかを確認する方法を考えよう。
オブザーバビリティは、メトリクスとトレースに変換される追加のデータ収集により、eBPFの恩恵を受けられる。例えば、下位レベルのカーネル・メトリクスは、カスタムPrometheus Exporterで収集できる。開発者のオブザベイラビリティにフォーカスしたアプローチとしては、アプリケーションのパフォーマンスに関する情報を得るためのソースコードの自動計測がある。Pixieは開発者向けにスクリプト可能な言語を通じて、この機能を提供する。CorootはeBPFを使用してKubernetesサービスマップを実装し、コンテナ間のトラフィックを追跡して、Ops/SREのプロダクションヘルスに関する情報を提供する。Parcaによる継続的なプロファイリングは、アプリケーションコード内部のコールとパフォーマンスをトレースするための関数シンボルのアンワインディング技術によって可能になる。
セキュリティは、eBPFが役立つもう1つの重要な分野だ。不正なシステムコール、ホームを呼び出す接続、またはビットコインマイナーやルートキットのような悪意のある攻撃者によってフックされたイベントシステムコールを検出する。例えば、Ciliumはセキュリティのオブザーバビリティを提供し、Tetragonで防止を提供する。Aqua SecurityのTraceeは、悪意のある動作を検出するために、CLIやCI/CDで使用できる。FalcoはKubernetesの脅威検知エンジンであり、クラウドネイティブのエコシステムにおいてもっとも成熟したソリューションである。GitLabセキュリティ・チームによって特別なユースケースが作成され、パッケージ依存関係のインストール・スクリプト(例えばNodeJSのpackage.json)をスキャンして悪意のある動作を検出し、サプライ・チェーン攻撃の防止に役立てる。
SRE/DevOpsチームは、迅速にデバッグし、よりグローバルな視点で根本原因を確認するための適切なツールを必要としている。Inspektor Gadgetのようなツールセットは、Kubernetesで発信接続のトレースやDNSリクエストのデバッグなどに役立つ。Carettaは、サービスの依存関係マップを可視化するために使用できる。eBPFプログラムを安全な方法で配布するには、新しいアイデアも必要だ。Bumblebeeは、OCIコンテナ・フォーマットを活用してeBPFプログラムを配布用にパッケージ化することで、それを容易にする。
オブザーバビリティの課題
プロダクション・インシデントのデバッグ、アプリケーション・パフォーマンスの分析、一般的に既知の疑問点の理解、潜在的な未知の疑問点の確認に役立つ、さまざまなオブザーバビリティデータ・タイプがある。このため、異なるストレージ・バックエンドが必要となり、DIY疲れにつながる。既存のデータに変換できないeBPFプローブ・データが導入され、タイプやソースが追加されると、さらに複雑になる可能性がある。統一されたオブザーバビリティのデータストアが必要となり、多くのデータを保存できるように拡張される。
この問題を解決するために本当に必要なデータは何だろうか?ソフトウェアのリグレッションのトラブルシューティング?最適な保存期間を見つけるのは難しい。ストレージバックエンドをセルフホストするのも難しいが、SaaSはコストが高すぎるかもしれない。さらに、コスト効率とキャパシティプランニングが必要になる。これは、将来的なオブザーバビリティデータのストレージ増加を見積もるのにも役立つ。GitLabインフラチームは、キャパシティプランニングと予測に役立つオープンソースプロジェクトTamlandを開発した。
eBPFデータから得られるメリットや見識をさらに増やすには、アラートやダッシュボードへの統合も必要だ。 一般に公開されるインシデントの量を減らし、より多くの見識を利用して問題を検出し、修正するにはどうすればよいだろうか?全体的な健全性の状態、インシデント管理データとの相互参照、そして「すべての運用データ」は、異常検知、予測、傾向計算するために必要だ。マイクロサービスの世界では、「私のサービスは問題ないか」という答えはもうない。
すべての閾値が「OK」を示す緑色のダッシュボードは、アラートが機能していることや、 ダッシュボードの分析情報からクリティカルな状況を迅速に解決することの証明ではない。データ収集自体も影響を受けたり壊れたり、eBPFプログラムが意図したとおりに動作したり、風変わりなカーネルのバグが運用を襲うかもしれない。これは、運用の問題をシミュレートするための新旧のアイデアをもたらすカオスエンジニアリングだ。管理された方法で問題を解決し、サービスレベル目標(SLO)、アラート、ダッシュボードを検証する。カオス・フレームワークは、例えばクラウドネイティブのカオスエンジニアリングのためのChaos Meshや、CI/CDワークフローに統合されたChaos Toolkitのように、独自の実験で拡張できる。カオスエンジニアリングのパターンは予期しない動作の導入、セキュリティ・テストを実行する場合にも利用できる。ランダムなカオスでは、セキュリティ エクスプロイトも含め、すべてが異なる動作をするためだ。
eBPFのオブザーバビリティを壊そう
eBPFに基づくツールやプラットフォームは、素晴らしい分析情報を提供し、本番インシデントのデバッグに役立つ。これらのツールやプラットフォームは、例えば、インフラストラクチャー環境の破壊や攻撃を試み、ツールやプラットフォームの動作の観察で、その強みを証明し、弱点を明らかにする必要がある。ここでは、オブザーバビリティとカオスエンジニアリングに注目してみよう。ゴールデンシグナル(遅延、トラフィック、エラー、飽和)は、CPU/メモリのストレステスト、TCPの遅延、DNSのランダム応答などを注入する既存のカオス実験を使って検証できる。
もう一つの実用的な例は、CPU、IO、メモリを含む下位レベルのシステムメトリクスの収集だ。これは、PrometheusへのeBPFイベント・エクスポーターを使って実行できる。受信したメトリクスを検証するために、各タイプ(CPU、IO、メモリストレス、遅延)の既存のカオス実験することで、システムがどのように動作するか、収集したデータが有効なのかを確認できる。
開発者は、アプリケーション・コードの自動計測を提供し、Kubernetesクラスタ内のサービス・マップを作成するPixieの恩恵を受けられる。正しいデータを示すマップやパフォーマンスのボトルネックを示すトレースを検証するために、ストレステストやネットワーク攻撃を引き起こすカオス実験を追加する。そうすれば、サービスマップやトレースが時間とともにどのように変化するかを具体的に確認でき、ユーザーが問題に直面する本番インシデントが発覚する前に、特定された問題のある動作に対して対策を講じられる。
SREにとって、Kubernetesのトラブルシューティングは、Inspektor Gadgetツールコレクションのインストールで、コンテナランタイムブラックボックスの制限を克服できる。Inspektor GadgetはeBPFを使用してコンテナ通信経路からイベントとメトリクスを収集し、下位レベルのLinuxリソースを高位レベルのKubernetesコンセプトにマッピングする。DNS、ネットワークアクセス、アウトオブメモリ分析用のガジェットが多数用意されている。ツールのウェブサイトでは、アドバイス、監査、プロファイル、スナップショット、トップ、トレースガジェットに分類されている。top ebpfガジェットを使えば、他の実行中のeBPFプログラムの使用状況やパフォーマンスを可視化できる。その機能のテストにて推奨される方法は、ツール/コマンドを分離し、それにマッチするカオス実験の実行だ。例えば、DNSカオス実験では、DNSリクエストに対してランダムまたは無応答を返す。
Corootをインストールし、そのサービスマップ自動検出機能を使用することで、より視覚的なKubernetesのトラブルシューティングと観測が可能だ。視覚的なeBPを使用したFサービスマップは、コンテナのネットワーク接続をトレースし、kube-state-metricsPrometheusエクスポーターからのメトリクスを使用して個々のコンテナをアプリケーションに集約する。Corootのサービスマップは、カオス実験の対象として最適だ。サービスがサービスマップから消るような影響を与えるTCP接続の切断や遅延をシミュレートしたり、ネットワーク攻撃シミュレーションで帯域幅を増やしたり、インシデント条件下でダッシュボードを検証することを検討しよう。OOMキルはCorootでも検出可能で、Prometheusモニタリングメトリクスの基礎となるものを使用する。このシナリオを具体的にテストするための、DNSが失敗した時だけメモリリークが起こるデモ・アプリケーションは筆者の"Confidence with Chaos for your Kubernetes Observability"の講演で利用可能だ。
Parcaによる継続的なプロファイリングは、eBPFを使用してコードを自動計測するため、開発者はプロファイリング呼び出しを追加するためにコードを修正する必要がなく、開発に集中できる。Parcaエージェントは、コールスタック、関数呼び出し時間などのプロファイリングデータを生成し、アプリケーションのパフォーマンスボトルネックを特定するのに役立つ。CPU/メモリのストレステストを追加することで、アプリケーションの動作に影響を与え、競合状態やデッドロックが明らかになる可能性があり、実際に何を最適化しようとしているのかを把握するのに役立つ。
OpenTelemetryは、データフォーマットの仕様として、トレースとログの次にメトリクスをサポートしている。Kubernetesクラスタ内、またはハイパークラウド上のカーネルからeBPFコレクターを提供する新しいプロジェクトがある。異なるコレクターはメトリクスのイベントをReducer(データインジェスター)に送り、ReducerはPrometheusのスクレイプエンドポイントとしてメトリクスの提供をサポートするか、gRPCを使ってOpenTelemetryコレクターのエンドポイントに送る。カオス実験は、既知の方法で追加でき、メトリクスが時間とともにどのように変化するかを見るためにシステムをストレステストを行う。
最後になるが、一部の使用例では、高性能ネットワークでeBPFプログラムとして動作するカスタムDNSサーバーが含まれる。DNSリクエストを壊すことで、その挙動を明らかにするのにも役立ちます。それがDNSです。
立場を変え、eBPFのセキュリティを打ち破る
立場を変えて、eBPFのセキュリティ・ツールや方法を打ち破ってみよう。一つの方法は、特権の昇格をシミュレートする行動データを注入し、ツールがどのように反応するかを観察することだ。もう1つの方法は、データの分離を必要とするマルチテナント環境を悪用し、望まないアクセスをシミュレートすることだ。
攻撃者になりすますのは困難なことが多い。誰かが「システムコールをトレースし、ルートキットを探す」と言ったとき、私はすぐにこれに注目した。Linuxのrootkitsを検索するといくつか結果があり、その手法を理解することは、潜在的な攻撃のなりすましシナリオを構築するのに役立つ。インターネット上でsyscall hookingを検索すると、traceeのメンテナによる、Diamorphineルートキットを使った実践的な洞察とtraceeを使ったルートキット狩りについての講演を含み、より多くのリソースにたどり着く。
例題を読み、試す前に、本番環境でこれを試してはいけない。隔離されたテストVMを作成し、ルートキットをダウンロードしてビルドし、カーネルモジュールをロードしてください。ルートキットは自分自身を隠し、システムを危険にさらすためにあらゆることを行う。テスト終了後は、VMを削除すること。
Tracee CLIを呼び出すことで、システムコールフッキングを検出できた。以下のコマンドは、Docker自身の中で、いくつかのマップされた変数とトレースするイベントhooked_syscalls
を必要とする特権コンテナでtraceeを実行できる。
$ docker run \
--name tracee --rm -it \
--pid=host --cgroupns=host --privileged \
-v /etc/os-release:/etc/os-release-host:ro \
-v /sys/kernel/security:/sys/kernel/security:ro \
-v /boot/config-`uname -r`:/boot/config-`uname -r`:ro \
-e LIBBPFGO_OSRELEASE_FILE=/etc/os-release-host \
-e TRACEE_EBPF_ONLY=1 \
aquasec/tracee:0.10.0 \
--trace event=hooked_syscalls
問題は、ルートキットからどのようにカオス実験を作成するかだ。本番環境で信頼できるカオス・テストではないが、Diamorphine ルートキットの getdents システムコール・フッキング・メソッドを本番環境でシミュレートし、アラームがトリガーされるかどうかを検証できる。
Cilium Tetragonは、eBPFの助けを借りて悪意のある動作を検出するために同様の方法で動作し、ルートキットの動作に関する新たな見識を示した。検出とルール・エンジンは、ルートキットの一晩の活動が、指定されたポート上で拡大してランダムな名前のプロセスを生成することを示せた。
$ docker run --name tetragon \
--rm -it -d --pid=host \
--cgroupns=host --privileged \
-v /sys/kernel/btf/vmlinux:/var/lib/tetragon/btf \
quay.io/cilium/tetragon:v0.8.3 \
bash -c "/usr/bin/tetragon"
より実用的なシナリオを想像してみよう。クラウドVM、本番環境のKubernetesクラスタ、テストやステージングなどのCI/CDデプロイ環境で動作するビットコイン・マイナーのマルウェアだ。これらのパターンを検出することは問題の一部であり、侵入防御は別の、まだ答えの出ていない問題である。本番環境のカオス実験としてルートキットをインストールすることは、まだ推奨されていない。 しかし、eBPFプログラムでシステムコールのローディング・オーバーライドを模倣することは、テストに役立つ。
シミュレーションだけを行うカオス・テスト用ルートキットを作成することを新たなに提案する。例えば、ディレクトリ・ファイル一覧のgetdentsシステムコールにフックして、すべてのセキュリティ・ツールがうまくいけばシミュレーションされたセキュリティ問題を検出して検証できるようにする。可能であれば、以前に学習した攻撃から、より多くのフッキング試行をシミュレートする。これはまた、AI/MLモデルを訓練するための興味深い使用事例であり、eBPFセキュリティ・ツールとプラットフォームを検証するための、さらなるシミュレーションされた攻撃を提供できる。
カオスエンジニアリングがeBPFからどのような恩恵を受けるか
QCon Londonでの講演に取り組む際、eBPFをカオス実験のためのデータ収集と注入の方法として考えた。eBPFによって下位レベルのカーネル内情報にアクセス可能になれば、データを変更して本番インシデントをシミュレートできる。Phoebeプロジェクトを紹介した「Maximizing error injection realism for chaos engineering with system calls」という研究論文がある。eBPFの助けを借りてシステムコールをキャプチャし、オーバーライドする。
既存のカオス実験はユーザーレベルで行われている。例えばChaos MeshのDNSカオスは、KubernetesクラスタのすべてのDNSリクエストを処理するCoreDNSに注入される。もし、ユーザー空間に到達する前にDNSリクエストにフックするeBPFプログラムがカーネル・レベルにあるとしたらどうだろう?それはDNSリクエスト分析し、リゾルバリクエストに対して間違ったレスポンスを返すことでカオスを引き起こせる。これは高スループット、低レイテンシーのDNSレスポンスを実現するためにBPFで書かれた実験的なDNSサーバーである。Xpress DNS プロジェクトでは、すでにいくつかの作業が行われている。ユーザースペースアプリケーションは、カーネルのeBPFプログラムによって読み込まれるBPFマップにDNSレコードを追加/変更できる。これはDNSとeBPFを使った新しいカオス実験の入り口となる。
eBPFカオスインジェクションのすべてのアイデアをまとめると、ルートキットの振る舞いをシミュレートする新しいカオス実験を作成し、セキュリティのオブザーバビリティと実行を検証するためにホームを呼び出せる。TCP/UDPとDNSの遅延や間違った応答を引き起こすためにトラフィックを傍受することや、CPUストレスのアイデアは、信頼性とオブザーバビリティを検証するのに役立つ。
カオスeBPF:やるべきことがある
eBPFの長所と利点は明確だが、何が欠けているのか、今後どこに投資する必要があるのか?どのようなリスクに注意すべきか?
一つの焦点は、eBPF プログラムをコンパイル、テスト、コード品質チェックやセキュリティスキャンに対する検証、潜在的なパフォーマンスの問題が必要なコードと同様に扱う、DevSecOps と SDLC である。また、潜在的なサプライチェーン攻撃を回避する必要もある。eBPF の複雑な性質を考えると、ユーザはインストールガイドに従い、本番システムで何が起こるかを検証せず、curl や bash のコマンドパターンを適用する可能性がある。
カーネルがロード時にeBPFプログラムを検証し、安全でない可能性があるプログラムを拒否するため、CI/CDパイプラインでeBPFプログラムを自動的にテストすることは大変です。CI/CDでeBPFプログラムをテストできるようにするために、eBPF verifierをカーネルの外に移行する試みがある。
eBPFにはリスクがあり、その1つは、カーネル・レベルのあらゆるものへのRoot権限によるアクセスだ。TLSライブラリ関数コールが生の文字列を利用できるようになった直後に、TLS暗号化トラフィックをフックできる。また、eBPFを迂回するためにeBPFを使用するエクスプロイト、ルートキット、脆弱性も現実に存在する。エクスプロイトやデータアクセスに特殊なプログラミング技術を使用する研究も行われているが、これらはeBPFセキュリティ実施ツールでは検出されない。いたちごっこは今後も続くだろう。
eBPFのウィッシュリストは以下の通りだ。
- スリープ可能なeBPFプログラム。コンテキストを一時停止し、後の時点で続行する(さまざまなプログラミング言語で「ファイバー」と呼ばれる)。
- 他のeBPFプログラムの悪意のある動作を監視するeBPFプログラム(Ops lifeのモニター・ザ・モニター問題に似ている)。
- より多くのスタートガイド、学習リソース、またプラットフォームの抽象化により、この新しいテクノロジーへの参入障壁が低くなり、誰もが貢献できる。
結論
eBPFは、オブザーバビリティデータを収集する新しい方法だ。ネットワークの洞察、セキュリティのオブザーバビリティと実行に役立つ。本番インシデントのデバッグにも役立つ。カオスエンジニアリングは、オブザーバビリティとeBPFプログラムの検証に役立ち、カオス実験におけるeBPFプローブの新しいアイデアは、より高速な反復を可能にする。さらに、伝統的なメトリクス・モニタリングにとどまらず、より多くのデータソースから恩恵を受けられる。つまり、本番環境の相関、検証、観測を行える。これは、DataOps、MLOps/AIOps、AllOpsへの道筋を容易にする。
開発者は、オブザーバビリティ主導の開発のための自動インスツルメンテーションの恩恵を受けることができる。DevOps/SREチームはカオスエンジニアリングで信頼性を検証し、DevSecOpsはより多くのクラウドネイティブセキュリティデフォルトが見られる。CI/CDにおけるeBPFプログラムのテストと検証は、すべてのアイデアを上流に持ち込み、eBPFオープンソースプロジェクトを使用し貢献するための参入障壁を下げることに次ぐ、大きなToDoである。