コンテンツにスキップ
1337skills 1337skills - チートシート

eBPF革命：インストルメンテーションなしのセキュリティ及びオブザーバビリティ

· 13 min read · automation
ebpfobservabilitysecuritykubernetescloud-nativemonitoringlinuxnetworking

2026年2月27日 | 読了時間: 13分37秒

はじめに：カーネルをインフラストラクチャとして

数十年間、オブザーバビリティはアプリケーションにコード追加を意味しました。メトリクス ライブラリでサービスをインストルメント化し、呼び出しパス全体にトレーシング SDKを散りばめ、すべてのホストでログ シッパーを構成しました。可視性の各層はコストが付属しました：依存関係管理、パフォーマンス オーバーヘッド、デプロイして維持する必要があるコード変更。エンドポイント見落とし、そしてあなたはブラインドスポットを持っていました。ライブラリアップグレード、およびテレメトリー パイプラインを壊すリスク。

eBPFはこの方程式を基本的に変更します。アプリケーションをインストルメント化する代わりに、カーネルをインストルメント化します。すべてのシステム コール、すべてのネットワーク パケット、すべてのファイル アクセス、すべてのプロセス実行がLinuxカーネルを通過します — そしてeBPFは、それらを生成するアプリケーションを変更することなく、これらのイベントを観察及び実行することできます。ゼロ コード変更。ゼロ SDK 依存関係。ゼロ デプロイメント調整。

これは軽微な改善ではありません。それは能力の異なるカテゴリーです。監視層がカーネル レベルで動作する場合、すべてを見ます — アプリケーションがログを選択しないもの、サービス メッシュをバイパスするネットワーク接続、コンテナ ランタイムが知らないプロセスを含む。

eBPFエコシステムは2025年から2026年を通して急速に成熟しました。かつての研究プロジェクトと専門化されたツール収集は本番インフラストラクチャスケール化しました。Ciliumは大規模クラウド プロバイダーのネットワークを処理します。Falcoは世界中のKubernetes クラスターのランタイム セキュリティを提供します。Tetragonはカーネル直下のセキュリティ ポリシーを執行します。及びCoroot等のツール — メトリクス、ログ、トレース、継続的プロファイリング — 単一eBPFベース エージェント（ゼロ アプリケーション変更必要）からの完全スタック オブザーバビリティを提供します。

この記事はeBPFが何であるか、セキュリティ及びオブザーバビリティなぜ重要か、実施で採用方法を説明します。

eBPF 実際に何であるか

eBPFは拡張Berkeley Packet Filterの略ですが、名前はほぼ歴史的です。最新eBPFはパケット フィルタリング はるか超えて移動しています。

コアで、eBPFはカーネル内仮想マシン、カーネル イベントに応答してサンドボックス化されたプログラム実行。これらプログラムはシステム呼び出し、ネットワーク トラフィック、ファイル操作、プロセス スケジューリング、本質的には任意カーネルレベル アクティビティ観察可能 — カーネル自体を変更またはカーネル モジュール必要なし。

セーフティ モデル

eBPFを実用的にするのはセーフティ モデルです。任意eBPFプログラムが実行される前に、カーネル ベリファイヤー包括的に確認します：

  • 境界なしループなし：プログラムは終了する必要があります。ベリファイヤーは無期限実行可能性プログラム拒否します。
  • 無効メモリ アクセスなし：すべてのポインタ逆参照は検証されます。バッファ オーバーフローは不可能です。
  • スタック サイズ制限：プログラムは固定スタック サイズ（512バイト）を持ち、スタック枯渇を防ぎます。
  • ヘルパー機能アクセス：プログラムは事前承認されたカーネル ヘルパー機能のみ呼び出し可能、任意カーネル コード不可。
  • 権限要件：eBPFプログラム読み込み要件適切機能（通常 CAP_BPF またはroot）。

