GKE の ClusterNetworkPolicy: マイクロサービスの制御と自律性のバランスを取る
Srini Jasti
Group Product Manager
Blaz Zupan
Software Engineer
※この投稿は米国時間 2026 年 8 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。
マルチテナントの Kubernetes 環境におけるネットワーク セキュリティの管理では、通常、2 つの異なるニーズのバランスを取ることが求められます。デベロッパーがマイクロサービス間で円滑な通信を確保したいと考える一方で、プラットフォームおよびセキュリティ チームは、コンプライアンスの維持、ラテラル ムーブメントの防止、そしてクラスタ全体のガードレールの確立を確実に行わなければなりません。
従来、これには標準の Kubernetes NetworkPolicy が主なツールとして使われてきました。標準の NetworkPolicy は、単一の名前空間を分離するには効果的ですが、そのスコープは個々の名前空間に厳密に限定されており、デベロッパーのセルフサービスを前提とした設計になっています。クラスタ管理者がグローバルなセキュリティ強化のために使用しようとすると、ポリシーの競合や運用上の課題が生じる可能性があります。
この問題に対処するため、Google は Kubernetes SIG-Policy ワーキング グループ（WG）が開発したオープンソース標準である ClusterNetworkPolicy（CNP）を Google Kubernetes Engine（GKE）に導入しました。大規模環境を想定して設計された CNP は、クラスタ全体のリソースです。これにより、管理者はネットワーク セキュリティを一元管理できるようになり、グローバル セキュリティの担当者が、一貫性のあるバイパスできないポリシーを実装するための仕組みを提供します。
CNP の技術的な詳細、一般的なユースケース、ポリシーの例、利用開始方法について、以下をご覧ください。
ティアによるポリシーの構造化
ClusterNetworkPolicy のコア機能は、その階層的なティア システムです。CNP は、フラットで競合するピアルールを同時に調整しようとするのではなく、決定論的なトップダウンの評価階層を確立します。
-
管理者ティア: 最も優先度の高いレベル。ここでのルールは、他のあらゆるポリシーよりも先に適用されます。
-
ネットワーク ポリシー ティア: 標準の名前空間レベル。デベロッパーが個々のアプリケーション ポリシーを管理します。
-
ベースライン ティア: 最も優先順位が低く、他のどのポリシーも適用されない場合のクラスタのデフォルト動作を規定します。これは、名前空間スコープのポリシーを使用でオーバーライドできます。
このティア構造により、ネットワーク セキュリティを組織の役割と整合させることができます。標準のロールベース アクセス制御（RBAC）を使用すると、管理者ティアを管理してコンプライアンス要件を適用できます。一方、プラットフォーム チームはベースライン ティアを使用して、クラスタ全体にデフォルトの「すべて拒否」ゼロトラスト体制を設定できます。同時に、デベロッパーはコア セキュリティ要件をオーバーライドすることなく、自身のアプリケーションに対して標準ネットワーク ポリシーを定義できます。
この決定論的なトップダウンの評価方法により、異なるチームのポリシー間の競合が解消されます。管理者ティアでは、明示的な Pass アクションが導入されています。これにより、セキュリティ チームはグローバル ルールに照らしてトラフィックを検査し、最終的な許可または拒否の決定をデベロッパーの名前空間ポリシーに委任できるため、中央での統制と分散管理の両立が容易になります。
一般的なネットワーク セキュリティ シナリオ
このティア アーキテクチャは、複雑なセキュリティ要件を一元化されたルールへと落とし込みます。ClusterNetworkPolicy が有効な解決策となる一般的なシナリオをいくつか紹介します。
-
機密性の高いワークロードの分離: 管理者ティアのグローバル拒否ルールを適用して、支払い処理やコンプライアンス データに使用される名前空間など、特定の名前空間をクラスタの他の部分から分離できます。このアクションは、放っておくとこれらの環境をさらしてしまう恐れのある、制限の緩いデベロッパー ポリシーをオーバーライドします。
-
コアサービスの保護: 内部運用に支障をきたすような構成を防ぐため、管理者は kube-dns などの重要なサービスに対して、管理者ティアのグローバル許可ルールを作成できます。これにより、名前空間ポリシーに構成ミスがあっても、これらのサービスへのアクセスを維持できます。
-
外部への下り（外向き）の管理: IP アドレス範囲のマッチングを利用することで、下り（外向き）トラフィックをクラスタレベルで制御できます。この機能を使用すると、企業イントラネットや外部 IP 範囲へのアクセスを明示的に制限または許可できるため、不正なデータの持ち出しに対する安全対策として機能します。
シナリオの例
一般的な企業の要件を考えてみましょう。すべての名前空間にわたるアプリケーション ワークロードは、中央のプラットフォーム インフラストラクチャ（共有認証サービスやテレメトリー サービスなど）へのアクセスが許可されている必要がありますが、その一方で、機密性の高い環境（制限付きの Vault 名前空間など）へのアクセスは厳格に禁止されます。その一方で、通常のマイクロサービス間のトラフィックは、デベロッパーが管理する名前空間スコープのポリシーに委ねられます。
ClusterNetworkPolicy を使えば、これを簡単に実現できます。プラットフォーム管理者は、管理者ティアのガードレールを次のように一元的に定義するだけです。
オープンソース基盤の拡張
Google は、この機能を独自の拡張機能として構築するのではなく、Kubernetes コミュニティと協力して ClusterNetworkPolicy API（policy.networking.k8s.io）を設計し、名前空間スコープの NetworkPolicy API（networking.k8s.io）と明確に区別しました。さらに、Cilium コミュニティと緊密に連携して、API の実装を構築しました。
GKE はオープンソース標準に基づいて構築されているため、セキュリティ構成をさまざまな環境に移植することが可能です。ClusterNetworkPolicy API は、ティアの選択をネイティブにサポートしているため、明確で決定論的なポリシー評価が可能です。このアプローチにより、管理者は堅牢なセキュリティ ガードレールを適用しながら、開発チームが必要とする運用上の柔軟性を維持できます。
GKE の ClusterNetworkPolicy は、ワークロードのネットワーク セキュリティを強化し、運用を名前空間スコープのルールから、クラスタ全体にわたる統合されたガバナンスに移行します。現在は、バージョン 1.36 以降でプレビューとして利用可能です。詳細と利用開始方法については、以下をご覧ください。
- グループ プロダクト マネージャー、Srini Jasti
- ソフトウェア エンジニア、Blaz Zupan
