eBPF Introduction

eBPF Introduction Oracle Cloud Hangout Café Season7 #6 Yutaka Ichikawa
Oracle Corporation Japan Solutions Architect Nov 8, 2023

Copyright © 2023, Oracle and/or its affiliates 2 Profile Name
• Yutaka Ichikawa/市川豊 Belong • Solutions Architect Role • Principal Cloud Solution Engineer SNS • X/GitHub/Qiita:cyberblack28 Blog • https://cyberblack28.hatenablog.com/ Materials • https://speakerdeck.com/cyberblack28/ Community • Oracle Cloud Hangout Cafe #ochacafe • CloudNative Days Tokyo #cndt #o11y2022 Certified • Certified Kubernetes Administrator • Certified Kubernetes Application Developer • Certified Kubernetes Security Specialist • Kubernetes and Cloud Native Associate Publications 12/11-12 ハイブリッド開催 https://event.cloudnativedays.jp/cndt2023

Copyright © 2023, Oracle and/or its affiliates 3 ThinkIT +
Oracle Cloud Hangout Cafe Oracle Cloud Hangout Café ダイジェスト • 第1回「CI/CD最新事情」 2023年1月 (公開中) • 第2回「マイクロサービスの認証・認可とJWT」 2023年2月(公開中) • 第3回「Kubernetes Operator 超入門」 2023年3月(公開中) • 第4回「Kubernetes のセキュリティ」 2023年4月(公開中) • 第5回「実験！カオスエンジニアリング」 2023年5月(公開中) • 第6回「Service Mesh がっつり入門！」 2023年6月(公開中) https://thinkit.co.jp/series/10728

Copyright © 2023, Oracle and/or its affiliates 4 ThinkIT +
Oracle Cloud Hangout Cafe Oracle Cloud Hangout Café ダイジェスト • 第1回「Kubernetes 超入門」 2023年12月 • 第2回「IaC のベストプラクティス」 2023年1月 • 第3回「Kubernetesのネットワーク」 2023年2月 • 第4回「Pythonで作るAPIサーバー」 2023年3月 • 第5回「Observability 再入門」 2023年4月 • 第6回「Kubernetes のオートスケーリング」 2023年5月第二弾連載開始

Copyright © 2023, Oracle and/or its affiliates 5 1. What’s
eBPF • eBPF とは？ • カーネルモジュールと eBPF • BPF と eBPF • eBPF 開発 Agenda 2. eBPF 事情 • KubeCon + CloudNativeCon EU 2023 • 「Past, Present, and Future of eBPF in Cloud Native Observability」 • 「Life Without Sidecars - ls eBPF's Promise Too Good to Be True ?」 3. eBPF をベースとしたプロダクト 3. Networking / Security / Observability 4. Scalable Secure High Performance CNI Plugin 5. Sidecar - free Mesh & Ingress 6. Network Observability 7. Security Observability Runtime Enforcement 8. Runtime Enforcement 9. Runtime Security and Forensics using eBPF 10. Open Source Kubernetes observability for developers

Copyright © 2023, Oracle and/or its affiliates 7 What’s eBPF
? eBPF とは？ eBPF（Extended Berkeley Packet Filter）は、 Linux カーネルのソースコードの変更やモジュールを追加することなく Linux カーネル内部でプログラムを実行できる技術

? eBPF とは？出典 : Brendan Gregg's Blog https://www.brendangregg.com/blog/2019-01-01/learn-ebpf-tracing.html eBPF does to Linux what JavaScript does to HTML. 訳：JavaScript が HTML に対して行うのと同じように、eBPF は Linux に対して行います。 eBPF には、Linux カーネルの拡張を書くためのフレームワークがある

? カーネルモジュールと eBPF Linux カーネル空間で稼働し、Linux カーネルの機能を拡張する技術 Linux カーネルに直接ロードされて、新しい機能の追加、既存機能を変更するプログラム Linux カーネルのサブセットとして、Linux カーネルの拡張や制御を実行できるプログラム • プログラミングのハードルが高い • 後方互換性を担保しないガバナンスによりメンテナンスが厳しい • レビュー条件や開発者交渉などが厳しく、アップストリームのハードルが高い • アップストリームからディストリビューションのリリースまで時間が長い • カーネルモジュールプログラミングに比べて、ハードルが低い • eBPF プログラムは後方互換性を担保されている • 後方互換性担保によるアップストリームの不要 • アップストリーム不要のため、リリースも早くできる

? BPF と eBPF 2014年 Linux カーネル 3.14 から BPF をより汎用的にするための拡張として eBPF が誕生 BPF ※現在では BPF といえば、 eBPF を示すことが多く、以前の BPF は、classic BPF (cBPF) ともいわれる Linux カーネル 2.1.75 に移植されて、ネットワークにおけるパケットフィルタリングやキャプチャーを中心としていた eBPF ではネットワークだけでなく様々なカーネル内のイベントをフックして処理できるようになった

? eBPF 開発 eBPF は、C 言語でプログラミングして、Clang というコンパイラを利用して、bytecode というプログラムを生成する bytecode は、Linux カーネル内で動作する独自のレジスタマシンと命令セットを持ち、アーキテクチャ非依存な仮想マシン。

? eBPF 開発 bytecode を Linux カーネルにロード主要なライブラリ - libbpf (C) - cilium/ebpf (Go) - libbpf-rs (Rust) ELFファイルを加工して、最終的に Syscall に渡す=ロード ※ユーザスペースでELFフォーマットのファイルをカーネルが読み込めるようにする処理

? eBPF 開発ロードされた bytecode を Verifier で検証、JIT Compiler で各CPUの命令に合わせて、bytecode を変換 bytecode を Verifier で検証