この検証は実行時ではなく読み込み時に発生します。プログラムベリファイヤー通過後、実行時安全チェックなしネイティブ スピードの近くで実行。結果はカーネルレベル オブザーバビリティ無視できるパフォーマンス オーバーヘッド付き — 通常包括的監視用CPU影響1-2%未満。

アタッチメント ポイント

eBPFプログラムフックまたはアタッチメント ポイント呼ばれる特定カーネル イベント附属：

フック タイプ ユース ケース 例
kprobes 任意カーネル機能トレース sys_open 監視ファイル アクセス用
tracepoints 安定カーネル トレース イベント sched_process_exec 経由プロセス 作成追跡
XDP ネットワーク パケット処理 ネットワーク スタックに到達する前に悪意のあるパケット削除
TC トラフィック制御 コンテナ レベルでネットワーク ポリシー適用
LSM Linux Security Module フック ファイル操作上セキュリティ ポリシー執行
uprobe ユーザースペース 機能トレース 特定アプリケーション機能プロファイル
perf events CPU パフォーマンス カウンター 継続的CPUおよびメモリ プロファイリング

アタッチメント ポイント幅が eBPFを強力にするもの。単一eBPFベース エージェントはネットワーク トラフィック、ファイル アクセス、プロセス実行、DNS解決、システム呼び出し パターン同時に監視可能 — 従来5または6個別ツール必要とした統合ビュー提供。

オブザーバビリティ用eBPF：すべて見る

従来オブザーバビリティ3本柱がある：メトリクス、ログ、トレース。eBPFはインストルメンテーションなしでこれら3つすべて有効にし、4番目追加 — 継続的プロファイリング — アプリケーション レベル アプローチで実用的不可。

ゼロインストルメンテーション サービス マップ

eBPFがカーネル レベルネットワーク接続監視する場合、サービス間すべてのTCP及びUDP接続を見ます — サービス メッシュ、サイドカー プロキシ、アプリケーション レベル インストルメンテーションをバイパスする接続含む。これは自動サービス発見及び依存関係マッピング有効にします。

Corootなどのツール この機能使用して、すべてのサービス依存関係表示のライブ トポロジー マップ生成します。コード変更必要ありません。サイドカー コンテナ必要ありません。サービスごと構成必要ありません。エージェントをデプロイし、数分以内にどのサービスがどの他のサービスと通信し、各接続のレイテンシ、及びすべてのパス全体のエラー率を見ます。

これは特に価値があります：

  • レガシー アプリケーション インストルメント化大規模努力なくできない
  • サードパーティー サービス コード制御していない場所
  • ポリグロット 環境 異なるサービス異なる言語及びフレームワーク使用
  • 本番問題デバッグ 未知の依存関係が連鎖失敗を引き起こす場所

プロトコル対応メトリクス

eBPFは単にネットワーク接続を見ません — これはプロトコル理解します。パケット ヘッダーをカーネル レベルで解析することで、eBPFエージェント はアプリケーション認識なしアプリケーション層メトリクス抽出可能：

HTTP/HTTPS：リクエスト メソッド、パス、ステータス コード、レイテンシ — アクセス ログから得るもの相当、ですが自動的すべてのサービスのためカーネル レベルでキャプチャされます。

データベース プロトコル：PostgreSQL、MySQL、Redis、MongoDB ワイヤー プロトコルはクエリ レイテンシ、エラー率、接続数抽出するために解析されます。つまり、任意データベース監視エージェント インストール または接続文字列修正なしデータベース パフォーマンス メトリクス得ます。

gRPC：gRPC サービスのメソッドレベル レイテンシ及びエラー追跡、gRPC フレームワーク構成修正なく キャプチャされます。

DNS：すべてのDNS ルックアップのためのDNS解決 レイテンシ及び失敗率、アプリケーション レベル ツールで著しく難しく debug DNS関連パフォーマンス問題特定助け。

Kafka：プロデューサー及びコンシューマー ラグ測定 プロトコル レベルでキャプチャ、ブローカー独立メッセージ パイプライン パフォーマンスへの可視性提供。

継続的プロファイリング

おそらく eBPFベース オブザーバビリティの最も過小評価される機能は継続的プロファイリング。従来のプロファイリングには、特定プロセスへプロファイラー附属、期間実行、出力分析が必要です。これは本番使用にとって破壊的及び リソース集約的すぎます。

eBPFベース プロファイリング異なる機能します。パフォーマンス イベント附属及び固定間隔でホスト全体のすべてのプロセス全体CPUスタック トレース 見本。オーバーヘッド最小 — 通常1% CPU未満 — 本番環境で継続的実行実行可能にします。

実践的価値は重要。サービス遅延スパイク経験する場合、スパイク遅延経験する代わりに、プロファイリング データ既に存在、正確にCPU時間がインシデント時間中費やされた所表示のフレーム グラフとして キャプチャされます。これは パフォーマンス デバッグ をアクティブな調査から遡及分析に変換します。

セキュリティ用eBPF：最初のレスポンダーとしてのカーネル

オブザーバビリティは物語の半分のみ。eBPFはランタイム セキュリティのため同様に変革的で、オブザーバビリティ及びセキュリティの単一カーネルレベル エージェントへの収束は最新インフラストラクチャ内の最も重要なアーキテクチャ シフトの1つです。

ランタイム脅威検出

従来セキュリティ監視はログ分析に依存しました — アプリケーション ログ、監査ログ、システム ログで侵害の指標をチェック。このアプローチには基本的な制限があります：攻撃者 はログを修正または抑制でき、アプリケーションはセキュリティ関連イベントをログしないあるいはログシッピング はイベント及び検出の間にレイテンシを導入。

eBPFベース セキュリティ監視異なるレベルで動作します。システム呼び出し及びカーネル イベントフック することで、ログ が抑制できないアクティビティを観察：

  • プロセス実行：すべてのプロセスシステム上生成、コンテナ ブレークアウト悪用によって起動されるものを含む
  • ファイル アクセス：ファイル開かれ、読み取り、書き込み、削除される場合、/etc/shadow または暗号キー等の機密パス へのアクセスを含む
  • ネットワーク接続：すべてのアウトバウンド接続、アプリケーション レベル ネットワーク ポリシーをバイパスするもの含む
  • 権限昇格：プロセス機能、ユーザー ID、セキュリティ コンテキスト変更システム呼び出し
  • カーネル モジュール読み込み：カーネル モジュール読み込み試み、ルートキット インストール示唆

ポリシー 執行

検出は価値、ですが予防より優れています。eBPF LSM（Linux Security Module）フック カーネル直下セキュリティ ポリシー執行有効にし、無認可アクション有効になる前にブロック。

Tetragonは Cilium チームにより開発され、この空間 主要なツール。それが提供：

プロセス実行ポリシー：どのバイナリが コンテナ実行できるように制限を定義。 Go バイナリのみ実行する必要があるコンテナ内シェルが起動され場合、Tetragon実行ブロック及びアラート生成できます。

ネットワーク ポリシー：ポッドがカーネル レベル接続可能な目的地を執行、可能性のあるコンテナ ランタイム脆弱性をバイパス。

ファイル アクセス ポリシー：プロセスがアクセス可能ファイル及びディレクトリを制限、ファイルシステム パーミッション を超えて防御深度提供。

機能制限：プロセス適用可能な Linux 機能を制限、たとえコンテナ ランタイムが付与しても。

執行はカーネルで発生し、アプリケーション レベル悪用によってバイパス不可。 コンテナ内コード実行を得る攻撃者 依然eBPF ポリシーブロック アクション実行不可、なぜならポリシーはシステム呼び出し完了する前に執行されるためです。

ネットワーク セキュリティ

