Linuxカーネルを安全に拡張するeBPFは、サイドカーやカーネルモジュールに頼らずに可観測性・ネットワーク・セキュリティを実現する基盤として定着しました。それを製品として結実させたのがCiliumです。海外の一次情報をたどりながら、日本のエンタープライズ現場で何が変わり、どこから触るべきかを整理します。

「サイドカーを増やさずに、L3からL7まで可視化したい」「エージェントを各ノードに常駐させずに、カーネルレベルでネットワークとプロセスを観測したい」——こうした要望は、ここ数年でSIerや情シスの現場でも珍しくなくなりました。その背後にある技術がeBPFであり、それをKubernetes向けに実装として結実させたのがCiliumです。本稿では、海外の一次情報をたどりながら、eBPF/Ciliumが可観測性・ネットワーク・セキュリティの何を変えたのか、そして日本の現場でどこから触るべきかを、実務目線で整理します。

01eBPFとは何か — カーネルを「安全に」拡張する仕組み

eBPF(extended Berkeley Packet Filter)は、Linuxカーネルのソースを変更せず、カーネルモジュールも読み込まずに、サンドボックス化されたプログラムをカーネル内で実行する技術です。従来、カーネルの挙動を拡張しようとすればカーネルモジュールを書くしかありませんでした。しかしモジュールは、公式ドキュメントの表現を借りれば「カーネルがリリースされるたびに壊れる可能性があり、修正し続ける必要がある」うえ「セキュリティ境界の欠如によりカーネルを破壊しうる」リスクを伴います。eBPFはこの両方を回避します(ebpf.io — What is eBPF?)。

安全性を担保するのがベリファイア(verifier)です。eBPFプログラムはロード時に静的解析を受け、未初期化変数へのアクセス、範囲外メモリアクセス、無限ループなどが検出されれば拒否されます。「プログラムは必ず完了まで実行される」「クラッシュしたりシステムに害を与えたりしない」ことが保証されて初めてカーネルに載ります。通過したバイトコードはJITコンパイルされ、ネイティブなカーネルコードと同等の速度で動きます。ここが、ユーザー空間でパケットやイベントを処理する従来型エージェントとの決定的な差です。

現場のコツ:ベリファイアは「安全に動くか」を検査するツールであって、「プログラムが何をしているか」を検査するセキュリティツールではない、と公式が明言しています。eBPFプログラム自体の配布・署名・供給元管理は別途ガバナンスが必要、と理解しておくと稟議での説明がぶれません。

02フックポイント — 「どこで観測するか」の自由度

eBPFはイベント駆動です。システムコール、関数の出入り、カーネルのトレースポイント、ネットワークイベントといったフックポイントにプログラムを引っかけ、そこを通過するたびに実行されます。既定のフックがない場所でも、kprobe(カーネルプローブ)uprobe(ユーザープローブ)を使えば、カーネル内・ユーザーアプリケーションの「ほぼどこにでも」アタッチできます。ネットワークならXDP(eXpress Data Path)でNICドライバ直後、つまりカーネルのネットワークスタックに入る前にパケットを処理でき、DDoS緩和やロードバランシングで威力を発揮します。

この「観測点の自由度」こそがeBPFの本質です。アプリのコードに手を入れず、言語ランタイムにも依存せず、カーネルという共通の観測面から全プロセス・全通信を横断的に捉えられます。APMエージェントを各言語ごとに入れて回る運用と比べると、被覆率と保守コストの構造が変わります。

eBPFの実行モデル ユーザー空間 アプリケーション / プロセス 収集ツール (Hubble / Tetragon) カーネル空間 eBPFプログラム verifier検証 + JIT syscall / kprobe tracepoint XDP / TC (ネットワーク) イベント/メトリクス
図:eBPFプログラムはカーネル内のフックポイントに載り、検証・JITを経てネイティブ同等の速度で動く。収集はユーザー空間のツールが担う。

02Cilium — eBPFを「製品」にした実装

eBPFはあくまで基盤技術です。それをKubernetesのネットワーク実装に落とし込んだのがCiliumでした。CiliumはコンテナワークロードにL3-4接続を提供するCNI(Container Network Interface)のeBPF実装として出発し、その後、ネットワークポリシー、複数クラスタのメッシュ化、kube-proxyの置き換え、ネットワーク暗号化、Ingress/Egressゲートウェイ、帯域管理、BGPへと機能を広げました。特筆すべきは、サイドカーレスのサービスメッシュを先駆けたことです(CNCF公式発表)。

Ciliumは3つの顔を持ちます。ネットワーク本体のCilium、可観測性のHubble、セキュリティのTetragonです。この分業を理解すると、自組織のどの課題に効くかが見えてきます。

03Hubble — L3〜L7のフロー可視化を「タダ同然」で

Hubbleは、Ciliumが動く環境でL3-4からL7までのネットワーク可観測性を提供します。どのサービスがどのサービスと、どのポート・どのHTTPパスで通信しているかをサービスマップとして描き、メトリクスとUIを添えます。ポイントは、これがアプリのコード変更もサイドカー注入もなしに得られること。eBPFがカーネルでフローを捉えるため、追加のプロキシコンテナを各Podに差し込む必要がありません。

