Configure GKE network policies for AI service isolation

Introduction

When you deploy AI inference pipelines on GKE, every pod in the cluster can reach every other pod by default — a flat network that lets a compromised container access model-serving endpoints, cached embeddings, or proprietary weights without restriction. GKE network policies, enforced by Dataplane V2's eBPF layer, flip this to an allow-list model where each AI service namespace operates as an isolated security zone with controlled ingress and egress paths.

By the end of this lesson, you will be able to author default-deny policies and targeted allow rules that segment an AI platform's namespaces, restrict LLM gateway egress to specific model API CIDR ranges, and include the DNS egress rule that prevents opaque timeout failures.

Key Terminology

• Default-Deny Policy: A network policy with an empty pod selector and no ingress/egress rules that blocks all traffic to and from pods in the namespace, establishing a zero-trust baseline.
• Dataplane V2: GKE's eBPF-based networking layer that enforces network policies without requiring a separate CNI plugin like Calico, providing native policy enforcement with lower latency.
• Namespace Selector: A label-based matcher in network policy peers that restricts traffic sources or destinations to pods in specific namespaces, using the kubernetes.io/metadata.name label.
• Egress CIDR Block: An IP address range in CIDR notation (e.g., 104.18.0.0/16) that restricts outbound traffic to specific external endpoints, used to limit which model APIs an AI workload can reach.
• Policy Additivity: The Kubernetes network policy model where all policies are union-combined — there are no deny rules, only the default-deny baseline and explicit allow exceptions layered on top.

Concepts

GKE network policies are additive allow-rules layered over a default-deny baseline, so securing an AI gateway means composing a default-deny policy with explicit ingress and egress exceptions that pin the gateway to only the namespaces, ports, and CIDR ranges its model traffic legitimately requires.

Egress Hardening for External Model APIs

The broad 0.0.0.0/0 CIDR in the gateway egress policy is a pragmatic starting point, but production deployments must narrow this to specific IP ranges. Resolve the IP addresses of your model API providers periodically and update egress rules accordingly. OpenAI publishes endpoint IPs in their API documentation, and Google Cloud provides published IP ranges for Vertex AI endpoints. For Anthropic API calls, resolve api.anthropic.com and add the resulting CIDR blocks. Combine this network-layer restriction with Workload Identity to ensure that even if egress reaches an approved IP, the pod must present a valid GCP service account token — creating a dual authentication barrier that neither network compromise nor credential theft alone can bypass.

• DNS Policy Interaction: GKE Dataplane V2 evaluates network policies before DNS resolution. If your egress policy omits port 53 access to kube-dns, pods cannot resolve any hostname, and all external connections fail with opaque timeout errors rather than clear DNS failures. Always include an explicit DNS egress rule in every namespace that requires external access.

• Policy Evaluation Order: Kubernetes network policies are additive — there is no deny rule. The default-deny policy blocks everything, and each subsequent policy adds exceptions. This means you cannot create a policy that says "allow all egress except to the metadata server." Instead, you must enumerate all allowed destinations explicitly, which is more secure but requires careful maintenance as new services are added.

• Interaction with Binary Authorization: Network policies control where traffic flows, while Binary Authorization controls what code runs in those pods. Together, they ensure that only attested container images can communicate over approved network paths. A compromised CI/CD pipeline that produces an unauthorized image will be blocked by Binary Authorization before it can exploit any network policy exceptions.

• Falco Runtime Correlation: When Falco detects anomalous network activity — such as an AI workload pod opening a connection to an unexpected IP address — the network policy acts as the enforcement layer that blocks the connection while Falco generates the alert. Configure Falco rules to trigger on connect syscalls targeting IPs outside your approved egress CIDR list, creating a detection-and-prevention feedback loop.

Code Walkthrough

Now that you understand default-deny baselines, namespace selectors, egress CIDR blocks, and policy additivity, the following manifests apply those concepts to the ai-gateway namespace step by step.

Step 1 — Establish the zero-trust baseline. Apply a default-deny policy before adding any allow rules. An empty podSelector targets every pod in the namespace, and omitting ingress/egress rule lists causes Kubernetes to block all traffic:

Code snippetyaml
1apiVersion: networking.k8s.io/v1
2kind: NetworkPolicy
3metadata:
4  name: default-deny-all
5  namespace: ai-gateway
6spec:
7  podSelector: {}
8  policyTypes:
9    - Ingress
10    - Egress