Cilium、最も広く展開されたeBPFベース ネットワーク ツール、Kubernetes環境でネットワーク セキュリティ再定義しました。従来ネットワーク ポリシーはIP アドレス及びポート レベルで動作。Cilium eBPFベース ポリシーはアイデンティティ及びAPI レベルで動作：

  • アイデンティティベース ポリシー：IPアドレス及びサービス アイデンティティ代わりに Kubernetes ラベル参照ポリシー、ポッドIP割り当て追跡必要性排除
  • L7フィルタリング：HTTP、gRPC、Kafkaアプリケーション認識ポリシー ポート制限ではなく特定APIエンドポイント へのアクセス制限
  • 透過的暗号化：ノード間WireGuard ベース暗号化、eBPF経由カーネル 実装、アプリケーション変更必要ないしで
  • 帯域幅管理：ポッドごと帯域幅制限、カーネル レベルで執行

eBPF ツール エコシステム

eBPF エコシステムはいくつかの主要プロジェクト周りに統合し、特定 ドメイン各自を解決。

ネットワーク及びセキュリティ

ツール 目的 メンテナー
Cilium Kubernetes ネットワーク、ネットワーク ポリシー、サービス メッシュ Isovalent（Cisco）
Tetragon ランタイム セキュリティ 執行 Isovalent（Cisco）
Falco ランタイム脅威 検出 Sysdig / CNCF
Calico eBPF eBPF データパス付き Kubernetes ネットワーク Tigera

オブザーバビリティ

ツール 目的 メンテナー
Coroot 完全スタック オブザーバビリティ（メトリクス、ログ、トレース、プロファイリング） Coroot
Hubble Cilium のためネットワーク オブザーバビリティ Isovalent（Cisco）
Pixie Kubernetes オブザーバビリティ New Relic / CNCF
Parca 継続的プロファイリング Polar Signals
Grafana Beyla HTTPおよび gRPC 自動インストルメンテーション Grafana Labs

トレース及びデバッグ

ツール 目的 メンテナー
bpftrace eBPF 用高レベル トレース言語 IO Visor
BCC BPF コンパイラ コレクション ツールキット IO Visor
bpftool eBPF プログラム管理ユーティリティ Linux カーネル

実践的採用：開始

eBPF採用は深いカーネル 知識必要ありません。最新 eBPF ツール複雑性を削除及び 馴染みの インターフェース — ダッシュボード、アラート、ポリシー定義を提示。

オブザーバビリティで開始

最低リスク エントリー ポイントはオブザーバビリティ。Coroot または Grafana Beyla等eBPFベース エージェント 既存 監視 スタック と並べてデプロイ。エージェント はアプリケーション変更必要ありません — 特権コンテナ または DaemonSet として実行 及びすぐ メトリクス 収集開始。

Kubernetes環境の場合：

# Helm で Coroot をデプロイ
helm repo add coroot https://coroot.github.io/helm-charts
helm repo update coroot
helm install -n coroot --create-namespace coroot-operator coroot/coroot-operator
helm install -n coroot coroot coroot/coroot-ce

# ダッシュボード にアクセス
kubectl port-forward -n coroot service/coroot-coroot 8080:8080

数分以内に、サービス マップ、HTTPおよびデータベース接続のレイテンシ メトリクス、及びリソース使用率 データが表示 — アプリケーションへのインストルメンテーション変更なくキャプチャ。

セキュリティ 執行追加

オブザーバビリティが実施される場合、自然な次のステップはセキュリティ 執行。Tetragon は段階的パス 提供：

フェーズ 1：監査モード。 Tetragon を監査モードで ポリシー デプロイ。 これは ポリシー違反をブロック なしログ、アプリケーション 動作理解及び 執行前にポリシーを改定する時間を与えます。

フェーズ 2：アラート モード。 Tetragon イベント をアラート システム接続。 疑わしいアクティビティ発生するとき通知受信 — 予期しないプロセス、無認可ネットワーク接続、機密 ファイル アクセス。

フェーズ 3：執行モード。 監査 モードで検証されたポリシー上で 執行有効化。 最も重要な制限 — コンテナ ブレークアウト 予防、例えば — で開始及び徐々にカバレッジを拡大。

カーネル 要件

eBPF 機能はLinuxカーネル バージョン に依存。最新eBPF オブザーバビリティ及びセキュリティ ツール、以下が必要：

