Kubernetes NetworkPolicy Generator

Introduction:

Open pod-to-pod networking is a useful default while a Kubernetes application is still taking shape, but it is rarely the posture teams want to leave in production. A frontend that only needs to call one API, an API that only needs DNS and a database, or a batch job that should never accept inbound traffic all benefit from a smaller network blast radius. NetworkPolicy is the standard Kubernetes object for writing those limits at layer 3 and layer 4, using workload labels instead of fixed pod addresses.

The label model is the main difference from a traditional firewall rule. Pods are replaced often, Services hide groups of pods, and pod IP addresses are not stable enough to be a long-term security boundary. A NetworkPolicy first selects the pods that should become isolated, then lists the peers and ports that should remain allowed. Peers can be same-namespace pods, namespaces selected by labels, pods inside selected namespaces, or IP blocks for CIDR-based traffic.

NetworkPolicy is allowlist-based. There is no explicit deny rule in the standard API, and policies do not override each other by priority. When several policies select the same pod, their allowed connections are added together. A policy that appears restrictive in isolation can therefore be widened by another policy already present in the namespace. For a connection between two isolated pods, the source side must allow egress and the destination side must allow ingress.

Ingress

Traffic arriving at selected pods, such as a web tier reaching an API, an ingress controller forwarding requests, or a metrics system scraping a pod port.

Egress

Traffic leaving selected pods, such as DNS lookups, database access, service calls, webhook delivery, or tightly scoped external CIDR ranges.

Default deny

A state where selected pods have no allowed traffic in a direction until one or more allow rules open the required paths.

Selectors are the place where many mistakes hide. A selector such as app=orders-api,tier=backend matches only pods that carry both labels, while an empty pod selector selects every pod in the namespace. Namespace selection also depends on labels. A policy cannot point to a namespace by a dedicated name field, so clusters commonly use the well-known kubernetes.io/metadata.name namespace label when a policy needs to select one namespace by name.

The standard object stays deliberately narrow. It covers pod selectors, namespace selectors, IP blocks, protocols, single ports, and supported port ranges. It does not express HTTP paths, TLS identity, DNS names, service-account policy, policy priority, logging, or clusterwide defaults by itself. Many network plugins add their own policy resources for those jobs, but the standard NetworkPolicy remains the portable starting point for documenting and rolling out workload traffic boundaries.

How to Use This Tool:

Start from the intended isolation posture, then make the selected pods and allow rows match the workload you plan to protect. The generated YAML, rollout commands, rule ledger, review notes, peer syntax guide, flow map, and JSON summary all come from the same parsed inputs.

1. Choose a Policy template. App ingress plus controlled egress starts with both directions, while ingress-only, egress-only, selected-pod default deny, and namespace default deny provide narrower starting points.
2. Set Policy name and Namespace. The name is normalized into a Kubernetes-safe metadata name. Leaving the namespace blank omits metadata.namespace, so kubectl uses the current context namespace.
3. Enter Target pod selector as label pairs such as app=orders-api and tier=backend. Clear this field only when the policy should select every pod in the namespace.
4. Pick Policy directions and Review profile. The profile changes review language for portable standard policy, strict default-deny rollout, Cilium-backed standard policy, or Calico-backed standard policy.
5. Write Ingress allow rows and Egress allow rows as CSV-style lines in the order name, peer, ports, protocol, note. Use Browse, drag and drop, Sample, Normalize, or Reset when pasted rows need cleanup.
6. Open Advanced when you need a companion default-deny output, a Kustomize base, a different namespace-name label key, managed labels, review annotations, current Kubernetes port-range output, or portable single-port output.
7. Read Policy Review before copying YAML. Fix blocking errors for labels, peers, CIDR ranges, ports, protocols, namespace labels, or names before applying the manifest.

Use Rollout Commands as a staging checklist. Server-side dry run and diff catch API-level issues, but they do not prove that the target network plugin enforces the rule or that the workload still has every dependency it needs.

Interpreting Results:

Policy YAML is the manifest to apply or place in source control. Before using it, confirm the selected pods, policy directions, namespace, peers, and ports. Rule Ledger is often the faster audit surface because it translates each allow row into direction, peer, selector, ports, effect, and note.

