A security review may find that a payments API reaches more workloads than planned. Traffic may be inconsistently encrypted. Audit logs may not show which workload called a sensitive service.
For K8s NetworkPolicy vs Service Mesh for Zero Trust, NetworkPolicy limits pod traffic at L3/L4. A mesh adds workload identity, mTLS, and L7 authorization. The best choice is often both layers. But the real issue is mapping each control to a specific risk.
Choose controls by the risk you must reduce
Kubernetes NetworkPolicy is enough when you only need to limit pods, ports, and network ranges. A service mesh is needed for cryptographic service identity. It is also needed for encrypted east-west traffic or HTTP-based authorization.
NIST SP 800-207 defines Zero Trust Architecture as a set of continuously enforced controls. It does not define Zero Trust as one network feature. This matters when teams debate tools instead of risks.
NetworkPolicy limits a route; a service mesh proves who uses that route.
Think of NetworkPolicy as a building badge. It opens a floor and a room. A mesh is the guard at the room door. The guard checks the badge, encrypts the conversation, and limits the visit.
Start with CNI-enforced NetworkPolicy for default-deny segmentation. Add a mesh where identity, mTLS, or Layer 7 policy changes risk. This avoids adding proxies to every pod just to block one TCP port.
Map each requirement to one control
| Zero Trust requirement | NetworkPolicy | Service mesh | Best fit |
|---|
| Pod and port segmentation | L3/L4 allow rules | Usually indirect | CNI plus NetworkPolicy |
| Workload identity | Labels, not cryptographic proof | Service identity and certificates | Mesh or SPIFFE/SPIRE |
| Traffic encryption | No native mTLS | mTLS for enrolled traffic | Mesh |
| HTTP and gRPC authorization | Cannot inspect requests | Method, path, claims, principal | Mesh |
| Non-mesh TCP or UDP isolation | Strong if CNI supports it | May not cover traffic | NetworkPolicy |
| Audit evidence and traces | Depends on CNI flow logs | Request-level telemetry | Combined design |
Measure overhead instead of guessing
A basic NetworkPolicy adds no application proxy hop. Sidecar meshes add a local proxy. Test them with real payload sizes, connection counts, and CPU limits.
The effect ranges from negligible to material for latency-sensitive services. Test p50, p95, and p99 latency. Test CPU and memory limits during peak traffic.
Do not assume every mesh has the same cost.
Ambient mesh and eBPF platforms can reduce some per-pod cost. Lower overhead does not mean equal policy coverage. Your CNI determines what a NetworkPolicy actually enforces.
Workload identity, workload authentication, and user authentication are separate controls. NetworkPolicy segments pod-to-pod traffic. It does not authenticate the calling workload.
In a mesh, mTLS uses service identity certificates. These certificates authenticate enrolled workloads and encrypt east-west traffic. This differs from checking a user JWT or OAuth token.
For example, mTLS can prove that checkout called payment. The payment API must still check whether the customer can submit a charge. The next section shows why CNI choice is a security decision.
NetworkPolicy is not a universal firewall
Kubernetes defines the NetworkPolicy API. Kubernetes does not enforce it by itself. The CNI connects pods and determines whether it enforces policy.
The CNI may support ingress, egress, logs, FQDN rules, or vendor deny features. Calico, Cilium, AWS, Google Cloud, and Microsoft Azure can produce different results. The same YAML may not behave identically everywhere.
A NetworkPolicy without an enforcing CNI is documentation, not protection.
Confirm enforcement before calling a policy a PCI DSS, HIPAA, SOC 2, FISMA, or segmentation control. Test denied traffic from a real pod. Also save the test result as evidence.
The most common error is assuming restrictive policies override broad permissions. Kubernetes policies use additive allows. One matching allow can permit traffic despite another policy.
Start isolated, then add narrow paths
A default-deny policy selects pods and permits no ingress or egress paths. Other policies must add each allowed path. It is like locking every office door first.
Then you issue only the keys each job needs. This reduces accidental reachability. It also makes reviews easier.
Use separate ingress and egress policies. A reviewer can then answer two clear questions: Who may call this workload, and what may it call?
Selectors often match labels such as app: checkout. They may also match namespaces such as store. Labels help route traffic, but they are not cryptographic identities.
Labels become risky when teams can attach trusted labels without controls. Use admission control, protected namespaces, service accounts, RBAC, and policy-as-code reviews. These controls limit who can create or change labels.
Cilium and Calico may offer richer policy features. Document these extensions because they are not portable Kubernetes behavior. This distinction prevents teams from buying a mesh for simple L3/L4 isolation.
Match the design to your cluster context
A small cluster with one team and few internal services can gain strong segmentation with NetworkPolicy. It also needs disciplined namespace ownership. A multi-tenant cluster often needs more.
A regulated payment flow may need identity-aware mesh controls. So may an HTTP or gRPC estate needing caller-aware rules. The key difference is the decision being enforced.
Use a mesh when policy must distinguish callers sharing one network destination.
If checkout may call POST /charge, but catalog may not, a TCP rule cannot express that difference. Both callers can reach the same port. Only a Layer 7 rule can separate the requests.
For U.S. Federal systems, OMB M-22-09 and CISA's Zero Trust Maturity Model stress identity and visibility. They also stress policy enforcement. They do not require Istio, Linkerd, Cilium, or one named tool.
Use traffic type as the first branch
HTTP and gRPC traffic are good mesh candidates. A proxy can inspect methods, paths, headers, and authenticated principals. Opaque TCP and UDP traffic often benefit first from L3/L4 policy.
Databases, DNS, and infrastructure services commonly need careful network rules. North-south traffic enters through an ingress controller, API gateway, or egress gateway. East-west traffic moves between internal pods.
NetworkPolicy and mesh controls can overlap usefully for east-west traffic. One limits paths. The other can verify identity and request details.
Use regulation as an evidence test
PCI DSS, HIPAA, and SOC 2 do not say mTLS alone proves compliance. Auditors often need proof that segmentation works. They also need least privilege, encryption, logs, and reviewed policy changes.
NIST SP 800-190 covers container security risks. It complements NIST SP 800-207. A mesh can create request-level evidence, while CNI logs show connection-level evidence.
High-value workloads often need both kinds of evidence.
Decision rule: Choose NetworkPolicy alone for proven L3/L4 isolation needs. Combine it with a mesh for service identity, mTLS, or HTTP/gRPC authorization. Do not add a full mesh to a small proof of concept without those requirements.
Choose controls by the decision they can enforce. The next section turns that choice into one testable business flow.
Apply both layers to one business flow
A layered policy expresses one business dependency twice. NetworkPolicy allows the network path. Mesh policy authenticates, encrypts, and authorizes the application call.
Consider frontend calling checkout on TCP 8080. Then checkout calls payment on port 8443. Each layer answers a different question.
Network reachability does not authorize a business action.
A payment service may accept a connection from checkout. It can still reject every request except POST /charge. This is where Layer 7 authorization earns its added cost.
Start with one narrow flow tied to revenue. Test denied calls on purpose. This exposes gaps before dozens of services create an unclear dependency graph.
For most production clusters, use both layers for high-value HTTP services. Use NetworkPolicy for baseline isolation. Add mesh controls only where caller identity, mTLS, or request rules alter risk.
This approach does not fit every case. A small proof of concept may need only basic isolation. A mesh becomes justified when requirements demand proof of workload identity or encrypted service traffic.
Limit the route with NetworkPolicy
yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: payment-ingress
namespace: store
spec:
podSelector:
matchLabels:
app: payment
policyTypes: [Ingress]
ingress:
- from:
- podSelector:
matchLabels:
app: checkout
ports:
- protocol: TCP
port: 8443
This policy limits access to app: checkout pods in the same namespace. Production policy should add an explicit namespace selector. It should also add a separate checkout egress policy.
That egress policy should allow DNS and an approved external provider. Include the DNS resolver. Include only required ports.
Require encrypted workload identity
yaml
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
name: payment-strict
namespace: store
spec:
selector:
matchLabels:
app: payment
mtls:
mode: STRICT
STRICT makes Istio reject plaintext connections to the selected payment workload. It encrypts enrolled traffic and authenticates enrolled workloads. Legacy jobs and external gateways need an approved transition path.
Monitoring agents may need that path too. Do not enable strict mTLS before finding these clients. Otherwise, a planned control can cause an outage.
Permit only the business action
yaml
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
name: payment-charge-only
namespace: store
spec:
selector:
matchLabels:
app: payment
rules:
- from:
- source:
principals: ["cluster.local/ns/store/sa/checkout"]
to:
- operation:
methods: ["POST"]
paths: ["/charge"]
This policy checks a service account-based principal and an HTTP operation. It shows the mesh advantage clearly. A TCP allow rule cannot inspect either value.
Ask for a policy review when teams cannot name service accounts, owners, and approved flows. That is often a design problem, not a tooling problem.
For frontend to checkout to payment, production needs more than the payment ingress rule. Set default-deny for checkout and payment. Allow frontend to reach only the checkout listener.
Add an egress NetworkPolicy for checkout. Allow only payment on TCP 8443. Also allow the approved DNS resolver on UDP and TCP 53.
Add payment egress rules only for required dependencies. A catalog pod should fail when connecting to payment. Checkout should fail on every unapproved port.
Authorized checkout requests are then subject to mTLS and HTTP authorization. This double check makes CNI enforcement testable. It also reveals the limits of mTLS alone.
mTLS is necessary but not sufficient
Mutual TLS, or mTLS, encrypts traffic in transit. It lets two participating workloads authenticate with certificates. It reduces passive interception and service spoofing for enrolled east-west traffic.
mTLS does not decide whether a valid workload may access every API endpoint. It does not decide whether it may read every database record. Authorization must make those decisions.
mTLS protects the conversation; authorization decides if that conversation should happen.
A compromised checkout service can still make a valid mTLS connection. AuthorizationPolicy and application rules must restrict its actions. This is a common blind spot during mesh evaluations.
Istio often manages certificates for mesh workloads. SPIFFE and SPIRE offer a portable model for workload identity. OWASP still lists broken access control and injection as separate application risks.
Authentication must be followed by policy
Use AuthorizationPolicy, JWT checks, RBAC, ABAC, and application checks for the actual decision. RBAC gives rights based on roles. ABAC checks traits such as tenant, region, or data class.
A valid service identity is not an end-user identity. Requests tied to a customer, clinician, or employee need that identity checked. Do not blindly trust an inbound header.
The error most often seen here is treating a service certificate as user authorization. It proves the caller workload. It does not prove the user's right to act.
Egress and secrets need separate controls
mTLS does not stop a compromised pod from sending data to an allowed hostile destination. It does not rotate database passwords. It also cannot stop secrets from appearing in logs.
Use egress policies, egress gateways, DNS controls, secret rotation, image patching, and central logs. Add runtime security where your risk requires it. NSA and CISA describe Zero Trust as defense in depth, not TLS alone.
Encryption is one lock, not the whole building.
These controls only help when they stay available during releases and incidents. That makes rollout order and dataplane choice security decisions.
Roll out safely and choose the dataplane
Safe default-deny rollout starts with real connection data, not diagrams. Capture source workload, destination workload, namespace, port, protocol, and DNS name. Record external services and business owners too.
Capture at least one normal operating cycle. Include scheduled jobs and failure recovery paths. A daily task can be as important as normal traffic.
Apply isolation in stages: observe, isolate ingress, restrict egress, enable mTLS, then enforce Layer 7 authorization.
Each stage needs health checks and expected denials. Each stage also needs rollback rules. Assign an owner who can explain every exception.
One common case involves a payment namespace. It works in staging but fails in production. A daily reconciliation job calls an external SaaS endpoint.
The policy looked correct during normal traffic. It blocked a business-critical dependency missing from the inventory. This is why observation must include scheduled work.
Allow CoreDNS, or your configured resolver, on UDP and TCP port 53. Do this before restrictive egress rules. Test kube-apiserver paths and admission webhooks too.
Test readiness probes, liveness probes, telemetry collectors, image registries, and gateways. Check ingress controllers, API gateways, and egress gateways. These flows often fail first.
CNI flow logs, distributed traces, and synthetic deny tests give stronger proof than one successful deployment. Test one forbidden caller and one forbidden port. Also test one plaintext connection and one denied HTTP path.
Compare sidecar, ambient, and eBPF
| Model | Proxy placement | mTLS and L7 policy | Primary tradeoff |
|---|
| Istio sidecar | Proxy beside each pod | Mature mTLS and detailed HTTP/gRPC controls | Per-pod resource and upgrade work |
| Istio ambient | Node transport plus optional waypoint | mTLS without every pod sidecar; L7 needs waypoint design | Feature and support validation |
| Cilium eBPF | Kernel-level dataplane | Strong L3/L4 policy and visibility; verify identity needs | Platform-specific operating skills |
Sidecars remain a good choice for mature request-level control and tracing. Ambient models can reduce sidecar injection work. eBPF can change the network baseline.
Neither model removes the need for exact protocol tests. Validate every denial case in scope. The final decision should map controls to your actual risk.
Do not add a full mesh for a small proof of concept without identity, mTLS, or Layer 7 requirements. Also delay this comparison if IAM, secret management, image patching, and central logging are still missing.
FAQs
Is kubernetes NetworkPolicy enough for zero trust?
Kubernetes NetworkPolicy is enough for L3/L4 microsegmentation when identity, mTLS, and Layer 7 authorization are unnecessary. Zero Trust also needs IAM, secrets, patching, logging, and workload risk controls.
Does a service mesh replace NetworkPolicy?
A service mesh does not fully replace NetworkPolicy because non-mesh pods and broad network boundaries still need L3/L4 control. Combined designs often protect high-value HTTP services with both layers.
What does istio strict mTLS actually protect?
Istio strict mTLS encrypts and authenticates traffic between enrolled workloads. It rejects plaintext traffic to the selected target. It does not authorize HTTP methods, protect stored secrets, or control external egress.
Why did default-deny break my kubernetes app?
Default-deny often breaks deployments because DNS, probes, telemetry, or gateway traffic lacked explicit rules. Check UDP and TCP port 53, readiness paths, and needed external destinations before restricting egress.
Can NetworkPolicy block a specific HTTP URL?
Standard Kubernetes NetworkPolicy cannot block a specific HTTP URL because it works at Layer 3 and Layer 4. Use a mesh or application policy for paths like /charge.
Does NetworkPolicy encrypt pod-to-pod traffic?
NetworkPolicy does not natively encrypt pod-to-pod traffic. Use mTLS in a mesh when encrypted east-west traffic is a stated requirement.
How do i test a kubernetes NetworkPolicy?
Test NetworkPolicy from real source pods with one allowed and one denied connection. Check the port, protocol, DNS access, and CNI flow logs.
Should i choose sidecar or ambient mesh?
Choose sidecars for mature request-level controls and tracing. Choose ambient only after testing its L7 needs, support status, and denial behavior for your workloads.
Make the decision based on enforceable risk
Choose NetworkPolicy as the base layer when you need pod, port, and network segmentation. It is often the lowest-risk first control. Verify that your CNI truly enforces it.
Add a mesh when a workload must prove its service identity. Add it when mTLS is required. Add it when policy must inspect HTTP methods, paths, or principals.
Do not treat mTLS as complete authorization. A valid workload certificate does not grant access to every action. Keep end-user checks and application authorization in place.
Roll out one business flow at a time. Test denied paths before broad rollout. Save the results for security reviews and audits.
The essential points:- NetworkPolicy provides L3/L4 segmentation when an enforcing CNI is present.
- A mesh adds service identity, mTLS, and Layer 7 authorization for enrolled traffic.
- High-value HTTP and gRPC services often need both layers.
- Test DNS, scheduled jobs, denied calls, and plaintext traffic before enforcement.
Further reading
If you want to learn more about this topic, these sources may interest you:
