eBPFに基づくマイクロサービスネットワークセキュリティ
変換元:eBPFを使用したマイクロサービスのネットワークセキュリティ
一部のオープンソースのkubernetesツールはeBPFの使用を開始しており、これらのツールのほとんどはネットワーク、監視、セキュリティに関連しています。
この記事では、LinuxカーネルのBPFコンセプト、この機能をマイクロサービス環境に追加する利点、CiliumやWeaveなどの現在この機能を使用しているツールなど、eBPFのすべての側面をカバーするわけではありません。
eBPFを理解する
Berkely Packet Filters(略してBPF)は、1992年にSteven McCanneとVan Jacobsoによって最初に導入された命令セットです。これは通常、アプリケーション(tcpdumpなど)にパケットフィルタリングを提供するために使用され、長期間Linuxカーネルに残ります。
BPFは単純な仮想マシンと見なすことができ、そこから抽象化されたマシンには、レジスタ、スタックスペース、暗黙的なプログラムカウンター、およびカーネルの残りの部分と連携できるようにする補助関数の概念がいくつかあります。
カーネル内のVMは、bfpバイトコードを最下層が理解できる構造に変換し、パケットフィルタリング機能を提供します。
しかし、その前に、パケットフィルタリングを実行するために、パケットをユーザースペースにコピーする必要がありました。これにより、効率が低下し、リソースが大幅に浪費されます。
ベリファイアは、プログラムがループをトリガーするかどうかを検証し、プログラムを停止できることを保証します(無限ループはありません)。
近年、Linuxコミュニティは、従来のBPF(cBPF、機能はパケットフィルタリングと監視に限定されています)パーサーをカーネルから削除し、eBPFと呼ばれる新しい命令セットを導入しました。
拡張されたBPFにより、柔軟性とプログラミング性が向上し、追跡、bpfシステムコールの外部使用、カーネルメモリへの安全なアクセスまたは高速解析などの新しい使用シナリオが追加され、ジャストインタイム(JIT)コンパイラが更新されます、このマシンで実行されているプログラムのeBPFを変換します。
bpfプログラムを他のカーネルオブジェクトにアタッチすることもできます(cBPFは、ソケットフィルタリングのためにソケットにのみアタッチできます)。アタッチできるオブジェクトは、Kprobes、Tracepoints、Network schedules、XDP(eXpress Data Path)などです。XDPは、ユーザー空間とカーネル空間の間、または異なる場所で通信を提供できる共有データ構造(マップ)と組み合わせて使用されます。 BPFプログラム間で情報を共有します。
BPFプログラムを作成する
eBPFの重要な機能は、高級言語(Cなど)を使用してプログラムを実装できることです。LLVMには、eBPF命令を含むELFファイルを編集するためのeBPFバックエンドがあり、フロントエンド(clangなど)を使用してプログラムを生成できます。
バックエンドがバイトコードに変換された後、bpf()システムコールを使用してbpfプログラムをロードし、そのセキュリティを確認します。JITはバイトコードをCPUアーキテクチャにコンパイルし、プログラムをカーネルオブジェクトにアタッチします。これらのオブジェクトでイベントが発生すると、プログラムの実行がトリガーされます(たとえば、ネットワークインターフェイスからメッセージを送信するとき)。
以下の情報を参照して、eBPFプログラムを作成できます。
- clang / LLVMを使用してプログラムをコンパイルする
- BPFプログラムを作成するためのGoバインディング
- eBPFプログラムのロード、コンパイル、デバッグのためのユーティリティを提供するGoライブラリ
IPTablesでのコンテナーセキュリティ戦略
従来、コンテナのランタイムはDockerでしたが、セキュリティポリシーとNATルールは、コンテナホストでIPTablesを構成することによって実装されていました。
下の図には5つの段階があります。
- connect()システムコール
- メッセージを作成する
- vETHを介したメッセージの転送
- ホストにiptablesを適用する
- メッセージを破棄または転送する
iptablesを使用する場合、インスタンスごとにポリシーを構成できますが、レイヤー3とレイヤー4に対してのみ構成できます。転送する必要のあるパケットを処理するには、パケットを再構築する必要があり、iptablesエントリを処理する必要があります。
eBPFでのコンテナーセキュリティ戦略
eBPF戦略は、iptablesの使用に制限されることなく、プロトコルスタック全体またはパケット形成の前にシステムコール()に適用できます。eBPFはコンテナーネットワーク名前空間に接続されているため、すべての通信はeBPFによってインターセプトおよびフィルター処理されます。
さらに、プログラムレベルのアクションに基づいてセキュリティポリシーを適用できます。マイクロサービスごとに、L3とL4だけでなく、L7でもREST GET / POST / PUT / DELETEなどのポリシーを構成するか、/ service1、/ restrictedなどの特定のパスを指定できます。
iptablesをeBPFで置き換える
Linuxカーネルの貢献者の手から、カーネルコミュニティがiptablesを置き換える必要がある理由、 kubernetesのkube-proxyが直面する問題を理解する理由、またはコンテナー内のIPアドレスとポートに基づくポリシーを使用することがなぜ良い方法ではないのかを学びます。
eBPF機能を使用して実装されたオープンソースのkubernetesツールの一部は、高パフォーマンスと低遅延を実現し、特に監視、セキュリティ、ネットワーキングの分野で使用されます。
Cilium:動的ネットワーク制御と視覚化
Ciliumネットワークプロジェクトは、大量のBPFを使用して、コンテナベースのシステムにルーティングとネットワークトラフィックフィルタリングを提供します。カーネルを変更せずに動的にルールを生成および適用できます。
上記の例のL3 / L4ポリシーでは、app2がポート80経由でapp1にアクセスすることのみが許可され、app3がapp1にアクセスすることは許可されていません。
[{
endpointSelector: {matchLabels:{id:app1}},
ingress:[{
fromEndpoints:[
{matchLabels:{id:app2}}
],
toPorts:[{
ports:[{ports:80, protocol:tcp}]
}]
}]
}]
/パブリックパスへのアクセスを制限するが/制限付きパスへのアクセスを制限するなど、より厳密なセキュリティポリシーを使用することもできます。
Ciliumの仕組み
各ホストはエージェントを実行し、エージェントは(iptablesを管理する代わりに)ネットワークポリシー定義をBPFプログラムに変換します。これらのプログラムはカーネルに読み込まれ、コンテナの仮想イーサネットデバイスに接続されます。これらのプログラムが実行されると、送受信される各メッセージにこれらのルールが適用されます。
BPFはLinuxカーネルで実行されるため、アプリケーションコードやコンテナー構成を変更せずにCiliumのセキュリティポリシーを使用および更新できます。
もっと見る:
- API対応のネットワークとセキュリティ
- コンポーネントの概要
- Ciliumが2つのBPFを使用する方法を理解したい場合は、BPFおよびXDPリファレンスガイドを参照してください。
チップ:
-
繊毛のシステム要件は、よりに参加するために、カーネルのバージョン要件Linuxカーネル> = 4.9.17として、比較的高い公式文書
-
eBPFによる制限は比較的新しく、必要なカーネルバージョンはより高いため、kubernetesによって広く宣伝されていませんが、ネットワークソリューションは大きなトレンドです。現在、calicoはすでにeBPFモードをサポートしており(本番環境での使用は推奨されていません)、Alibaba CloudのTerwayプラグインもeBPFに基づいています。
-
詳細は公式ドキュメントをご覧ください