GKE Dataplane V2 のネットワーク ポリシーを使用して Kubernetes のセキュリティ体制を強化する方法
Google Cloud Japan Team
※この投稿は米国時間 2023 年 3 月 4 日に、Google Cloud blog に投稿されたものの抄訳です。
Kubernetes を採用する組織が増えるにつれて、ワークロードを接続し保護するための新しいパラダイムも受け入れられるようになっています。境界防御だけに頼るのは、もはや効果的な戦略とはいえません。マイクロサービス アーキテクチャのパターンが急速に進化し続ける中、組織がアプリケーションとデータを保護し続けるには、多層防御戦略の採用が不可欠です。
大量のポートや API が公開されている、高度に分散された動的なシステムを効果的に管理するためには、従来のネットワーク境界にあるファイアウォール以上のものが組織にとって必要です。マイクロサービス間にある無数の接続により、不正なユーザーが、侵害されたコンテナ インスタンスを使用してネットワーク内を移動し、他のユーザーを攻撃して、カスケード障害や重大なデータ損失を引き起こす可能性があります。
幸いなことに、GKE と Anthos でマイクロサービスを実行している場合は、サードパーティ ソフトウェアのアドオンをインストールすることなく、一貫したネットワーク ポリシーの適用、ロギング、モニタリングを提供する GKE Dataplane V2 を使用できます。
GKE Dataplane V2: 概要と使用方法
GKE Dataplane V2 は eBPF（extended Berkeley Packet Filter）を統合しています。eBPF は、カーネルのソースコードを変更したり、モジュールを読み込んだりすることなく、アプリケーションが Linux カーネル空間でコードを実行できるようにする機能です。カーネルの機能を安全に拡張することで、通常のユーザー空間アプリケーションが Linux カーネル内で実行されるロジックを bytecode.* としてパッケージ化できるようにします。eBPF は画期的な技術であり、次のようないくつかの利点があります。
パフォーマンス - eBPF プログラムはカーネルで実行されるため、ユーザー空間プログラムよりもはるかに高速です。
セキュリティ - eBPF プログラムはサンドボックス化されているため、基盤となるカーネル ソースコードは保護され、変更されません。
拡張可能 - eBPF はパワフルなツールであり、従来のカーネル プログラミングの手法では実現できなかった新しい機能を作成するために使用できます。
GKE Dataplane V2 は、eBPF と Cilium（eBPF をベースとしたオープンソース プロジェクト）の機能を活用することで、Kubernetes 固有のメタデータを使用して、カーネル内でネットワーク パケットを柔軟かつ効率的に処理します。GKE Dataplane V2 を使用すると、カーネル内の eBPF プログラムは、サービス ルーティングを kube-proxy や iptables に依存することなく、GKE ノードに到着するパケットをルーティングして処理できるため、ネットワーク パフォーマンスが大幅に向上します。また、GKE Dataplane V2 には、ネットワーク ポリシーの適用が組み込まれており、ネットワーク アクティビティをリアルタイムで可視化できるため、クラスタのセキュリティ体制を改善するのにも役立ちます。ネットワーク パケットはカーネル内で処理され、ロギングのためアノテーション付きのアクションをユーザー空間に報告できます。
（GKE バージョン 1.20.6-gke.700 以降で新しいクラスタを作成する場合は、GKE Dataplane V2 を有効にできます。可用性については、こちらをご覧ください。）
GKE Dataplane V2 でネットワーク ポリシーを使用して、受信トラフィックを受け取る Pod を制御する方法の例を見てみましょう。Pod 間の接続を制限できるようにすることで、ネットワーク ポリシーは影響範囲を縮小し、セキュリティを強化できます。まず、以下のコマンドを使用して、Dataplane V2 を有効にした GKE クラスタを作成します。
こちらで GCP リポジトリのクローンを作成し、kubectl でマニフェストを適用します。以下を実行します。
クラスタで redis-cluster サービスが実行されていることがわかります。
次に、不正なユーザーがクラスタにアクセスし、別の redis コンテナ イメージを起動してデータを盗み、サービスを混乱させる方法について示します。
不正なユーザーのコンテナのプロンプトで、以下を実行します。
次のようなレスポンスが返されます。
これにより、不正なユーザーが、サービスとデータに違法にアクセスしている可能性があることが確認されました。
次に、NetworkPolicy を構成し、バックエンド Pod から redis-service Pod へのトラフィックのみを許可します。それ以外の redis Pod への受信トラフィックはすべてブロックされる必要があります。
次に、上記の NetworkPolicy をクラスタに適用します。
ここで、不正なユーザーのコンテナのプロンプトから、再度同じリクエストを実行します。
上記のリクエストがハングしていることがわかります。シェルを終了します。
下の図は、redis-allow-from-backend ポリシーが、redis-cluster サービスへの 2 つの接続に与える影響を示しています。ネットワーク ポリシーは、バックエンド Pod からの接続のみを許可します。redis-cluster サービスへの他のすべての受信リクエストは、そうしたリクエストを許可するネットワーク ポリシーがないため拒否されます。
NetworkPolicy の適用により、不正なユーザーがデータにアクセスできなくなったとしても、クラスタを静かに探っている可能性はぬぐいきれません。そのため、不正アクセスを防止するだけでなく、アラートや分析を行えるように、そのような活動をログに記録する必要もあります。GKE はデフォルトで、新しい Dataplane V2 クラスタに NetworkLogging オブジェクトを作成します。クラスタの NetworkLogging オブジェクトを編集することで、ネットワーク ロギング設定を構成できます。上述の例を使用し、拒否されたすべての接続をログに記録するために、以下を実行します。
ネットワーク ポリシー ログは、Cloud Logging に自動的にアップロードされるため、ネットワークトラフィックを検索して分析し、悪意のあるネットワーク アクティビティや不正なネットワーク アクティビティを発見できます（迅速に対処できるようにアラートを設定することもできます）。
まとめ
GKE Dataplane V2 を使用すると、クラスタ ネットワーキングを最適化し、ワークロードを簡単に接続して保護することができます。ネットワーク ポリシーの適用とロギング機能が組み込まれているため、サードパーティ ソフトウェア アドオンに依存する必要はありません。GKE Dataplane V2 なら、イノベーションを犠牲にすることなく、ネットワークを簡単に保護できます。
詳細:
- 戦略カスタマー エンジニア Bon Sethi
