Kubernetes NetworkPolicy

A NetworkPolicy is a Kubernetes resource that controls how Pods can communicate with each other and with network endpoints.

They provide network-level isolation and enforce who can talk to whom inside the cluster.

Network segmentation divides network traffic into trust zones or boundaries to reduce lateral movement.

It helps restrict blast radius if a workload is compromised.

A Pod policy defines network traffic rules for a set of Pods.

Ingress rules define which connections are allowed into a Pod.

Egress rules define which connections a Pod is allowed to initiate outbound.

Default-deny means no traffic is allowed unless a specific policy allows it.

It reduces accidental or malicious network access to a workload.

A NetworkPolicy applies to Pods selected by labels and optional namespace selectors.

A `podSelector` selects the Pods that the policy applies to.

It defines whether the policy applies to ingress, egress, or both.

An ingress rule allows incoming connections to matching Pods.

An egress rule allows outgoing connections from matching Pods.

`from` rules specify who may connect to the selected Pods in ingress policies.

`to` rules specify what destinations are allowed for egress traffic.

A namespace selector matches Pods in specific namespaces.

A pod selector can select specific workloads in the same or other namespaces.

An IPBlock allows or denies traffic to and from specific CIDR ranges.

A CIDR is a network range such as 10.0.0.0/8 or 192.168.1.0/24.

It allows policies to permit or deny traffic to known external networks or internal ranges.

It selects Pods in specific namespaces that match labels, useful for multi-tenant policies.

A NetworkPolicy is created in a namespace and applies only to Pods in that namespace unless cross-namespace selectors are used.

If no policies apply, the default pod network behavior depends on the cluster CNI and default policy settings.

Many clusters allow unrestricted pod-to-pod communication unless a CNI or security policy restricts it.

CNI (Container Network Interface) is the network plugin standard for Kubernetes networking.

Because NetworkPolicy support depends on the CNI plugin implementing the policy enforcement.

Examples include Calico, Cilium, Antrea, and others.

An ingress allowlist is a set of allowed sources for incoming traffic to a service or pod.

An egress allowlist is a set of allowed destinations for outbound traffic.

A default allow policy allows traffic unless specifically denied by other rules.

Because it exposes workloads to more network access than needed.

Traffic between different Pods in the same or different namespaces.

Because compromised workloads can otherwise talk to many other workloads.

Traffic leaving the cluster to external systems or services.

Because it helps prevent data exfiltration or communication with malicious endpoints.

Traffic entering the cluster from outside or from another namespace.

Because the same principle applies: reduce the attack surface and lateral movement.

A label is used to group Pods and match them to a NetworkPolicy.

It selects Pods or namespaces by label rather than by exact namespace name.

It selects pods in the same namespace as the policy.

It can select Pods from other namespaces using a namespace selector and pod selector combination.

It lists the destination ports allowed by an ingress or egress rule.

Because policies should permit only the required ports and protocols.

It is usually TCP, UDP, or SCTP.

Because a policy may allow HTTP on TCP but not UDP on the same port.

Because some apps must accept inbound traffic and also initiate outbound connections to dependencies.

A database policy may allow only the application tier to reach the database port.

It may allow inbound traffic only from the frontend or API tier.

A policy may allow ingress from pods in a specific namespace.

Pods often need egress to DNS services on UDP/TCP port 53 for name resolution.

Without DNS, pods may not resolve service names or external hostnames.

Because many workloads still need to resolve names but should not contact arbitrary external endpoints.

The port in a policy is typically a destination port on the target pod or destination address.

Because the same app should behave consistently across dev, test, and prod.

A namespace is a security boundary for policies, even when the network plugin supports cross-namespace rules.

A selected Pod is one that matches the policy selectors.

Because labels are how policies select Pods and groups.

Examples: `app: frontend`, `app: api`, `db: postgres`.

It has metadata, spec, podSelector, policyTypes, ingress, and egress.

The plugin implements enforcement of NetworkPolicies and low-level networking.

NetworkPolicy enforcement depends on the CNI plugin and cluster configuration.

Because some features require special CNI or network settings.

It is the network policy system enforced by the CNI plugin.

No traffic enters the pod unless allowed.

No traffic leaves the pod unless allowed.

Because some workloads need to talk to public APIs or dependencies.

Because every allowed path is tied to specific labels or CIDR ranges.

It may permit ingress only from app pods on database port 5432.