? eBPF 開発 bytecode の実行は、フックからイベントドリブンに呼び出されて実行主なフック • Socket : socket のデータ入出力を契機にフィルタする • Syscall : システムコールの呼び出しを契機にトレースやフィルタする • Kprobe / ftrace : カーネルの関数の呼び出しを契機にトレースなど行う • TC / XDP : NIC のパケット入出を契機にパケットに対する処理を行う etc Program types : https://github.com/iovisor/bcc/blob/master/docs/kernel- versions.md#program-types

? eBPF 開発 Linux Extended BPF (eBPF) Tracing Tools BCC (BPF Compiler Collection) bpftrace https://github.com/iovisor/bcc https://github.com/iovisor/bpftrace BCC および bpftrace ツールからも分かるように eBPF では多くのイベントを取得できる

? eBPF 開発

? 参考 https://bit.ly/ebpf-summit-BG

? eBPF 開発 eBPF Maps は、ユーザプログラムとカーネルプログラムの間でデータを共有する仕組み Key ＆Value ペアのデータ構造をベースに配列やハッシュテーブルなどのタイプを利用して、ユーザプログラムとカーネルプルグラム間でデータを共有、読み取り、更新が可能 Maps types : https://github.com/iovisor/bcc/blob/master/docs/kernel- versions.md#map-types

KubeCon + CloudNativeCon EU 2023

KubeCon + CloudNativeCon EU 2023 https://kccnceu2023.sched.com/event/1Hyak/past-present-and- future-of-ebpf-in-cloud-native-observability-frederic-branczyk- polar-signals-natalie-serrino-new-relic

「Past, Present, and Future of eBPF in Cloud Native Observability」キャズムを超えるどうやってここまで来たのか？ Present Past

「Past, Present, and Future of eBPF in Cloud Native Observability」 2014年、eBPF は新しく、非常に強力ではあるが、いくつかの難点がある • eBPF のプログラムを書くことは、技術的に難しい • それはまだ比較的に不明瞭 • 大抵の人は、eBPFをパケットフィルターとして捉える • eBPF のプログラムを書くハードルが下がった • 多くの人が試し始める • ネットワークを超えたユースケースが認識されつつある

「Past, Present, and Future of eBPF in Cloud Native Observability」 Meta, Google, Cloudflare, Netflix, Dropbox, Android, Alibaba, Datadog, Trip.com, Microsoft, Seznam, CapitalOne, Apple, Sky, Walmart, Huawei, Ikea 導入の爆発的増加

「Past, Present, and Future of eBPF in Cloud Native Observability」パフォーマンス: 大量のデータを読み取り、広範な調査を効率的にサポートアクセシビリティ: 何を、どこで、どのように計測するかを特定分析: 生データの低レベルでの大量の解釈次に取り組む可能性のあるフロンティアは何か? eBPF をベースとした広範囲なオブザバビリティの実現 Future

「Life Without Sidecars - ls eBPF's Promise Too Good to Be True ?」 https://kccnceu2023.sched.com/event/1HyZd

Service Meshについてアプリケーションとプロキシ機能の分離アプリケーションプロセスごとに専用のプロキシをサイドカーとして配置、そのプロキシにネットワーク周りを対応させる App Proxy container container Pod プロキシ機能の中央管理プロキシ機能は大量になるのでコンフィグレーションの管理コストが増加。中央にプロキシ機能を管理するコントロールプレーンを配置して効率的に管理。補足

サイドカーモデルサイドカーレスモデル全てのトラフィックは、サイドカー経由するプロキシが必要なトラフィックのみ Envoy Proxy を経由各 Pod に Envoy Proxy がある各 Node に Envoy Proxy があるサイドカーとしてのプロキシコンテナが無いことで起動時間やノードのリソース消費を低減ユーザ空間とカーネル空間切り替えのオーバヘッドも低減 Service Mesh における Ciliumをベースとしたサイドカーレスの特徴補足

Pod App Pod App Pod App Pod App Pod App Pod App Pod App Pod App Pod App Node Pod App Pod App Pod App Node Pod App Pod App Pod App Pod App Pod App Pod App サイドカーモデルサイドカーレスモデルサイドカーとしてのプロキシコンテナが無いことで起動時間やノードのリソース消費を低減補足

https://isovalent.com/blog/post/cilium-service-mesh/ 補足 Isovalent 社による Cilium / Cilium + Envoy / Cilium + Istio でのパフォーマンス比較表

「Life Without Sidecars - ls eBPF's Promise Too Good to Be True ?」 • カーネルをプログラム可能にするためのインターフェース • イベント駆動型、カーネル空間で実行 • 効率 - 開発者はユーザー空間へのデータ転送を回避し、コンテキストの切り替えを最小限に抑える • 安全 - プログラムは厳格な要件に従うため、カーネルを停止することは不可能です eBPF 概要

「Life Without Sidecars - ls eBPF's Promise Too Good to Be True ?」 Traditional reverse proxy & Drawbacks • シスコールのコスト • 遅延発生 • データコピーコスト

「Life Without Sidecars - ls eBPF's Promise Too Good to Be True ?」 Sockmap • eBPF の sock map は、このシナリオをカバーするデータ構造 • ソケットへの参照を保存し、eBPF プログラムが TCP パケットを完全にカーネル空間へのリダイレクトを可能にする • リバースプロキシとロードバランサを高速化するために使用可能

「Life Without Sidecars - ls eBPF's Promise Too Good to Be True ?」 Sockmap based proxy & Advantages • カーネルからユーザー空間へのデータのコピーが無い • コンテキスト切り替えが無い • 柔軟性がある

「Life Without Sidecars - ls eBPF's Promise Too Good to Be True ?」 The sidecar is going away ? (サイドカーは不要 ?)

