この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
prismatixのとばち（@toda_kk）です。
2022/8/5に開催されたオンラインテックカンファレンスCloudNative Security Conference 2022 by CloudNative Daysにて、「eBPFで実現するコンテナランタイムセキュリティ」をテーマに登壇しました。
アーカイブ動画
下記ページにアップロードされる予定です。
発表資料
セッション概要
eBPFはLinuxカーネルが提供する機能の一つで、近年、ネットワークやObservabilityといった文脈で注目を集めています。本セッションでは、セキュリティの観点から、eBPFを利用することで実現できることについて整理した上で、コンテナランタイムセキュリティを実現する具体的なeBPFツールとしてFalco、Tracee、Tetragonを紹介します。
ざっくりとした内容
セッション概要にもあるように、近年ではネットワークやObservabilityといった分野でeBPFという技術が注目されています。eBPFをセキュリティに利用する例として、コンテナランタイムセキュリティを実現する3つのOSSツールを紹介しました。
eBPFやBCCを利用したプログラミングについては、以前にもブログを書きました。
eBPFはいろいろできてパワフルな技術ではあるものの、普段AWSでインフラを構築したりWebアプリケーションを開発したりといった業務をやっている立場からすると、正直とっつきづらさがありました。Linuxカーネルとかよくわからんわけです。
そこで、自分のようにLinuxカーネルやシステムコールにあまり馴染みのないソフトウェアエンジニアでも、eBPFがどういうものなのか、何をやっていてどのように活用できるのか、わかりやすい資料が欲しいと思ったのが登壇のきっかけです。
また先日、弊社主催のオンラインイベントDevelopers IO 2022にて「OSSで始めるコンテナセキュリティ」をテーマに登壇しました。
自分のなかではDevelopers IO 2022のセッションの内容と今回の登壇内容は地続きになっていて、自分の関心に近いコンテナセキュリティをeBPFの活用事例ということにして、ランタイムセキュリティを提供するOSSを紹介してみよう、というセッションとなりました。
具体的には、Falco、Tracee、Tetragonという3つのOSSを紹介したのですが、これらは近しい機能を提供しているものの、それぞれどういった特徴があるのかを解説した資料がほとんどなかったので、今回の発表がそれなりに役に立つものになっていれば良いなあと思っています。
特にTetragonは今年の5月にOSSとして公開されたこともあり、日本語どころか英語でもあまり情報がなく調べるのに苦労しました。発表資料から、なんか頑張ってる感を感じ取っていただけますと幸いです。
いただいたご質問への回答
当日のセッションでは下記のご質問をいただいていました。
「falco/tracee はフィルタ/エンフォースメントのエンジンがユーザー空間で実装されているのに対して、tetragon はエンジンが BPF (kernel) で完結している」という理解は正しいでしょうか？
Tetragonのアーキテクチャを詳細まで追えていないのですが、ポリシーをKubernetes CRDやOPAで評価することになるので、Tetragonの場合もポリシーエンジンはユーザー空間で実行されるはずです。eBPFでイベントを検知した後、不正なプロセスに対してSIGKILLを送信することでEnforceを実現します。
また、発表後にTwitterで下記のようなコメントをいただきました。
Tetragonはちゃんと追う時間なかったので説明ありがたい。ただSIGKILLで殺すってことはファイルの書き込みなどの処理発生後に見えるけど防止できるんだろうか。#CNsec2022 #CNsec2022_B
— イスラエルいくべぇ (@knqyf263) August 5, 2022
なるほどありがとうございます。vimだとswapファイル作るのでkillされそうですが、いきなりechoとかで書き込んだらどうなるのかなというのが気になっていました(自分で試せ案件)
— イスラエルいくべぇ (@knqyf263) August 5, 2022
こちら、たしかに私も気になったので実際に動作確認してみました。
発表資料にも記載した方法でTetragon CLIを使ってイベント実行を出力しつつ、test-nginxに対して侵入した上でechoコマンドで/etc/passwdに書き込む操作を実行してみました。
echoコマンドによる/etc/passwdへの書き込み実行
$ kubectl exec test-nginx -it bash
root@test-nginx:/# echo test >> /etc/passwdすると、Tetragon CLIでは下記のように出力されました。SIGKILLの送信は行われておらず、/etc/passwdへの書き込みが正常に行われたように見えます。
Tetragon CLIの出力結果
? open default/test-nginx /bin/bash /etc/passwd
? close default/test-nginx /bin/bash実際にcatコマンドで/etc/passwdの内容を確認すると、上記内容が書き込まれていることが確認できます。
/etc/passwdへの書き込みが成功している
root@test-nginx:/# cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
# （中略）
nginx:x:101:101:nginx user,,,:/nonexistent:/bin/false
testセッションのなかでは、下記スライドに記載している内容でポリシーを定義して適用していました。echoコマンドを使ってファイルに対して書き込みを行う場合にはsys_writeがコールされないため、このポリシーに引っかからずにSIGKILLが送信されない、ということかと思われます。
ただ、echoを利用して書き込みを行うケースに対しても、適切にポリシーを定義すれば不正な操作を防ぐことができるのではないかと考えております。
こういった点も含めて、eBPFを扱うツールに関してカスタムポリシーなどを定義する際には、各コマンドの裏側で呼び出されるシステムコールが実行されるイベントについて知見が必要だなと感じています。
とはいえ、eBPFが強力な技術であることには間違いないので、可能な限りキャッチアップしながら実運用に活用していきたいですね。
以上、prismatixのとばち（@toda_kk）でした。
3