従来、サービス間通信の可視化はサービスメッシュのサイドカー(Envoy等)に依存しがちで、CPU・メモリのオーバーヘッドとレイテンシがついて回りました。Hubbleは観測をカーネルに寄せることで、この構造的コストを下げます。障害調査で「どのマイクロサービス間のドロップが増えたか」を即座に地図で追える価値は、運用現場ほど実感が大きいはずです。可観測性の設計思想については監視・アラート設計CloudWatch監視の第一歩も併せてご覧ください。

04Tetragon — カーネルで「検知」して「止める」

Tetragonは、eBPFによるセキュリティ可観測性とランタイム強制(runtime enforcement)を担うサブプロジェクトです。プロセス実行、システムコール活動、ネットワークやファイルへのI/Oといったセキュリティ上重要なイベントを検知し、リアルタイムに反応します。Kubernetes環境では名前空間・Pod・ラベルといったK8sのアイデンティティを理解する「Kubernetes-aware」な設計になっており、ワークロード単位でポリシーを書けます(Tetragon公式ドキュメント)。

従来型のランタイムセキュリティは、カーネルのイベントをすべてユーザー空間に送ってから解析・判定する構造でした。Tetragonはフィルタリングと強制をeBPFでカーネル内に持ち込むため、ユーザー空間への往復が減り、観測オーバーヘッドが小さく、かつ検知から遮断までの遅延が小さい。「怪しいプロセスがexecした瞬間にkillする」といったカーネルレベルの強制が、低オーバーヘッドで成立します。

現場のコツ:Tetragonの導入は「まず観測(Observability)モードで数週間、正常系のプロセス・通信のベースラインを取る」→「そのうえで強制(Enforcement)ポリシーを段階適用」の順が安全です。いきなりkill系のポリシーを本番に入れると、バッチや運用スクリプトを誤って止めるリスクがあります。最小権限の考え方はIAM最小権限の現実とも通じます。

05CNCFでの位置づけ — 「卒業」が意味するもの

Ciliumは2021年10月にCNCFのインキュベーティングプロジェクトとなり、2023年10月11日にGraduated(卒業)しました。CNCFの卒業は、技術監督委員会(TOC)によるデューデリジェンスと第三者セキュリティ監査を通過したことを意味します。Ciliumの監査結果は2023年2月に公開されました。卒業時点で7社からメンテナを迎え、800名超の個人コントリビュータを擁し、コミット数でKubernetesに次ぐCNCF第2位のアクティビティを持つプロジェクトへ成長していました(CNCF公式発表)。

エンタープライズにとって「卒業」は単なる名誉ではなく、技術選定の根拠になります。CNCF Graduatedは、成熟度・ガバナンス・セキュリティ監査という3点で一定の担保があり、稟議や社内標準化の説明責任を果たしやすい。実際、卒業発表時点で100を超える組織が本番採用し、46件の公開事例が挙げられていました。

Ciliumファミリの役割分担 eBPF (カーネル基盤) Cilium ネットワーク / CNI ポリシー / 暗号化 Hubble L3-7 可観測性 サービスマップ Tetragon セキュリティ観測 ランタイム強制
図:共通のeBPF基盤の上に、ネットワーク(Cilium)・可観測性(Hubble)・セキュリティ(Tetragon)が分業して載る。

06K8s環境での採用と、日本での温度感

海外では、CiliumはマネージドKubernetesのデフォルトCNIとして広く採用されています。GKE DataplaneやAmazon EKS、Azure AKSなど主要マネージドK8sがCiliumベースのデータプレーンを選べる、あるいは標準採用しているのが2026年時点の実情です。eBPF自体も、Meta・Google・Netflix・Datadogといったハイパースケーラの本番基盤を支える技術として定着しています(ebpf.io)。さらにカーネル側ではsched_extによるBPF製CPUスケジューラなど、応用領域が広がり続けています。

一方、日本のエンタープライズでは温度感に幅があります。マネージドK8sのデフォルトCNIとして「気づけばCiliumが動いていた」ケースは増えているものの、Hubbleでの可観測性やTetragonでのランタイム強制まで能動的に使いこなす組織はまだ限定的、というのが率直なところです。理由は技術的難易度というより、カーネルバージョン要件・既存監視/SIEMとの統合・運用体制の整備といった「橋渡し」の部分にあります。ここは、まさに海外で先に起きたことを翻訳して持ち込む余地が大きい領域です。

まとめ

eBPFは「カーネルを安全に拡張する」という一点で、可観測性・ネットワーク・セキュリティの実装方式を構造から変えました。Ciliumはそれを製品として結実させ、CNCF卒業という成熟度の担保を得ています。日本の現場で問われるのは技術そのものより、カーネル要件・既存基盤との統合・運用体制という橋渡しです。まずHubbleで可観測性の価値を確かめ、Tetragonは観測から段階的に——この順序が、大手SIer/エンタープライズにとって現実的な入り口になります。EMWはシリコンバレーで先行した実装知見を、日本のエンタープライズ運用に翻訳して持ち込みます。関連する基盤設計は導入事例もご参照ください。

参考(一次情報)

K8s基盤の可観測性・ネットワーク刷新でeBPF/Ciliumの採用を検討される際は、PoC設計から運用移行までお問い合わせください。

相談する
← ブログ一覧へ戻る