Google CloudがClusterNetworkPolicyの構成例を紹介、プレビュー版で3層の通信制御が可能

ClusterNetworkPolicy（プレビュー）の3層評価

GKEのClusterNetworkPolicy（プレビュー、アルファ版レベル）は、Admin層、NetworkPolicy層、Baseline層の順に通信を評価します。Admin層やBaseline層のルールで許可か拒否に一致すると、その時点で評価が止まる仕組みです。^[1][2]

図1　GKEのCNPの層ごとの判定（プレビュー）

このプレビュー版では、最上位のAdmin層に、メタデータへのアクセスの遮断のように、バイパスできない必須のセキュリティルールをクラスタ管理者が置きます。最下位のBaseline層は、Namespace間の既定拒否のように、クラスタ管理者がフォールバックの既定を置く層です。

中位のNetworkPolicy層は、アプリチームが管理する標準のNamespaceスコープのポリシーで、マイクロサービスの入出力を制御します。プレビュー版では、どの層にも一致しない通信はGKEの既定の動作として暗黙的に許可されます。

図2　ルールの3つの動作（プレビュー、アルファ版レベル）

Passは、包括的な管理を手放さずに、特定の通信の判断を標準のNamespaceレベルのポリシーへ委ねる動作です。層の中では0～1000の優先度でポリシーを評価し、数値が小さいほど優先されます。

ClusterNetworkPolicy（プレビュー）の構成例

GKEのClusterNetworkPolicy（プレビュー、アルファ版レベル）のマニフェストは、kubectl apply -fでクラスタへ適用します。構成例はCodelab「Secure AI Inference Workloads with GKE ClusterNetworkPolicy」で試せます。^[1][2]

図3　構成例で各層に置くポリシー（プレビュー）

プレビューの構成例の目的は、LLMのNamespaceへの通信を許可済みクライアントだけに絞ることです。あわせて、DNSの53番ポートを除き、メタデータAPIへのクラスタ全体からのアクセスを防ぎます。

Kubernetesでは既定で、Namespace間の通信と外向きの通信がすべて開いています。構成例は多層防御のため、GKEの評価層ごとにネットワークポリシーを適用する構成です。

Codelabの検証環境の構成

プレビューの構成例では、軽量オープンモデルのGemma 4（google/gemma-4-E2B-it）をvLLMで動かし、機密性の高いAIワークロードに見立てます。3つのNamespaceでPodを分け、client-nsではモデルに問い合わせる許可済みのチャットクライアントを動かします。

図4　構成例の3つのNamespace（プレビュー）

検証環境は、多層のネットワークポリシーを適用するGKE Dataplane V2（ADVANCED_DATAPATH）を使うGKE Standardクラスタです。TPU v5eのノードプールはct5lp-hightpu-4tの2x2構成で、taintによりアクセラレータのワークロードだけを動かします。

構成例のCloud Logging / GKE Network Policy Loggingは、許可と拒否のパケット判定をリアルタイムに捉えます。ポリシーの監査証跡も得る機能です。

Baseline層での未許可入力の拒否

プレビューの構成例では最初に、クラスタ管理者がフォールバックの安全網としてBaseline層にClusterNetworkPolicyを置きます。このポリシーの2つ目のルールが受信するPod間の接続を破棄し、client-nsとuntrusted-tenantのどちらもGemmaへ接続できない状態です。

図5　Baseline層に置く拒否ルール（プレビュー）

全Namespaceを対象にするBaseline層のマニフェスト（v1alpha2）は、次の通りです。

apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: baseline-default-deny
spec:
  tier: Baseline
  priority: 1000
  subject:
    namespaces: {}
  ingress:
    - name: allow-dns-ingress
      action: Accept
      from:
        - namespaces: {}
      protocols:
        - udp:
            destinationPort:
              number: 53
        - tcp:
            destinationPort:
              number: 53
    - name: baseline-deny-cross-ns
      action: Deny
      from:
        - namespaces: {}

公式資料からの抜粋：Experimenting with ClusterNetworkPolicy in GKE（Securing the LLM and metadata: Code walkthrough / Step 1: Establish zero-trust posture (baseline tier)）。対象版・範囲：GKEのClusterNetworkPolicy（プレビュー、policy.networking.k8s.io/v1alpha2）の構成例。

上記のコードでは、priority: 1000でBaseline層の中の順序を決めています。allow-dns-ingressでUDPとTCPの宛先53番ポートへの入力を受け入れ、残りのPod間の入力はDenyで拒否する構成です。