It may allow ingress from the ingress controller or load balancer on HTTP/HTTPS ports.

It may allow egress to a queue or database while restricting inbound traffic.

Because compromised workloads cannot easily reach or use other workloads.

It is a boundary such as namespace, pod group, or trust zone used to isolate workloads.

It separates workloads, teams, or environments and makes policy simpler.

It means the policy only applies to ingress traffic.

It means the policy only applies to egress traffic.

It applies both ingress and egress rules.

Because apps may require outbound calls to databases, APIs, or DNS.

Usually allow UDP/TCP 53 to the cluster DNS service or upstream DNS resolvers.

It allows traffic from the load balancer or ingress controller only on relevant ports.

It selects namespaces by labels such as `team: payments` or `environment: prod`.

They allow team- or environment-specific traffic rules.

A cluster where multiple teams or workloads share the same infrastructure but require isolation.

Because they provide strong isolation between teams and workloads.

A service mesh handles L7 routing and security, while NetworkPolicy works at L3/L4 network enforcement.

It may be implemented for all workloads in a namespace or across namespaces.

Because policy violations may show as connection resets or timeouts without obvious application errors.

Because the policy is based on labels, namespace selectors, and IP rules.

It happens when a pod is selected incorrectly or a label is not matching the expected pattern.

Because ingress controllers need to be allowed to reach the service ports.

It is usually the ingress controller pod or service IPs or a CIDR range.

Application pods need to reach their database service, often on a specific port.

If a pod depends on a database or external API and the policy is too restrictive.

Because connectivity mistakes can create outages or unexpected service breakage.

Security and traffic control are primary; performance is secondary but still matters.

It may allow egress to a specific external IP or CIDR and port.

Some systems need egress to cloud metadata endpoints or internal DNS services.

A policy may allow HTTPS to certain endpoints while blocking all others.

It reduces the number of possible attack paths from a workload.

To allow traffic only from selected pods in specific namespaces.

Kubernetes evaluates policies based on matching pods and the selected rules; traffic allowed must match at least one allowed policy.

If no matching ingress or egress policy allows traffic, the traffic is denied.

Because it creates a clean list of allowed communications.

Kubernetes does not have a direct deny rule object; instead, you define allow rules and default deny by omission.

It assumes no workload is trusted by default and restricts communication tightly.

Because container-to-container communication often occurs within the same cluster with no natural trust boundary.

It uses specific selectors and policies to ensure workloads do not talk to each other when they should not.

It is a logical boundary such as app tier, data tier, or external exposure layer.

Because only application services should reach the database on its proper port.

It restricts frontend ingress to public traffic but blocks backend communication except from allowed APIs.

Because it handles external traffic into application services.

It isolates different service groups to reduce lateral movement.

A worker or consumer may only egress to the queue, database, and DNS while denying all else.

It allows DNS lookup to cluster or upstream resolvers while restricting other egress.

A NetworkPolicy does not inspect HTTPS payload; it only controls traffic paths and ports.

Because an app still needs to validate inputs, APIs, and access control.

A frontend might allow ingress from the world to HTTP/HTTPS but not to internal management ports.

Because management or admin ports should not be publicly reachable.

It allows a Pod in namespace A to allow traffic from selected Pods in namespace B.

For shared services or multi-team architectures that need controlled communication.

Monitoring daemons may need egress to metrics systems or collecting endpoints while all other egress is denied.

Labels are the stable identity used by selectors in policy rules.

It occurs when labels do not match the intended policy and the Pod ends up with blocked or missing traffic.

It often involves checking the pod labels, the NetworkPolicy manifest, and the CNI plugin logs.

Because the app may be unreachable or unable to talk to dependencies even though the workload is running.

It can show policy evaluation, packet drops, or agent decisions.

Because the plugin-specific data plane has different support and semantics.

Policy checks happen in the data plane, so configuration changes may take effect after a short delay.

It can explicitly allow traffic from a CIDR while denying everything else.

Because the service may be a specific internal or vendor network range.

This depends on the CNI plugin and cluster setup.

Because it does not enforce least privilege or allowlist communication.

It is the set of policies that only allows explicitly permitted traffic paths.

It reduces misconfiguration and prevents unvetted access.

It restricts which workloads can reach a service, like only the API tier to the database.

Some CNI or load balancers need allowed ingress for health probes or liveness checks.

Because if the health check port is blocked, the workload may appear unhealthy or unready.