Policy Review separates blocking input issues from rollout cautions. A ready status means the inputs can produce standard networking.k8s.io/v1 YAML. It does not mean that an enforcing CNI is installed, that existing policies do not already allow wider access, or that application traffic has been tested. Treat warnings about empty selectors, missing DNS egress, broad any peers, private-looking CIDR blocks, no namespace, or strict-profile mismatch as items to resolve deliberately.

Technical Details:

A NetworkPolicy is a namespaced Kubernetes object whose spec.podSelector chooses the pods affected by the policy. A selected pod becomes isolated only for the directions named in policyTypes. If ingress is isolated, inbound connections must match an ingress allow rule. If egress is isolated, outbound connections must match an egress allow rule. Reply traffic for an allowed connection is allowed implicitly.

The matching model is additive. Every policy that selects a pod contributes more allowed traffic, and the final result is the union of those allows. Rule order does not create priority, and a later standard NetworkPolicy cannot deny a path that another selected policy already allows. Accurate review therefore depends on both the new YAML and the policies that already exist in the namespace.

Rule Core:

Peer Syntax Map:

The row syntax is a compact input format for standard NetworkPolicy peers. It does not produce plugin-specific policy resources.

Validation and Rollout Logic:

• Label keys and values are checked against Kubernetes label-safe patterns before the YAML is marked ready.
• Policy and namespace names are normalized to DNS-label-safe values, with a warning when no namespace is emitted.
• Ports can be numeric, named, or numeric ranges. Numeric ports must be between 1 and 65535, and protocols are limited to TCP, UDP, or SCTP.
• Review warnings call out empty target selectors, isolated directions with no allow rows, missing UDP/53 DNS egress, broad any peers, private-looking ipBlock CIDRs, and strict rollout without a companion default-deny output.
• The command checklist uses server-side dry run, diff, apply, get, and describe so the API server can reject invalid manifests before rollout.

CIDR peers need special care. Kubernetes documentation frames ipBlock mainly for IP ranges outside the cluster, while pod and namespace selectors are the portable way to describe cluster workloads. Some plugins can handle internal ranges in useful ways, but that behavior should be checked against the target plugin before relying on it.

Limitations, Privacy, and Safety Notes:

The generator creates static manifests and review artifacts from values entered in the browser. It does not connect to a cluster, inspect live labels, discover existing policies, verify network plugin enforcement, or run traffic tests.

• Run kubectl apply --dry-run=server and kubectl diff against the target cluster before applying a policy.
• Test DNS, health checks, ingress controller paths, service calls, metrics scraping, webhooks, and external dependencies after rollout.
• Check the namespace policy set because standard NetworkPolicies are additive.
• Use ipBlock for external CIDR ranges unless the target plugin documentation clearly supports the internal address behavior you need.
• A default-deny policy can break applications immediately. Stage it with explicit allow rules and rollback steps.

Worked Examples:

Backend API allowlist. A production API can target app=orders-api and tier=backend with both ingress and egress isolated. An ingress row such as frontend HTTPS,nspod:web|app=frontend,443,TCP,frontend service to API becomes a namespace-plus-pod source, while egress rows for UDP/53 DNS and a payments namespace keep the review from flagging missing DNS egress.

Namespace default deny. A baseline policy starts from the namespace default deny template and an empty target selector. The YAML then uses podSelector: {}, isolates both directions, and emits no allow rows. Apply this only when workload-specific allow policies are ready to open required paths.

Port range compatibility. A row with 3000-3100 can emit port plus endPort in current compatibility mode. Switching to portable mode emits only the starting port and adds a warning because the range cannot be represented the same way.

Syntax recovery. If the review says a peer is not recognized, compare the row with Peer Syntax. For example, web|app=frontend is not a valid peer by itself; nspod:web|app=frontend supplies the namespace-plus-pod form.

FAQ:

Glossary:

NetworkPolicy

A namespaced Kubernetes object that controls allowed ingress and egress traffic for selected pods.

CNI

Container Network Interface. NetworkPolicy enforcement depends on a cluster network plugin that supports it.

Pod selector

A label selector that chooses the pods a policy affects.

Namespace selector

A label selector that chooses namespaces whose pods can be peers in a policy rule.

IP block

A CIDR-based peer, most often used for external IP ranges rather than pod or service addresses.

Default deny

An isolation posture where selected pods have no allowed traffic in a direction until explicit allow rules are added.

References:

• Network Policies, Kubernetes Documentation.
• NetworkPolicy API Reference, Kubernetes Documentation.
• Labels and Selectors, Kubernetes Documentation.