tier: Baselineのポリシーは評価の最後に置かれ、上の層で一致しなかった通信だけを扱います。53番ポートの例外がないと、クラスタ全体の名前解決が失敗します。

NetworkPolicy層の許可

プレビューの構成例では、Baselineの既定拒否が有効な状態で、gemma-llmを管理するアプリチームが正当なクライアントへアクセスを委任します。標準NetworkPolicyは、client-nsのapp: rag-agent PodからのTCP 8000番の入力だけを許可します。

図6　接続元ごとの判定（プレビュー）

標準NetworkPolicyはgemma-llm Namespaceに置かれ、対象はapp: gemma-serviceのラベルを持つPodです。標準のNetworkPolicyが対応するNetworkPolicy層は、Baseline層より先に評価されます。

Admin層の外向きガードレール

構成例（プレビュー）の前提として、GKEのPodは既定で、リンクローカルのCompute Engineメタデータサーバー（169.254.169.254）に問い合わせできます。この問い合わせにより、インスタンスのメタデータや高い権限を持つ可能性があるサービスアカウントのトークンが露出します。

図7　構成例のPodとメタデータサーバー（プレビュー）

プレビューの構成例では、クラスタ管理者が置くガードレールの層は、最初に評価されるAdmin層です。priority: 10で層の中の順序を決め、subject.namespaces: {}でクラスタ内の全Namespaceを対象にしています。

図8　Admin層の外向きガードレール（プレビュー）

Admin層のルールごとの動作

delegate-all-ingressとdelegate-other-egressのルールは、action: Passで残りのクラスタ内の通信の評価を次の層へ渡します。DNS以外のポートで169.254.169.254/32へ問い合わせるとAdmin層で破棄され、開発者が外向きをすべて許可するポリシーを置いても回避できません。

図9　構成例のAdmin層のルール（プレビュー）

allow-all-dnsのルールは、0.0.0.0/0宛てのUDPとTCPの53番ポートを受け入れます。この許可により、PodはDNSによる名前解決ができます。

ポリシー判定の確認手段

Google Cloudブログの投稿者は、GKE Dataplane V2に組み込まれたテレメトリ機能で、ポリシーの検証と監査は容易だとしています。Hubbleのストリームでは、管理者がサイドカーなしでフローとポリシーの判定をリアルタイムに観察できます。

図10　ポリシーの調整状態と判定の確認手段（プレビュー）

GKE Network LoggingとCloud Loggingは、構造化された接続のテレメトリとポリシーの適用判定をCloud Loggingへ自動で書き出す仕組みです。判定はdisposition="deny"などの属性で、絞り込みやアラートに使えます。

ClusterNetworkPolicyの状態は、kubectlで確かめられます。一覧表示のコマンドは次の通りです。

kubectl get clusternetworkpolicies

公式資料からの抜粋：クラスタ ネットワーク ポリシーを構成する（トラブルシューティング）。対象版・範囲：GKEのClusterNetworkPolicy（プレビュー、アルファ版レベル）。

上記のコマンドは、クラスタ内のプレビュー（アルファ版レベル）のClusterNetworkPolicyを一覧表示します。kubectl describeでは、status.conditionsで調整の成否が分かります。

ClusterNetworkPolicyの利用条件

ClusterNetworkPolicy APIはプレビュー版であり、APIのレベルとしてはアルファ版に当たります。利用には、バージョン1.36.0-gke.4447000以降のGKEクラスタと、GKE Dataplane V2の使用が前提です。^[2]

図11　利用前に確かめる条件（プレビュー）

ClusterNetworkPolicyは一般提供前のサービス規約の対象で、pre-GAの機能は「現状のまま」提供され、サポートが制限される場合があります。CustomResourceDefinitionは、今後のバージョンで変更される可能性がある状態です。

Google Cloudブログの投稿者は、GKEでプレビューのClusterNetworkPolicyは役立つ場合があるとしています。本番環境で使う場合は、構成に合わせてルールを計画し、設計する必要があるという見解です。^[1][2]

プレビュー版CNPの層の選び方

GKEのClusterNetworkPolicy（プレビュー）では、ルールを置く層によって、Namespace側のポリシーで上書きできるかが変わります。編集部は、上書きの可否と管理する担当を、層を選ぶ目安として整理しました。^[1][2][3]

図12　GKEのCNPの3つの層（プレビュー）

GKEのClusterNetworkPolicy（プレビュー）では、開発者のポリシーで回避されてはならないルールはAdmin層に置くのが目安です。機密性の高いNamespaceの分離やkube-dnsへのグローバル許可、メタデータサーバーへのアクセス遮断が該当します。