Policies usually allow traffic to Service ports and Pod ports, which are often the same or mapped.

The policy’s `ports` field should reflect the application’s listening port.

Because allowing all ports would expose unnecessary application functionality.

It is an unintended path between compromised and valuable workloads.

Because it prevents teams from inadvertently reaching each other’s services in a shared cluster.

It allows one namespace’s workloads to communicate with selected workloads in another namespace.

Because a workload may need to talk to a database, a cloud service, or a queue.

Because policy can block traffic even when an app appears to start correctly.

To identify dropped connections or unreachable dependencies.

It displays the details and intent of NetworkPolicies in the cluster.

It helps validate the actual policy set applied to a namespace.

Service accounts are identity-level controls, while NetworkPolicies control network reachability.

Because it requires explicit traffic decisions rather than assuming trust.

It is a security approach where only permitted traffic is allowed.

Because they are mission-critical and should be reachable only by expected workloads.

A worker may only egress to the queue and internal APIs while everything else is blocked.

The plugin is the actual enforcement point, and different plugins may behave differently.

Because the workload might not be selected by the policy, or the CNI may not support the feature.

A pod may have explicit rules to permit egress to a specific CIDR or DNS endpoint.

Because DNS is required for service discovery and name-based access.

It often uses logs, packet analysis, or CNI diagnostic outputs to find traffic that is being denied.

A cron job may need outbound access to a database or external API but does not need inbound traffic.

Sidecars may need specific traffic rules based on whether they serve metrics, proxy traffic, or act as a security agent.

Because it reduces the risk of attack paths within a cluster.

An identity is the workload or user; a network boundary restricts traffic between identities.

Without support, network policies cannot be enforced.

The control plane manages policy objects; the data plane enforces packet filtering.

Because it stops traffic as it moves between pods rather than only at the app layer.

It uncovers app dependencies early and avoids hidden network assumptions.

Because it ensures all required communication paths are explicitly accounted for.

Monitoring or metrics systems often need a policy exception to reach metrics endpoints.

Because metrics endpoints are often not security-sensitive, but they still should be controlled.

Because internal service names and ports can otherwise be used in unexpected ways.

It is a diagram or inventory of which pods can talk to which workloads.

Because it makes security design easier to reason about.

It could allow ingress from the queue service and egress to the database and internal APIs.

It may allow inbound traffic from the mesh and outbound to backend services.

It may allow egress to logging endpoints while denying inbound access.

Allow ingress from ingress controllers or external ranges, egress to dependencies and DNS, deny all else.

It must be strict enough for security but flexible enough for the app to function.

If probes or monitoring systems are blocked, the service may appear unhealthy or fail health checks.

Because the policy exists in Kubernetes but is enforced in the network data plane by the CNI.

NetworkPolicy is the Kubernetes mechanism for network isolation: it defines allowed ingress and egress paths so workloads can communicate only on explicitly permitted paths.

The CNI plugin filters packets based on source/destination labels, namespaces, and ports.

It enforces at the IP and port layer, not application content layer.

Because it does not inspect HTTP paths, bodies, or application-level semantics.

A service mesh provides L7-aware routing, authorization, and observability.

Because NetworkPolicy controls pod-to-pod network reachability while service mesh can control HTTP semantics and mTLS.

mTLS secures service-to-service traffic; NetworkPolicy restricts which endpoints can talk to each other.

It happens when policy rules no longer match the actual network design or workload labels.

Because if labels change, the policy may inadvertently select or stop selecting workloads.

It is the use of NetworkPolicies to define boundaries and controls between workloads.

Because it reduces cross-namespace blast radius and helps maintain multi-tenant isolation.

It allows controlled communication between namespaces without fully open traffic.

Because they intentionally allow traffic across namespace boundaries and should be reviewed carefully.

It requires explicit IPBlock or external endpoint policy, often with DNS exceptions.

Because many workloads legitimately need outbound access to external APIs or package managers.

It allows only specific destinations and protocols and blocks all others.

To prevent compromised workloads from contacting command-and-control endpoints or exfiltrating data.

A trusted subnet is a CIDR range allowed for internal service access.

Because internal networks or service ranges are often more trusted and can be explicitly allowed.

Because they help diagnose whether traffic is being dropped or allowed unexpectedly.

It is Kubernetes’ way to control the network trust boundaries between workloads, enforcing least privilege and reducing lateral movement risk inside the cluster.