A cloud native firewall controls traffic between workloads using labels and identities instead of fixed IP addresses. In Kubernetes this is the NetworkPolicy object: allow rules for pods, enforced by the cluster's network plugin. Without any policy, every pod can talk to every other pod, so the default is open.
Why does the old firewall model strain in the cloud?
NIST's firewall guidance (SP 800-41 Revision 1) describes packet filters controlled by rulesets over addresses, ports and protocols. That works when a server keeps an address for years. In a cluster, pods are replaced constantly and get new addresses each time. A rule that names an address goes stale within minutes.
So cloud native tools select by label. The question moves from "which IP may reach which IP" to "which workloads with the label role=frontend may reach those with the label role=db."
How does Kubernetes network policy work?
The Kubernetes documentation sets out the rules plainly.
By default, a pod is non-isolated for ingress and for egress, so all inbound and outbound connections are allowed. When a NetworkPolicy selects a pod, that pod becomes isolated for the direction the policy covers, and only connections that some policy allows are permitted.
Policies are additive. They do not conflict, and the effects of multiple policies combine. So you cannot write a later rule that overrides an earlier allow.
Each policy has a pod selector that picks the pods it applies to. Rules can allow traffic from pods, namespaces or IP blocks, on stated ports. The docs add a requirement people forget: network policies are implemented by the network plugin, and your cluster must use one that supports enforcement. Creating the objects on a cluster without such a plugin has no effect.
What can it not do?
The documentation lists gaps in the NetworkPolicy API itself. It cannot force internal traffic through a common gateway, handle anything TLS related, target nodes by Kubernetes identity, target services by name, apply default policies across all namespaces, offer advanced policy querying, log blocked or accepted connections, or express explicit deny rules. The model is deny by default, with allow rules added.
The docs point to workarounds: operating system components, Layer 7 technologies such as ingress controllers and service meshes, and admission controllers. Some third-party Kubernetes distributions add cluster-wide defaults.
For a security team the logging gap matters most. A policy that silently drops traffic is hard to debug and gives no evidence of attempted lateral movement unless the plugin or another layer records it.
A constructed example
A team runs a checkout service, a payments service and a reporting job in one namespace. With no policies, a compromised reporting job can open connections to the payments pods. The team adds a policy selecting app=payments pods that allows ingress only from app=checkout pods on one TCP port. Reporting can no longer connect. Next, an egress policy for the reporting job allows only its database and DNS. Both changes are deny by default for those pods, and neither touches other workloads.
Where does a host or perimeter firewall still fit?
Cluster policies control pod to pod traffic. They do not replace controls at the edge, such as a perimeter firewall or a web application firewall, or the cloud provider's own network filters. NIST's guide distinguishes firewall types by what they inspect: packet filters at the network layer, stateful inspection with connection tracking, and web application firewalls for HTTP content. Cloud native policy is closest to the first two.
How to check or apply this
- Confirm your network plugin enforces NetworkPolicy. Apply a deny policy to a test namespace and check that a connection really fails.
- Start with a default-deny policy per namespace for ingress, then add allows for known flows.
- Add egress policies for sensitive workloads, including an allow for DNS, or name resolution will break.
- Label pods consistently, since labels are now your firewall rules.
- Keep policies in version control and review them like code.
- Add logging at a layer that supports it, since the API itself does not offer it.
- Re-test after upgrades of the network plugin.
Policy files are code, so they are subject to the same review as application changes. Safeguard's policies and gates can enforce checks in pull requests, though cluster network enforcement stays with your network plugin.
Quick check
Do Kubernetes pods block traffic by default?
No. According to the Kubernetes documentation, pods are non-isolated by default and all inbound and outbound connections are allowed until a policy selects them.
Can a later NetworkPolicy deny what an earlier one allowed?
No. Policies are additive and do not conflict, and the API has no explicit deny rule.
Sources
- Kubernetes documentation, Network Policies
- NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
Last reviewed: 18 October 2026.
