Kubernetes NetworkPolicy Generator

Introduction:

Kubernetes pods are commonly open to cluster traffic until a NetworkPolicy selects them for isolation. That default makes early deployment convenient, but it leaves every reachable workload dependent on application-level defenses. A policy narrows the path by naming the selected pods, the traffic direction, and the peers and ports that remain allowed.

Selectors are more durable than pod IP addresses because pods are replaced and rescheduled. A target podSelector chooses the workloads governed by the policy. Rules then describe sources for ingress or destinations for egress with pod labels, namespace labels, a combination of both, or an IP block.

Ingress

Connections arriving at selected pods. A backend might allow an ingress controller or a labelled frontend on one TCP port.

Egress

Connections leaving selected pods. Common allowances include cluster DNS, an internal service, or a carefully bounded external network.

Default deny

A selected direction with no allow entries. Traffic remains blocked unless another applicable policy allows it.

Policies are additive rather than ordered. If several policies select the same pod for one direction, the allowed connections are the union of all their matching rules. For traffic between two isolated pods, the source's egress policy and the destination's ingress policy must both permit the connection.

An empty target selector means every pod in the policy's namespace. That is useful for a namespace-wide baseline and dangerous when accidental. Empty ingress or egress rule lists also have strong meaning: selecting that direction without allow rows creates deny-all behavior for the selected pods.

API acceptance is therefore only the first deployment check. A safe rollout confirms the namespace and labels, inspects every policy selecting the same pods, verifies plugin support, and tests allowed and blocked traffic from representative workloads.

How to Use This Tool:

Begin with the workloads that should be isolated, then write only the connections they require.

1. Choose a Policy template, replace every sample value, and enter a workload-specific policy name and the exact target namespace.
2. Enter Target pod labels as key=value rows. Leave the selector blank only for an intentional namespace-wide policy.
3. Select ingress, egress, or both under Policy directions. Leaving the active direction's allow rows blank generates deny-all behavior for that direction.
4. Write each allow row as name, peer, ports, protocol, and note. Use quoted CSV fields when a value itself contains a comma, and correct the first reported syntax error before continuing.
5. Choose the review profile and output package. A strict rollout is best paired with the companion default-deny package unless an equivalent baseline already exists.
6. Review Policy review and Rule ledger, then run the generated server-side dry run and diff commands. Apply only after verifying labels, CNI enforcement, DNS egress, and expected connectivity in a staged namespace.

Interpreting Results:

Policy YAML is the exact manifest draft. Read its podSelector, policyTypes, peer selectors, and ports before considering the counts or flow chart. A warning is not automatically an error, but broad peers, an empty target selector, omitted DNS egress, documentation CIDRs, or deny-all directions can produce major outages or unintended access.

The Rule ledger translates each row into its direction, peer scope, ports, and effect. The Policy review identifies assumptions that API validation cannot settle, including live labels, namespace context, plugin enforcement, internal IP-block behavior, and vendor-specific features.

A server-side dry run proves that the target API accepts the object shape; it does not test packet flow. Confidence comes from applying to a controlled scope, testing both an allowed path and a path expected to fail, and inspecting all policies that select the same pods.

Technical Details:

A networking.k8s.io/v1 NetworkPolicy contains metadata plus a specification with a target podSelector, explicit policyTypes, and optional ingress and egress lists. A selected direction with no list entries permits no peers in that direction. Rules add allowances; they never subtract allowances granted by another policy.

Rule Core

Each source row becomes one ingress from rule or one egress to rule. The peer prefix controls the selector object.

Protocols are limited to TCP, UDP, and SCTP. Numeric ports must be from 1 through 65535. A range such as 8000-8010 emits an inclusive endPort in current mode; portable mode emits only the starting port and raises a warning because the allowed traffic is narrower than the entered range. Named ports follow the accepted Kubernetes service-style name shape.

Transformation Core

Policy names and namespaces are normalized to DNS-label-safe lowercase text. Target labels become spec.podSelector.matchLabels. Ingress and egress rows are parsed independently, inactive directions are ignored, and the chosen package determines how resources are assembled.

The portable, strict, Cilium, and Calico profiles change review guidance, not the API kind. Vendor profiles still emit standard NetworkPolicy; they do not create Cilium layer-7 or fully qualified domain name rules, Calico tiers, or global policy.

The visible ledger limit affects table display only. It does not remove rules from generated YAML. Warning and pass totals are audit tallies, while ingress, egress, and deny-all counts describe the current draft rather than effective cluster policy after other objects are added.

Limitations, Privacy, and Safety Notes:

Rule text and imported CSV or text files are processed in the browser. The generator cannot inspect live namespaces, pods, labels, existing policies, service endpoints, or CNI capabilities.

• Replace the documentation networks 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24, and 2001:db8::/32 before deployment.
• Prefer pod and namespace selectors over private cluster CIDRs unless the target CNI's IP-block behavior is understood.
• Roll out default-deny changes gradually and keep an independent recovery path in case management traffic is blocked.

Worked Examples:

References:

• Network Policies, Kubernetes Documentation.
• NetworkPolicy v1 API reference, Kubernetes Documentation.
• How to create a Kubernetes NetworkPolicy, Simplified Guide.