All posts

Kubernetes Network Policies with Zscaler: Making Them Work Together

Packets were dying before they reached their target. Services were talking into the void. The cluster wasn't broken. The rules were. Kubernetes Network Policies decide which pods can talk, and which ones fall silent. Without them, traffic flows unchecked. With them, you gain control. But in real environments, policies rarely live alone. They coexist with cloud firewalls, zero trust platforms, and inspection gateways like Zscaler. The challenge is making them work as one. A Kubernetes Network P

Free White Paper

Kubernetes RBAC: The Complete Guide

Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.

Free. No spam. Unsubscribe anytime.

Packets were dying before they reached their target. Services were talking into the void. The cluster wasn't broken. The rules were.

Kubernetes Network Policies decide which pods can talk, and which ones fall silent. Without them, traffic flows unchecked. With them, you gain control. But in real environments, policies rarely live alone. They coexist with cloud firewalls, zero trust platforms, and inspection gateways like Zscaler. The challenge is making them work as one.

A Kubernetes Network Policy looks simple — a YAML definition of rules. Yet once Zscaler sits between your workloads and the internet, the story changes. Traffic routes through tunnels. DNS resolution shifts. IPs you thought you knew behave differently. Labels matter. Egress rules matter more. Any mismatch leaves workloads stranded.

The first step is mapping traffic. Find out which namespaces, pods, and services must connect outside the cluster. Identify the domains and IP ranges Zscaler enforces. In Kubernetes, egress policies need explicit destinations. Use Zscaler’s published IP ranges and update them whenever they change. Hardcoding addresses might buy you hours, but automation wins the week.

Continue reading? Get the full guide.

Kubernetes RBAC: Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

Next, work with default-deny in both ingress and egress policies. Create allowlists for exactly what needs to pass through Zscaler. Test each rule in isolation. Log everything. Kubernetes can’t see inside Zscaler tunnels, but it can confirm packets leave and return. Combine podSelectors and namespaceSelectors for precision.

For inbound flows from Zscaler, make sure the cluster nodes and CNI support the originating IP ranges. Some CNIs truncate source IPs with NAT, breaking policy matches. Avoid surprises by validating node configurations before rollout.

Policy audits are essential. Over time, application updates demand new destinations. Zscaler’s footprint evolves. Your rules must adapt. Integrate policy validation into CI workflows so broken routes show up in staging, not production.

Teams that get Kubernetes Network Policies and Zscaler working together have more than security. They have predictability. Outages from blocked traffic drop sharply. Compliance audits get easier. The mental load of “Will this request make it?” disappears.

You can see this working in real time. Build it. Test it. Watch traffic obey your rules. Try it now with hoop.dev and have it running live in minutes.

Get started

See hoop.dev in action

One gateway for every database, container, and AI agent. Deploy in minutes.

Get a demoMore posts