「Life Without Sidecars - ls eBPF's Promise Too Good to Be True ?」 eBPF プログラム • ブロックできない • ループ制限 • 命令数の制限 • 実行できる全てのパスを知る必要がある • 状態管理の制限難しいこと • mTLS ハンドシェイク • リトライ、タイムアウト、サーキットブレーキング • L7 プロトコル解析 • デバッグ eBPF だけでは、サービスメッシュの実装はできないサイドカーレスの Cilium サービスメッシュも Envoy を利用 A Service mesh needs a proxy サービスメッシュにはプロキシが必要

「Life Without Sidecars - ls eBPF's Promise Too Good to Be True ?」ノードごとにプロキシを共有 • リソースを大量に消費するプロキシを使用すれば、より効率的になる • リソース不足と公平性への懸念 • リソースを最適化する精度が弱い • 機密情報を隔離できない • 問題が発生した場合の影響範囲が大きい

「Life Without Sidecars - ls eBPF's Promise Too Good to Be True ?」サイドカー優位性 • リソースの消費量はアプリケーションに応じて変化 • プロキシの障害は特定のインスタンスに限定される • メンテナンスが容易でリスクが軽減される • セキュリティ境界が非常に明確であり、隔離性が非常に高い • シンプルモデル

「Life Without Sidecars - ls eBPF's Promise Too Good to Be True ?」よく言われること • サイドカーは、リソースを消費する • 余分な遅延が発生する • サービスメッシュは、まもなくカーネルに組み込まれる • マルチテナントプロキシーの将来性 • Linkerd のプロキシは、特にサイドカーとして機能するように最適化されており、リソース消費を抑える • サイドカーによって発生するレイテンシは、大抵アプリがサイドカーの利用を妨げる場合に比べれば少ない • カーネルに組み込むことはできても、メッシュ利用は難しいと思われる • マルチテナントプロキシは前進すると思うが、プロキシの操作が難しく、セキュリティと安定性に懸念がある

「Life Without Sidecars - ls eBPF's Promise Too Good to Be True ?」結論 • eBPF は適切なスタックレベルで多くの利点をもたらす • 我々はすでにそこにいる • サイドカーはこれからも続く

サイドカー、サイドカーレス、どちらがということもなく共存していくようにも思えるので、適材適所として選択する方向もあるのではという感想（個人意見）

Networking / Security / Observability こうした仕組みを軸に eBPF ベースのセキュリティやオブザバビリティプロダクトを利用する流れが KubeCon + Cloud Native Con などで注目されている • 高いパフォーマンスカーネルレベルで動作するため、オーバーヘッドが小さい • セキュリティの向上ネットワークポリシーやトラフィック制御、プロセス監視などによるクラスタ全体のセキュリティ向上 • 柔軟な可観測性詳細なメトリクスやネットワークトラフィックの観測が可能で、問題の特定と解決が容易

Networking / Security / Observability Observability Security Networking

Scalable Secure High Performance CNI Plugin iptables が kube-proxy 経由で実行していたことを効率的なハッシュテーブルを使用して eBPF が代替 • eBPF をベースにしたネットワーク、オブザバビリティ、セキュリティソリューション • L3/L4/L7プロトコルに対応 • Pod 間、外部サービス間のロードバランシングやネットワークポリシーを強制

2023年10月11日 CNCF は、Cilium の卒業を発表 • 2021年10月に Incubating CNCF プロジェクト • 現在は7つの異なる企業からのメンテナ、800人以上のコントリビューター • Bell Canada、Bloomberg、DB Schenker、S&P Global、Sky、および The New York Times を含む企業からの46の公開ケーススタディ • コミット数の点で、Kubernetes のみに次ぐ、CNCF プロジェクトとして2番目にアクティブ https://www.cncf.io/announcements/2023/10/11/cloud-native-computing-foundation-announces-cilium-graduation/

認定資格 https://training.linuxfoundation.org/ja/certification/cilium-certified-associate-cca/

iptables iptabels kube-proxy が iptables の設定（Service A のルーティングルール） ServiceA Source Pod Destination Pod を ServiceA で公開 ServiceA ⇒ xx.xx.xx.xx:8080 ServiceA ⇒ xx.xx.xx.xx:8080 ServiceA ⇒ xx.xx.xx.xx:8080 xx.xx.xx.xx:8080 xx.xx.xx.xx:8080 xx.xx.xx.xx:8080 以下のいずれかへ送信（DNAT） xx.xx.xx.xx xx.xx.xx.xx xx.xx.xx.xx iptables は、Service の IP から Destination Pod の IP アドレスへの変換をシーケンシャルに行うため、テーブル情報に比例してオーバヘッドが発生し、ボトルネックになり得る Destination Pod

Cilium ServiceA Source Pod Agent 以下のいずれかへ送信（DNAT） xx.xx.xx.xx:8080 xx.xx.xx.xx:8080 xx.xx.xx.xx:8080 Cilium Agent が Service を管理 Service Map Conntrack Map Destination Pod を ServiceA (xx.xx.xx.xx:80) で公開 xx.xx.xx.xx:8080 xx.xx.xx.xx:8080 xx.xx.xx.xx:8080 ID Frontend Type Backend ID Backend IP 1 xx.xx.xx.xx:80 ClusterIP 1 xx.xx.xx.xx:8080 1 xx.xx.xx.xx:80 ClusterIP 2 xx.xx.xx.xx:8080 1 xx.xx.xx.xx:80 ClusterIP 3 xx.xx.xx.xx:8080 Service Map: • 定義されたサービスとそれに関連するバックエンドのマッピング情報を持つeBPFのマップ • 「どのサービスがどのバックエンド（ Pod やコンテナ）に関連しているか」を知る Conntrack Map: • 通信の状態やメタデータを追跡するためのeBPFのマップ • 「特定の通信や接続の状態は何か」という情報を追跡するカーネル内のプログラムによる ID をベースとしたフィルタリングでパフォーマンスが向上

Sidecar - free Mesh & Ingress • eBPF と Istio の統合 • Sidecar-free によるサービスメッシュレイヤーの複雑さとオーバーヘッドを低減 • 様々なコントロールプレーンやオブザバビリティプロダクトをサーポート

