Cloud Native 8 min read

Understanding Kubernetes Native NetworkPolicy: Concepts, Fields, and Examples

This article explains Kubernetes native NetworkPolicy, covering its purpose, supported CNI plugins, detailed field definitions, default behaviors, example policies, and historical changes, providing a comprehensive guide for configuring pod communication rules in a cloud‑native environment.

Cloud Native Technology Community
Cloud Native Technology Community
Cloud Native Technology Community
Understanding Kubernetes Native NetworkPolicy: Concepts, Fields, and Examples

Kubernetes NetworkPolicy is a specification that defines allowed communication rules between Pods and other network endpoints, using label selectors to target Pods and specify inbound and outbound traffic policies.

NetworkPolicy resources are processed by CNI‑compatible network plugins such as Calico, Cilium, Kube‑router, Romana, and Weave Net, which watch for Policy creation, updates, and deletions to enforce traffic rules.

By default, there are no restrictions on pod‑to‑pod or pod‑to‑external communication; policies must be explicitly created to limit traffic.

An example policy that blocks all traffic to Pods labeled app=web demonstrates the basic structure of a NetworkPolicy.

NetworkPolicy fields:

metadata.namespace is required because the policy is namespace‑scoped.

podSelector (required) selects the Pods the policy applies to; an empty selector {} matches all Pods in the namespace.

policyTypes (optional) specifies whether the policy contains Ingress , Egress , or both. If omitted, the presence of ingress or egress sections determines the type.

ingress (optional) defines inbound rules. Each rule may contain ports (list of allowed ports) and from (list of allowed sources). Sources can be specified via ipBlock , namespaceSelector , or podSelector .

egress (optional) defines outbound rules, with analogous ports and to fields.

Key sub‑fields:

ports : array of port objects; each may include port (numeric) and protocol (TCP, UDP, SCTP, default TCP).

from / to : arrays of source/destination selectors; empty means no restriction.

ipBlock : CIDR block with optional except list to exclude sub‑ranges.

After reviewing the spec, the article summarizes that NetworkPolicy rules are evaluated with an OR relationship—matching any rule permits the traffic.

An example from the Kubernetes documentation shows a policy that selects Pods with label role=db in the default namespace, allowing inbound traffic from a specific CIDR except a sub‑CIDR, from Pods in namespaces with label project=myproject , and from Pods with label role=frontend on TCP port 6379, while restricting outbound traffic to a CIDR with TCP port 5978.

Important notes: a NetworkPolicy only selects Pods within its own namespace, so similar policies may be needed across multiple namespaces, or a non‑native policy like Calico’s GlobalNetworkPolicy can be used.

NetworkPolicy version history:

v1.6 and earlier required enabling extensions/v1beta1/networkpolicies in the API server.

v1.7 graduated NetworkPolicy to GA with API version networking.k8s.io/v1 .

v1.8 added support for Egress and ipBlock .

The appendix provides links to a video on securing cluster networking, a repository of common policy recipes, and related reading about Windows nodes, Kubernetes 1.14 features, and scheduler internals.

CloudNativekubernetessecurityingressCNINetworkPolicyEgress
Cloud Native Technology Community
Written by

Cloud Native Technology Community

The Cloud Native Technology Community, part of the CNBPA Cloud Native Technology Practice Alliance, focuses on evangelizing cutting‑edge cloud‑native technologies and practical implementations. It shares in‑depth content, case studies, and event/meetup information on containers, Kubernetes, DevOps, Service Mesh, and other cloud‑native tech, along with updates from the CNBPA alliance.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.