Free online client-side Kubernetes NetworkPolicy generator tool. Visually construct networking.k8s.io/v1 NetworkPolicy manifests, configure podSelector, namespaceSelector, ipBlock CIDR ranges, and port protocols (TCP/UDP/SCTP) with instant live YAML rendering and one-click security presets.
networking.k8s.io/v1
egress isolation, ensure DNS egress (UDP/53 or TCP/53 to kube-system namespace) is permitted, otherwise pods won't be able to resolve internal domain names.Enter your NetworkPolicy metadata name, target namespace, and key-value matchLabels (podSelector) to define which container pods this policy applies to.
Toggle Ingress (inbound traffic), Egress (outbound traffic), or both policyTypes depending on your microservice isolation requirements.
Add rule sources and destinations using podSelectors (app labels), namespaceSelectors (environment labels), or CIDR subnets (ipBlock with optional except ranges).
Define explicit port numbers (e.g., 80, 443, 5432, 53) and transport protocols (TCP, UDP, SCTP) allowed for each ingress or egress rule.
Review the live syntax-highlighted networking.k8s.io/v1 YAML manifest, copy it to your clipboard, or download the `.yaml` file for immediate deployment via kubectl apply.
Restrict sensitive database pods (PostgreSQL, MySQL, Redis, MongoDB) so they accept inbound connections exclusively from verified backend API pods on designated ports.
Prevent unauthorized cross-namespace lateral movement in multi-tenant Kubernetes clusters by enforcing strict namespaceSelector boundaries between staging, production, and dev environments.
Restrict ingress traffic so internal administrative workloads or management endpoints accept traffic only from trusted corporate VPN subnets or static bastion IP ranges.
Satisfy strict regulatory compliance mandates by replacing open, un-isolated cluster networking with explicit default-deny ingress and default-deny egress NetworkPolicies.
By default, Kubernetes uses an unrestricted, flat networking model. All container pods across all namespaces can communicate with every other pod in the cluster without restriction. While this open default simplifies initial application deployment, it represents a catastrophic security vulnerability in production environments: if an attacker compromises a single public-facing web container, they can move laterally across internal networks, discover unauthenticated database endpoints, and exfiltrate sensitive data.
Kubernetes NetworkPolicies provide Layer 3 (IP layer) and Layer 4 (Port/Transport layer) network traffic control. Similar to cloud security groups or traditional firewalls, NetworkPolicies allow platform engineers and DevOps teams to specify exactly which pods, namespaces, and IP ranges are permitted to communicate.
By default, no NetworkPolicies select your pods. All pods are non-isolated, accepting unrestricted inbound connections from any cluster IP and sending outbound traffic anywhere.
podSelector (Target Pod Identification)Every NetworkPolicy includes a podSelector field in its spec. This selector determines which pods in the policy's namespace are governed by the rule:
podSelector: { matchLabels: { app: backend } } applies the policy exclusively to pods carrying the app=backend label.podSelector: {} selects all pods in the specified namespace. This is commonly used when creating a default-deny-all-ingress or default-deny-all-egress safety policy.policyTypes (Enforcement Mode)The policyTypes array dictates whether the NetworkPolicy controls inbound traffic (Ingress), outbound traffic (Egress), or both:
policyTypes includes Ingress, the targeted pods become isolated for inbound connections.policyTypes includes Egress, the targeted pods become isolated for outbound connections.Ingress is listed in policyTypes but no ingress: rules array is provided, the policy acts as a Default Deny All Ingress policy.from and to Selectors)Ingress rules use from:, and Egress rules use to:. Each peer entry supports three primary selection methods:
kubernetes.io/metadata.name: production selects the production namespace.cidr: 192.168.1.0/24) and optional exception subnets (except: [192.168.1.50/32]). This is used for whitelisting external corporate gateways, edge load balancers, or legacy on-premise infrastructure.One of the most frequent causes of broken Kubernetes NetworkPolicies is misinterpreting YAML array indentation when combining podSelector and namespaceSelector:
*Interpretation:* Accepts traffic from pods in namespaces labeled user=alice OR from pods labeled role=client in the current namespace.
*Interpretation:* Accepts traffic ONLY IF the sending pod has the label role=client AND resides inside a namespace labeled user=alice.
Creating a NetworkPolicy resource in Kubernetes merely stores an API object in etcd. NetworkPolicies do not enforce network blocking by default unless your cluster is equipped with a compatible CNI (Container Network Interface) plugin.
aws-node (AWS VPC CNI) did not historically enforce NetworkPolicies. You must explicitly enable AWS VPC CNI Network Policy Controller (v1.14+) or install Calico for NetworkPolicy enforcement.--enable-network-policy) when creating the cluster or node pool (powered by Calico/Dataplane v2).Place this policy in every production namespace to enforce a Zero-Trust baseline:
When enabling Egress policy enforcement on your workloads, pods will lose the ability to resolve domain names (such as postgres.database.svc.cluster.local or external APIs) unless you explicitly permit DNS traffic (UDP/53 and TCP/53) to kube-system:
All NetworkPolicy AST construction, label validation, CIDR processing, and YAML code generation execute 100% client-side in JavaScript memory within your browser. Your cluster names, namespace labels, and internal IP address schemes are never uploaded, logged, or transmitted to any external server.