Network Observability Cilium と Hubble から取得できる情報からサービス間通信の依存関係を可視化 Cilium • L3/L4 の TCP コネクション • L7 通信や HTTP リクエスト etc Hubble • L3/L4/L7 のサービス間通信状況 • DNS クエリの通信状況 • Network Policy の拒否状況 etc

Security Observability Runtime Enforcement Kubernetes のワークロードに紐づけてランタイムセキュリティとオブザバビリティを強化 Linux カーネルの情報やイベント情報を収集 Tetragon Agent から Metrics や Log などに出力 •Tetragonとは?: • Cilium Project が開発する OSS。 • 「セキュリティの可観測性」と「リアルタイム制御」を提供。 • eBPF 技術を利用し、低オーバーヘッドでカーネル情報を収集。 •主な機能: • プロセス、システムコール、ネットワーク、ファイル I/O のイベント検出。 • イベント情報のログやメトリクスへの出力。 • リアルタイムでの実行制御。 •Kubernetesとの連携: • Pod 情報、ラベル、Namespace、コンテナイメージ名などのメタデータとイベント紐付け。 • 複雑なマイクロサービス環境でも高度なポリシー定義と情報収集。 •セキュリティの利点: • Tetragon の検知したイベントを SIEM にエクスポート可能。 • セキュリティ担当者が Kubernetes クラスタ内のイベントを監視・追跡。 • セキュリティに関する意思決定をサポート。 ※ SIEM（シーム）とは、Security Information and Event Management の略称で、ネットワーク製品やセキュリティ製品を含むあらゆる IT 機器のログを一元管理・解析し、インシデントにつながる脅威を検知するセキュリティ製品

Runtime Enforcement 予期せぬアプリケーションの挙動を検知し、ランタイムレベルで脅威をアラートするランタイムセキュリティツールカーネルからのシステムコールを解析して、定義したルールに違反した意図しない振る舞いを検知 Go or C++ の SDK で動的共有ライブラリを生成して読み込ませることで、 libsinsp/libscapを拡張 https://falco.org/

参考 https://www.youtube.com/watch?v=ipsXkjWPYLY 「Kubernetes のセキュリティ」で Falco のデモを実施 https://thinkit.co.jp/article/21709

Runtime Security and Forensics using eBPF eBPF ベースのランタイムセキュリティツール、カスタムルールでは Go や Rego を利用した独自のルールも定義できる tracee-ebpf： eBPF で取得したイベントデータの収集、トレーシングから加工、変換、キャプチャなどを行い、イベントデータを tracee-rules に送信する tracee-rules：受け取ったイベントデータを定義したルールに従って評価し、不正なイベントを検知して、出力する https://aquasecurity.github.io/tracee/dev/

Open Source Kubernetes observability for developers eBPF をベースとした、Kubernetes アプリケーション用のオープンソースのオブザバビリティツール自動テレメトリー: eBPF を使用して、フルボディリクエスト、リソースとネットワークのメトリック、アプリケーションプロファイルなどのテレメトリーデータを自動的に収集クラスタ内エッジコンピューティング: すべてのテレメトリデータをクラスタ内でローカルに収集、保存。使用するクラスター CPU は 5% 未満で、ほとんどの場合 2% 未満。スクリプタビリティ: Pixie の柔軟な Python クエリ言語である PxL は、 UI、 CLI、およびクライアント API で使用可能 https://px.dev/

Network Monitoring Infrastructure Health Service Performance Database Query Profiling Request Tracing Continuous Application Profiling https://github.com/pixie-io/pixie

Copyright © 2023, Oracle and/or its affiliates 60 Get Started
1

1 デモ環境の構築手順 https://github.com/oracle-japan/ochacafe-s7-6

1 Install PIXIE CLI on OCI Cloud Shell $ curl -o px https://storage.googleapis.com/pixie-dev-public/cli/latest/cli_linux_amd64 Download the latest Pixie linux binary. $ chmod +x px Make it executable. px command excute. $ mkdir $home/bin $ export PATH="$PATH:$home/bin" $ px version Pixie CLI 0.8.2+Distribution.401c92c.20230530183620.1.jenkins

1 Install PIXIE on OKE $ px deploy Deploy the Pixie Platform in your K8s cluster https://docs.px.dev/installing-pixie/requirements/ https://work.withpixie.ai:443 Webブラウザからアクセス

1 事前にアカウントの作成が必要

1 HTTP Service Map/Nodes/Namespaces Services/Pods

1 Install Sock Shop on OKE $ px demo deploy px-sock-shop Example: deploy Weaveworks' "sock-shop". $ kubectl -n px-sock-shop get svc front-end --watch NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE front-end LoadBalancer 10.96.70.72 193.122.xxx.xx 80:30001/TCP 24m Webブラウザからアクセス

1 https://docs.px.dev/about-pixie/what-is-pixie/ コンポーネント全体図 Pixie Edge Module (PEM): ノードごとにインストールされるPixie のエージェント。 PEM はeBPF を使用してデータを収集し、データはノード上にローカルに保存。 Vizier: Pixie のコレクター。クラスターごとにインストールされます。クエリの実行とPEM の管理を担当。 Pixie Cloud: ユーザー管理、認証、データプロキシに使用されます。ホスト型またはセルフホスト型が可能。 Pixie CLI: Pixie をデプロイするために使用。クエリの実行やAPI キーなどのリソースの管理にも使用。 Pixie クライアントAPI: Pixie へのプログラムによるアクセスに使用。

1 コンポーネント概要 ① Pixie Edge Module (PEM) ノードごとにインストールされる Pixie のエージェント。 PEM は eBPF を使用してデータを収集し、データはノード上にローカルに保存。 ② Vizier Pixie のコレクター。クラスターごとにインストールされる。クエリの実行と PEM の管理を担当。 ① ②

