コンテナのセキュリティと可視性が強化された GKE Dataplane V2 が登場

※この投稿は米国時間 2020 年 8 月 20 日に、Google Cloud blog に投稿されたものの抄訳です。

Kubernetes が持つ「特殊能力」の 1 つに、デベロッパーファーストなネットワーキング モデルがあります。トラフィックをクラスタに送信する L3/L4 サービスや L7 Ingress などの使いやすい機能や、マルチテナント ワークロードを分離するネットワーク ポリシーを備えています。Kubernetes を採用する企業が増えるにつれて、あらゆるユースケースが拡大し、マルチクラウド、セキュリティ、可視性、スケーラビリティに関する新しい要件が増えてきました。さらに、サービス メッシュやサーバーレスといった新しいテクノロジーにより、基盤となる Kubernetes のレイヤをカスタマイズする必要性が高まっています。こうした新しい要件には共通点があります。つまり、パフォーマンスを犠牲にすることなく Kubernetes に対応したパケット操作ができる、プログラミングしやすいデータプレーンが求められているということです。

Extended Berkeley Packet Filter（eBPF）の利用は有効です。これはプログラム可能なフックを Linux カーネル内のネットワーク スタックに提供する、Linux の新しいネットワーキングの仕組みです。ユーザー空間とカーネル空間を行ったり来たりすることなく、ユーザー空間情報でカーネルを拡張するとともに、ネットワーク パケットでのコンテキストアウェアかつ迅速なオペレーションを可能にします。

本日、Google は eBPF や Cilium を活用した独自のデータプレーンである GKE Dataplane V2 を発表します。Cilium は、eBPF を活用して Linux カーネルを Kubernetes に対応させるオープンソース プロジェクトです。Dataplane V2 は現在ベータ版です。今後は、Google Kubernetes Engine（GKE）の Kubernetes ネットワーク ポリシー ロギングとしても使用されます。

eBPF と Cilium について

eBPF は、カーネルの再コンパイルやカーネル モジュールの読み込みをせずに、Linux カーネルでサンドボックス プログラムを実行できる革新的なテクノロジーです。以前ならカーネルの変更やカーネル モジュールに依存していた問題への対処でも、ここ数年は eBPF が標準的な方法になっています。さらに eBPF によって、ネットワーキング、セキュリティ、アプリケーション プロファイリングなどの分野における新世代のツールの開発が進みました。これらのツールがあれば、既存のカーネルの機能に頼る必要はなくなり、ランタイムの動作を積極的に再プログラムでき、実行効率や安全性を損なうこともありません。

Cilium は、コンテナ ワークロードのスケーラビリティ、セキュリティ、可視性に関する新たな要件に対応するため、eBPF を基礎として設計されたオープンソース プロジェクトです。Cilium は従来の Container Networking Interface（CNI）の枠を超え、サービスの解決やポリシーの適用など、下の図に示す多くのケースで役立ちます。

Cilium プロジェクトは、Kubernetes への eBPF の実装では特に完成度の高いものです。Cilium のコミュニティはこのプロジェクトのブートストラップに多大な努力を払ってきました。eBPF によって新たにもたらされるものを Kubernetes コミュニティ全体で活用できるようにするため、Google は Cilium プロジェクトに積極的に貢献しています。

eBPF を活用した Kubernetes ネットワーク ポリシー ロギングの構築

私たちが実際にお客様の問題を解決する際、eBPF がどのように役立っているか、実例を見てみましょう。セキュリティを重視するお客様は、Pod が相互通信する方法を宣言するのに Kubernetes ネットワーク ポリシーを使用します。しかし、これらのポリシーは、動作のトラブルシューティングや監査を行うスケーラブルな方法がないため、企業のお客様の利用には適していません。それでも、GKE で eBPF を利用できるようになったことで、リアルタイムでポリシーを適用するとともに、ノードの CPU とメモリリソースへの影響を最小限に抑えつつ、ポリシーの動作（許可 / 拒否）を Pod、Namespace、ラインレートのポリシー名に関連付けられるようになりました。

上の画像は、高度にカスタマイズされた eBPF プログラムが Linux カーネルにインストールされ、ネットワーク ポリシーを適用し、処理のログを報告する仕組みを示したものです。パケットが VM に送られると、カーネルにインストールされた eBPF プログラムが、パケットをルーティングする方法を決定します。eBPF プログラムは iptables と違い、ネットワーク ポリシー情報など、Kubernetes 固有のメタデータへのアクセスが可能です。これにより、パケットを許可または拒否できるだけでなく、アノテーション付きの処理をユーザー空間に報告できます。こうしたイベントにより、Kubernetes ユーザーにとって意味のあるネットワーク ポリシー ログを生成できるのです。たとえば下記のログスニペットは、どの送信元 Pod がどの宛先 Pod に接続しようとし、どのネットワーク ポリシーが接続を許可したのかを正確に示しています。

ネットワーク ポリシー ロギングが GKE Dataplane V2 を活用する仕組みをご紹介しましょう。GKE Dataplane V2 によって、ポリシー ロギングに必要な情報が提供されるだけでなく、ユーザーはネットワーク ポリシー適用を詳細に構成する必要がなくなります。つまり、Dataplane V2 を使用するユーザーは、ネットワーク ポリシーの適用を明示的に有効にする方法や、GKE クラスタでネットワーク ポリシーを使用するための CNI の選択で、もう悩むことはありません。まさに Kubernetes をさらに使いやすくした一例といえます。

ネットワーク ポリシーに加え、Kubernetes の負荷分散により、eBPF を利用して Direct Server Return（DSR）モードを実装できます。DSR は、Kubernetes LoadBalancer サービスを利用する際にクライアントの IP アドレスが失われるというNAT の問題を解決します。eBPF は臨機応変にメタデータをネットワーク パケットにエンコードできるため、宛先ノードに追加情報を提供して元のクライアントと直接通信させることができます。DSR で各ノードの帯域幅の要件を減らしたり、ポートの枯渇を防いだりすることもできます。

カスタム メタデータでネットワークを拡張できるという eBPF の利点により、想定されるユースケースの多くを実現できます。Kubernetes や eBPF の今後に対する期待を皆様と共有できれば幸いです。さらなるイノベーションについての続報をお待ちください。

活用方法

企業は常にインフラストラクチャの可視性を高め、セキュリティを改善することを目指しています。予期しない Pod のインターネット接続やサービス拒否攻撃など、異常なトラフィック パターンを素早く検出したいと考えています。Kubernetes ネットワーク ポリシー ロギングにより、許可されたか拒否されたかを問わずすべてのネットワーク接続を Cloud Logging コンソールで直接確認できるようになりました。これにより、ポリシーのトラブルシューティングや、異常なネットワーク アクティビティの発見が容易になります。

Kubernetes ネットワーク ポリシー ロギングを試すには、次のコマンドを使用して Dataplane V2 を有効にし、新しい GKE クラスタを作成してください。

^{このブログ投稿に協力してくれた Cilium プロジェクトの共同創設者、Thomas Graf 氏に Google より謝意を表します。}