Apply this with kubectl apply -f default-deny.yaml. At this point every pod in ai-gateway is isolated — no ingress, no egress, not even DNS. Policy additivity means this deny baseline is never overridden; subsequent policies only add exceptions on top.

Step 2 — Layer allow rules for the gateway. The gateway needs three egress paths: DNS resolution on port 53, the internal model-serving namespace on port 8080, and external model APIs on port 443. The kubernetes.io/metadata.name label acts as the namespace selector, and the egress CIDR block restricts outbound traffic to a specific IP range published by the model API provider:

Code snippetyaml
1apiVersion: networking.k8s.io/v1
2kind: NetworkPolicy
3metadata:
4  name: ai-gateway-allow
5  namespace: ai-gateway
6spec:
7  podSelector:
8    matchLabels:
9      app: llm-gateway
10  policyTypes:
11    - Ingress
12    - Egress
13  ingress:
14    - from:
15        - namespaceSelector:
16            matchLabels:
17              kubernetes.io/metadata.name: frontend
18          podSelector:
19            matchLabels:
20              app: web-frontend
21      ports:
22        - protocol: TCP
23          port: 8443
24  egress:
25    - ports:                        # DNS — must appear before any hostname resolves
26        - protocol: UDP
27          port: 53
28        - protocol: TCP
29          port: 53
30    - to:
31        - namespaceSelector:
32            matchLabels:
33              kubernetes.io/metadata.name: model-serving
34          podSelector:
35            matchLabels:
36              app: model-server
37      ports:
38        - protocol: TCP
39          port: 8080
40    - to:
41        - ipBlock:
42            cidr: 104.18.0.0/16    # Anthropic api.anthropic.com range (resolve periodically)
43        - ipBlock:
44            cidr: 104.18.1.0/24
45      ports:
46        - protocol: TCP
47          port: 443

GKE Dataplane V2 enforces both policies simultaneously via its eBPF layer. Because policies are additive, the deny baseline remains in effect; only the three egress paths and the single ingress path are open. Without the DNS egress stanza, pods resolve no hostnames and external connections fail with opaque timeouts rather than clear DNS errors — a common misconfiguration when the DNS interaction with policy evaluation order is overlooked.

Check that kubectl describe networkpolicy ai-gateway-allow -n ai-gateway lists all three egress rules and that a test pod in ai-gateway can reach https://api.anthropic.com on port 443 but is blocked from sending traffic to pods in vector-db or monitoring.

Do's and Don'ts

Now that you have worked through the implementation, the practices below separate a durable approach from a fragile one.

Do's

1. ✓Do apply the default-deny-all policy before any allow rules — because GKE network policies are additive and never override each other, the deny baseline must exist first; allow rules layered on top open only the exact paths you intend, and any pod brought up before the deny policy is in place briefly operates with full cluster access.
2. ✓Do include the DNS egress stanza (UDP/TCP port 53) in every allow policy — without it, pods in the namespace cannot resolve hostnames at all, and external connections to endpoints like api.anthropic.com fail with opaque timeouts rather than a clear DNS error, making the misconfiguration very hard to diagnose.
3. ✓Do use kubernetes.io/metadata.name namespace labels together with podSelector in the same from/to block — pairing namespaceSelector and podSelector in one array element restricts traffic to a specific app within a specific namespace (e.g., only app: web-frontend in frontend), whereas splitting them into separate list items creates an OR condition that opens access far wider than intended.

Don'ts

1. ✗Don't omit policyTypes: [Ingress, Egress] from a policy that intends to restrict both directions — a NetworkPolicy that lists only Ingress in policyTypes leaves egress completely uncontrolled for matched pods, so an llm-gateway pod could still exfiltrate data or reach unintended model endpoints even though ingress appears locked down.
2. ✗Don't use a hard-coded CIDR block without noting that it requires periodic re-resolution — the egress rule for 104.18.0.0/16 (Anthropic's range) is correct only as long as the provider's published IP range does not change; treating it as permanent causes silent breakage when the provider rotates IPs, and the DNS timeout symptoms will look identical to the missing-DNS-rule misconfiguration.
3. ✗Don't place namespace-selector allow rules in the ingress.from list as separate array elements when you intend AND semantics — writing namespaceSelector and podSelector as two sibling list items under from matches pods from the target namespace OR any pod with the matching label cluster-wide, granting the ai-gateway ingress on port 8443 from pods far outside the frontend namespace.