機能 最小カーネル 推奨
基本 eBPF 4.4 5.10以上
BTFサポート 5.2 5.10以上
LSM フック 5.7 5.15以上
BPF トークン 6.9 6.9以上
リング バッファー 5.8 5.10以上

ほとんど クラウド プロバイダー マネージドKubernetes サービス（EKS、GKE、AKS） すべての最新 eBPF 機能 サポートするカーネルを実行。オンプレミス デプロイメント最高 互換性 のためカーネル 5.10以降 をターゲット すべき。

パフォーマンス 考慮

eBPF 監視 最小オーバーヘッド 追加、ですが「最小」は「ゼロ」ではありません：

  • CPUオーバーヘッド：通常1-2% 包括的監視 用（ネットワーク、プロセス、ファイル、プロファイリング）
  • メモリ 使用：ノード当たり 50-200 MB エージェント 用、カーディナリティ に依存
  • ネットワーク オーバーヘッド：メトリクス及びイベント 中央 サーバー にシップ、帯域幅使用 クラスタ サイズ及びアクティビティに依存
  • ストレージ：ClickHouse（Coroot使用）またはPrometheus（多数ツール使用） サービス及び保持期間数に比例 ストレージが必要

ほとんど環境の場合、これらオーバーヘッド獲得される可視性と比較して無視できます。ただし、高頻度 取引 システム、リアルタイム オーディオ/ビデオ処理、及び他のレイテンシクリティカル ワークロード本番環境デプロイメント前にeBPF ツール注意深くベンチマーク。

セキュリティ及びオブザーバビリティ の収束

eBPFエコシステムの最も重要なトレンド、セキュリティ及びオブザーバビリティの統一プラットフォームへの収束。歴史的に、これらは個別の学問分野、個別ツール、個別チーム、個別予算だった。eBPF 技術的境界を消去。

単一カーネルレベル エージェント ネットワーク接続、プロセス実行、ファイル アクセス、システム呼び出し パターン キャプチャする場合、同じデータ 両用途に役立つ：

  • オブザーバビリティ："Service AのレイテンシはDB増加 200ms最後のデプロイメント後"
  • セキュリティ："Service Aコンテナ内で予期しないプロセスが起動し、 未知のIPへの アウトバウンド接続を作成しました"

両方の観察は同じeBPF データ ソースから来ます。差はデータ方法及びどのアクション がトリガーされるか。この収束は エージェント スプロール（3個または4個代わりの1個エージェント）削減、データ重複排除、以前不可能だった相関を可能にします — リアルタイムで パフォーマンス影響にセキュリティ イベント をリンク等。

Coroot等のツール既に この収束を具現化し、オブザーバビリティ ダッシュボード並べてSLO追跡及び異常検出提供。Cilium及びTetragon共に単一プラットフォーム からネットワーク、オブザーバビリティ、セキュリティ執行提供。 このエコシステムが成熟する のに従って この収束を加速することを予想。

結論：新しい インフラストラクチャ層

eBPFはLinuxカーネル 機能から基礎インフラストラクチャ層に移動しました。 これは大規模クラウド プロバイダの Kubernetes オファリングのネットワーク背後のテクノロジー。 従来APMエージェント交換したオブザーバビリティ プラットフォーム。これはランタイムでコンテナ保護するセキュリティ ポリシーを執行。

エンジニアリング チーム用に、実践的要点は明確：Linuxワークロード実行している場合 — 特にKubernetes — eBPFベース ツール インフラストラクチャ スタックの一部であるべき。コード変更なく取得する オブザーバビリティ は優れています。アプリケーション修正なしに追加可能なセキュリティ 執行は変革です。及びそれぞれツール スタック決して できた方法で統合プラットフォーム両方能力オペレーション簡素化。

オブザーバビリティで開始。セキュリティ 執行を段階的に追加。カーネル がアプリケーションにするよう頼んでいた仕事をやらせてください。結果の価値。