1 Let’s observability

1 Observability & Profile オブザバビリティ（可観測性）の3つの柱としてのメトリクス、ログ、トレース • メトリクス：CPU使用率やメモリ使用量などの数値データ（何が起きているのか） • ログ：正常及び異常な状態など、タイムスタンプと共に出力されるテキストデータ（何が起きたのか） • トレース：個々のアプリケーションを伝播する特定のリクエストの追跡データ（どこで起きたのか）この3種類のデータだけでは不十分 • プロファイル：スタックトレースおよびスタックトレースに関連するCPU使用率やメモリ使用率のデータ • 例外：エラーおよびエラーを引き起こした入力値データ • イベント：サービスに対するアクションのデータ（例：商品サイトで商品購入、チケットサイトで席予約など）さらにもう3種類のデータ参考 TEMPLE: Six Pillars of Observability (https://medium.com/@YuriShkuro/temple-six-pillars-of-observability-4ac3e3deb402)

1 Observability & Profile Profile Profileは、コードのパス、関数、スレッドなど消費したリソース（CPU, メモリ, I/O, ロックなど）を一定の期間でサンプリングした統計データ（例）関数：関数の呼び出しでどのくらいのリソースを消費しているかなどを計測スレッド：複数あるスレッドのうち、あるスレッドがロックした場合に、他の待たされているスレッドの時間を計測

1 Observability & Profile Profiler Profilerは、Profileを取得するツール主な Profiler • perf • Dtrace • SystemTap • pprof (Go) • JFR (Java) プログラミング言語側からの提供されている Profiler

1 Observability & Profile Frame Graph Frame Graph を利用することで、スタックトレースの Profile を可視化できる Frame Graph は、Google Chrome のデベロッパーツールにある Performance タブで描画できる • 横軸がある一定期間でのリソース使用料 • 縦軸が内訳となる関数名（コールスタック）読み込んでいる JavaScript の関数ごとに消費している時間

ProfilerによるProfileの取得には以下のような課題がある • 開発中、単一プロセスで一時的に利用することが前提 • 大量で動的に増減するコンテナ内のプロセスに適用したり、集計することが難しい継続的なProfileの取得ができない Copyright © 2023, Oracle
and/or its affiliates 74 Get Started 1 Observability & Profile Profiler の課題

• 本番環境で実行中のアプリケーションをプロファイリングする • 必要な時に単発で取得するのではなく、継続的にプロファイルを取り続けてその推移を取得する開発中一時的に起きた時に、Profile を収集するのでは遅く、分析においても意味をなさない本番環境で継続的にプロファイリングすることで、時系列に前後関係を把握して分析を効果的に行う Copyright © 2023,
Oracle and/or its affiliates 75 Get Started 1 Observability & Profile Continuous Profiling

1 Observability & Profile Continuous Profiling Tool https://www.cncf.io/blog/2022/05/31/what-is-continuous-profiling/

1 Observability & Profile Continuous Profiling Tool https://www.cncf.io/blog/2022/05/31/what-is-continuous-profiling/ • コード内のパフォーマンスの問題とボトルネックを見つける • カーディナリティの高いタグ/ラベルを使用してアプリケーションを分析する • CPU 使用率が高い問題を解決する • メモリリークを追跡する • アプリケーションのコールツリーを理解する • プロファイリングデータをトレースにリンクするようにコードを自動計測する Grafana Pyroscope オープンソースの継続的なプロファイリングプラットフォーム https://github.com/grafana/pyroscope

1 Observability & Profile 分散トレーシングとの比較分散トレーシングプロファイルイベントベースにボトルネックになっているサービスを特定できるので、レイテンシの改善などに役立つ時間ベースにサービス内のボトルネックを特定できるので、スループットの改善などに役立つ『Cloud Profilerによるワーカープロセスのパフォーマンス改善』 Observability Conference 2022 https://onl.la/H2re14C

1 Sock Shop shipping Pod のフレームグラフ https://docs.px.dev/tutorials/pixie-101/profiler/ • Pixie プロファイラーは10ミリ秒ごとに CPU のスタックトレースをサンプリング • 30秒間のウィンドウで集約して共通の関数に基づいてグループ化 • フレームグラフにおいて、幅が広いスタックトレースはその関数に多くの処理時間が割り当てられているフレームグラフの色 • 濃紺：K8s メタデータ • 淡青色：ユーザー領域のアプリケーションコード • 緑：カーネルコード

2

2 デモ環境概要図 VM.Standard.E4.Flex OCPU x 1 MEM 16GB Canonical Ubuntu 22.04 kind-control-plane kind-worker kind-worker2 kind-worker3 • L3/L4/L7 のサービス間通信状況 • Network Policy の拒否状況 • Sock Shop の状況 • Process lifecycle • Filename access • Network observability Container Runtime Security kubectl v1.28.1 構築手順等 https://github.com/oracle-japan/ochacafe-s7-6 Sample App

2 Cilium & Hubble Cilium • L3/L4 の TCP コネクション • L7 通信や HTTP リクエスト Hubble • L3/L4/L7 のサービス間通信状況 • Network Policy の拒否状況 • Sock Shop 状況

2 Cilium & Hubble Demo kind-control-plane kind-worker kind-worker2 kind-worker3 org = empire class = deathstar deathstar org = empire class = tiefighter tiefighter org = alliance class = xwing xwing Namespace: default

2 Cilium & Hubble Demo Observability of Hubble tiefighter to deathstar forward xwing to deathstar forward

2 L4 Policy with Cilium and Kubernetes org = empire class = deathstar deathstar org = empire class = tiefighter tiefighter org = alliance class = xwing xwing Namespace: default kind-control-plane kind-worker kind-worker2 kind-worker3

2 L4 Policy with Cilium and Kubernetes Network Policy

2 L4 Policy with Cilium and Kubernetes Observability of Hubble xwing to deathstar dropped Filter of Dropped

2 L7 Policy with Cilium and Kubernetes org = empire class = deathstar deathstar org = empire class = tiefighter tiefighter org = alliance class = xwing xwing Namespace: default tiefighter to deathstar Access Deny HTTP PUT /v1/exhaust-port tiefighter to deathstar forward HTTP POST /v1/request-landing kind-control-plane kind-worker kind-worker2 kind-worker3 xwing to deathstar dropped

2 L7 Policy with Cilium and Kubernetes Network Policy

2 L7 Policy with Cilium and Kubernetes Observability of Hubble tiefighter to deathstar Access Deny HTTP PUT /v1/exhaust-port tiefighter to deathstar forward HTTP POST /v1/request-landing xwing to deathstar dropped

2 Monitoring of Sock Shop by Hubble Sock Shop install $ kubectl create -f https://raw.githubusercontent.com/microservices-demo/microservices-demo/master/deploy/kubernetes/complete-demo.yaml Port-forward Sock Shop $ kubectl get pods -n sock-shop NAME READY STATUS RESTARTS AGE ・・＜省略＞・ front-end-5d7b595bcd-2crfh 1/1 Running 0 11m ・・＜省略＞・ $ kubectl port-forward front-end-5d7b595bcd-2crfh -n sock-shop 8079:8079 http://localhost:8079/ ブラウザアクセス

2 Monitoring of Sock Shop by Hubble

2 Monitoring of Sock Shop by Hubble http://localhost:12000/ ブラウザアクセス後、sock-shop をクリックすると hubble でリアルタイムの状況を確認できる

3

3 Container Runtime Security コンテナランタイムセキュリティ • コンテナ実行時のセキュリティ • ランタイムにおける振る舞いを動的にスキャン、異常な振る舞いを検知あらかじめ設定したルールに適合するかを判断して、適合した場合にアラート出力コンテナ攻撃者侵入ファイルダウンロードマルウェア検知検知コンテナランタイムセキュリティコンテナホストアラート送信

3 - eBPF - based Security Observability & Runtime Enforcement セキュリティイベントの検知と防止定義したポリシーに従ってリアルタイムに検知、検知後、SIGKILL を送信してプロセスを停止プラガブルなポリシー定義ポリシー定義において、以下の形式をサポート • Kubernetes CRD • JSON API • OPA

3 The Four Golden Signals of Security Observbability Security Observability with eBPF では、コンテナのセキュリティ可観測性におけるゴールデンシグナルとして以下の4つ定義しています。 https://isovalent.com/blog/post/2022-04-oreilly-security/ • プロセス実行 • ネットワークソケット（TCP・UDP・Unix） • ファイルアクセス • L7ネットワークアイデンティティ Tetragon では、このシグナルを Kubernetes のメタデータと紐づけて記録できる

3 CustomeResource によるポリシー設定 • Tetragon はデフォルト動作としてプロセス実行のシグナルを記録、それ以外のシグナルは TracingPolicy CustomResource で設定可能 • TracingPolicy CustomResource では、kprobe と tracepoints という2つのフィールドがあり、各フックポイントで eBPF プログラムをロードする仕組み任意の関数・システムコールに対してフックポイント Linux カーネルに予め定義されたフックポイント kprobe tracepoints

3 Install Tetragon $ helm repo add cilium https://helm.cilium.io $ helm repo update $ helm install tetragon cilium/tetragon -n kube-system $ kubectl rollout status -n kube-system ds/tetragon -w Waiting for daemon set "tetragon" rollout to finish: 0 of 3 updated pods are available... Waiting for daemon set "tetragon" rollout to finish: 1 of 3 updated pods are available... Waiting for daemon set "tetragon" rollout to finish: 2 of 3 updated pods are available... daemon set "tetragon" successfully rolled out

3 $ tetra version tetra command excute. Install Tetragon CLI $ GOOS=$(go env GOOS) $ GOARCH=$(go env GOARCH) $ curl -L --remote-name-all https://github.com/cilium/tetragon/releases/latest/download/tetra-${GOOS}-${GOARCH}.tar.gz{,.sha256sum} $ sha256sum --check tetra-${GOOS}-${GOARCH}.tar.gz.sha256sum $ sudo tar -xzvf tetra-${GOOS}-${GOARCH}.tar.gz $ rm tetra-${GOOS}-${GOARCH}.tar.gz{,.sha256sum} CLI version: v0.11.0 Install Tetragon CLI

3 Use case 1: Monitoring Process Execution $ kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.11/examples/minikube/http-sw-app.yaml $ kubectl get pods NAME READY STATUS RESTARTS AGE deathstar-7848d6c4d5-f7g8m 1/1 Running 0 57m deathstar-7848d6c4d5-npd4b 1/1 Running 0 57m tiefighter 1/1 Running 0 57m xwing 1/1 Running 0 57m Sample Application Deploy Deploy Confirm Process execution

3 Process execution deathstar tiefighter xwing Namespace: default kind-control-plane kind-worker kind-worker2 kind-worker3 deathstar ② kubectl exec コマンドで xwing Pod のコンテナに入ってから、whoami コマンドを実施 ① kubectl logs & tetra コマンドを連携して、コンテナ内で実行される状況を出力する A B ③ whoami コマンドが実行される状況をウォッチする A カーネルのイベントハンドラである process_exec と process_exit を利用してプロセスの実行と終了を観測する

3 $ kubectl logs -n kube-system -l app.kubernetes.io/name=tetragon -c export-stdout -f | tetra getevents -o compact --namespace default --pod xwing ① Console A Flag --namespace has been deprecated, please use --namespaces instead Flag --pod has been deprecated, please use --pods instead 🚀 process default/xwing /usr/bin/netserver -D 🚀 process default/xwing /usr/bin/curl http://cilium.io 🔌 connect default/xwing /usr/bin/curl tcp 10.0.10.175:43500 -> 104.198.14.52:80 📤 sendmsg default/xwing /usr/bin/curl tcp 10.0.10.175:43500 -> 104.198.14.52:80 bytes 73 🧹 close default/xwing /usr/bin/curl tcp 10.0.10.175:43500 -> 104.198.14.52:80 💥 exit default/xwing /usr/bin/curl http://cilium.io 0 $ kubectl exec -it xwing -- /bin/bash ② Console B bash-4.3# whoami root A B

3 $ kubectl logs -n kube-system -l app.kubernetes.io/name=tetragon -c export-stdout -f | tetra getevents -o compact --namespace default --pod xwing Console A Flag --namespace has been deprecated, please use --namespaces instead Flag --pod has been deprecated, please use --pods instead 🚀 process default/xwing /usr/bin/netserver -D 🚀 process default/xwing /usr/bin/curl http://cilium.io 🔌 connect default/xwing /usr/bin/curl tcp 10.0.10.175:43500 -> 104.198.14.52:80 📤 sendmsg default/xwing /usr/bin/curl tcp 10.0.10.175:43500 -> 104.198.14.52:80 bytes 73 🧹 close default/xwing /usr/bin/curl tcp 10.0.10.175:43500 -> 104.198.14.52:80 💥 exit default/xwing /usr/bin/curl http://cilium.io 0 🚀 process default/xwing /bin/bash 🚀 process default/xwing /usr/bin/whoami 💥 exit default/xwing /usr/bin/whoami 0 A

3 $ kubectl logs -n kube-system -l app.kubernetes.io/name=tetragon -c export-stdout -f | jq 'select(.process_exec.process.pod.name=="xwing" or .process_exit.process.pod.name=="xwing")' 出力されるイベントログの詳細は JSON 形式で確認可能 Process Exit Event の一部

3 Privileged Execution deathstar tiefighter xwing Namespace: default kind-control-plane kind-worker kind-worker2 kind-worker3 deathstar A B hostPID: true, hostNetwork: true, securityContext privileged: true の test-pod を展開して、CAP_SYS_ADMIN を使用して実行している Pod を観測 test-pod ① 事前に tetragon-config (configmap)を更新して、tetragon をリスタート # change "enable-process-cred" "true" # change "enable-process-ns" "true" ② test-pod をデプロイ B ③ kubectl logs & tetra コマンドを連携して、 CAP_SYS_ADMIN の状況を観測

3 Privileged Execution $ kubectl edit cm -n kube-system tetragon-config # change "enable-process-cred" from "false" to "true" # change "enable-process-ns" from "false" to "true" # then save and exit Console B $ kubectl rollout restart -n kube-system ds/tetragon $ kubectl apply -f https://raw.githubusercontent.com/cilium/tetragon/main/testdata/specs/testpod.yaml Restart the Tetragon daemonset Apply the privileged PodSpec:

3 Use case 2: Privileged Execution Console A $ kubectl logs -n kube-system -l app.kubernetes.io/name=tetragon -c export-stdout -f | tetra getevents –o compact --namespace default --pod test-pod 🚀 process default/test-pod /usr/bin/runc --systemd-cgroup --root=/run/runc create --bundle /run/containers/storage/overlay- containers/985efa094308160475b7202193509582a338377c89e121c6e230f4b0fe95fc61/userdata --pid-file /run/containers/storage/overlay- containers/985efa094308160475b7202193509582a338377c89e121c6e230f4b0fe95fc61/userdata/pidfile 985efa094308160475b7202193509582a338377c89e121c6e230f4b0fe95fc61 🛑 CAP_SYS_ADMIN 🚀 process default/test-pod /proc/self/exe init 🛑 CAP_SYS_ADMIN 🚀 process default/test-pod /dev/fd/6 init 🛑 CAP_SYS_ADMIN 💥 exit default/test-pod /dev/fd/6 init 0 🛑 CAP_SYS_ADMIN 💥 exit default/test-pod /usr/bin/runc --systemd-cgroup --root=/run/runc create --bundle /run/containers/storage/overlay- containers/985efa094308160475b7202193509582a338377c89e121c6e230f4b0fe95fc61/userdata --pid-file /run/containers/storage/overlay- containers/985efa094308160475b7202193509582a338377c89e121c6e230f4b0fe95fc61/userdata/pidfile 985efa094308160475b7202193509582a338377c89e121c6e230f4b0fe95fc61 0 🛑 CAP_SYS_ADMIN 🚀 process default/test-pod /bin/sleep 365d 🛑 CAP_SYS_ADMIN 💥 exit default/test-pod /bin/sleep 365d SIGTERM 🛑 CAP_SYS_ADMIN

3 Generic tracing - File Access - deathstar tiefighter xwing Namespace: default kind-control-plane kind-worker kind-worker2 kind-worker3 deathstar A B Kubernetes ワークロード内のプロセスが /etc/ ディレクトリで読み取りまたは書き込みを実行するかどうかを観測 ① 事前に次スライドにあるトレーシングポリシーを適用する B ② kubectl exec コマンドで xwing Pod のコンテナに入ってから、vi コマンドで /etc/passwd ファイルを更新する ③ kubectl logs & tetra コマンドを連携して、コンテナ内で実行される状況を確認する B ④ 適用したトレーシングポリシーを削除する

3 カーネル関数が実行されたタイミングでフックされて、Tetragon がイベントを検知する仕組み

3 kprobe hook 概要 security_file_permission このフックは、ファイルへの読み書きアクセスを監視するために使用される。多くの異なるシステムコール（例：read, write, copy_file_range, sendfile）がこの種のアクセスで使用されるため、このフックはそれらすべてのシステムコールに共通の実行ポイントとなる。 security_mmap_file アプリケーションがファイルを直接、その仮想アドレス空間にマッピングする場合、このフックでそのマッピング操作を監視する。具体的なアクセスを捉えるのが困難なため、ファイルが仮想メモリにマッピングされた時点での監視が行われる。 security_path_truncate ファイルのサイズを変更する操作、たとえば truncate システムコールなど、が行われるときにこのフックが使用される。このような操作は、ファイルの内容を間接的に変更する可能性がある。これらのフックを使用することで、ファイルへの様々なタイプのアクセスを効率的に監視することができる。

3 $ kubectl apply -f https://raw.githubusercontent.com/cilium/tetragon/main/examples/tracingpolicy/sys_write_follow_fd_prefix.yaml Apply the following TracingPolicy Generic tracing - File Access - Console B tracingpolicy.cilium.io/sys-read-follow-prefix created $ kubectl exec -it xwing -- /bin/bash kubectl exec into the xwing pod bash-4.3# vi /etc/passwd

3 $ kubectl logs -n kube-system -l app.kubernetes.io/name=tetragon -c export-stdout -f | tetra getevents -o compact --namespace default --pod xwing Monitoring the events from the xwing pod Console A 🚀 process default/xwing /usr/bin/vi /etc/passwd 📬 open default/xwing /usr/bin/vi /etc/passwd 📪 close default/xwing /usr/bin/vi 📬 open default/xwing /usr/bin/vi /etc/passwd 📝 write default/xwing /usr/bin/vi /etc/passwd 1274 bytes 📪 close default/xwing /usr/bin/vi 💥 exit default/xwing /usr/bin/vi /etc/passwd 0 Generic tracing - File Access -

3 $ kubectl logs -n kube-system -l app.kubernetes.io/name=tetragon -c export-stdout -f | jq 'select(.process_kprobe.process.pod.name=="xwing" or .process_kprobe.process.pod.name=="xwing")' 出力されるイベントログの詳細は JSON 形式で確認可能 Process Kprobe Event の一部

3 $ kubectl delete -f https://raw.githubusercontent.com/cilium/tetragon/main/examples/tracingpolicy/sys_write_follow_fd_prefix.yaml To disable the TracingPolicy run Console B tracingpolicy.cilium.io "sys-read-follow-prefix" deleted Generic tracing - File Access -

3 Generic tracing - Network Observability - deathstar tiefighter xwing Namespace: default kind-control-plane kind-worker kind-worker2 kind-worker3 deathstar A B kprobe フックを使用して TCP 接続を観測 ① 事前に次スライドにあるトレーシングポリシーを適用する B ② kubectl exec コマンドで xwing Pod のコンテナに入ってから、curl コマンドで http://cilium.io/ へアクセスする ③ kubectl logs & tetra コマンドを連携して、コンテナ内で実行される状況を確認する B ④ 適用したトレーシングポリシーを削除する

3 カーネル関数が実行されたタイミングでフックされて、Tetragon がイベントを検知する仕組み tcp_sedmsg 関数 args フィールドで引数情報を定義 int tcp_sendmsg(strct sock *sk, struct msghdr *msg, size_tsize) sk (index: 0) size (index: 2)

3 Generic tracing - Network Observability - $ kubectl apply -f https://raw.githubusercontent.com/cilium/tetragon/main/examples/tracingpolicy/tcp-connect.yaml Apply the example TCP connect TracingPolicy Console B tracingpolicy.cilium.io/connect created $ kubectl exec -it xwing -- curl http://cilium.io kubectl exec into the xwing pod Redirecting to https://cilium.io/

3 $ kubectl logs -n kube-system -l app.kubernetes.io/name=tetragon -c export-stdout -f | tetra getevents -o compact --namespace default --pod xwing Monitoring the events from the xwing pod Console A 🚀 process default/xwing /usr/bin/curl http://cilium.io 🔌 connect default/xwing /usr/bin/curl tcp 10.0.10.175:38386 -> 104.198.14.52:80 📤 sendmsg default/xwing /usr/bin/curl tcp 10.0.10.175:38386 -> 104.198.14.52:80 bytes 73 🧹 close default/xwing /usr/bin/curl tcp 10.0.10.175:38386 -> 104.198.14.52:80 💥 exit default/xwing /usr/bin/curl http://cilium.io 0 Generic tracing - Network Observability -

3 $ kubectl logs -n kube-system -l app.kubernetes.io/name=tetragon -c export-stdout -f | jq 'select(.process_kprobe.process.pod.name=="xwing" or .process_kprobe.process.pod.name=="xwing")' 出力されるイベントログの詳細は JSON 形式で確認可能 Process Kprobe Event の一部

3 $ kubectl delete -f https://raw.githubusercontent.com/cilium/tetragon/main/examples/tracingpolicy/tcp-connect.yaml To disable the TracingPolicy run Console B tracingpolicy.cilium.io "connect" deleted Generic tracing - Network Observability -

Copyright © 2023, Oracle and/or its affiliates 123 参考資料 eBPF
は何が嬉しいのか? https://speakerdeck.com/yutarohayakawa/ebpfhahe-gaxi-siinoka KubeCon + CloudNativeCon EU 2022 Recap https://speakerdeck.com/masayaaoyama/k8sjp51-kubecon-eu-2022-recap https://speakerdeck.com/tobachi/container-runtime-security-with-ebpf eBPF で実現するコンテナランタイムセキュリティ https://speakerdeck.com/chikuwait/learn-ebpf 「おいしくてつよくなる」 eBPF のはじめかた https://speakerdeck.com/cloudace/saidokahurina-service-mesh-dearu-cilium- gaqi-ninarunodeyusukesuwokao-etemita サイドカーフリーな Service Mesh である Cilium が気になるのでユースケースを考えてみた。

eBPF Introduction

eBPF Introduction

More Decks by oracle4engineer

Other Decks in Technology

Featured

Transcript