Kubernetes NetworkPolicy Generator

Policy template:

Start from an allowlist posture, then edit selectors and peers before copying YAML.

Policy name:

Use a short deployment-safe name such as orders-api-network.

Namespace:

Set the namespace that owns the selected pods and the NetworkPolicy object.

Target pod selector:

These labels go into spec.podSelector.matchLabels for the pods the policy isolates.

Policy directions:

Choose which traffic directions the NetworkPolicy should isolate and allow.

Review profile:

Choose the enforcement context used for review checks and rollout commands.

Ingress allow rows:

Allow sources that may connect to the selected pods. Leave blank for deny-all ingress when Ingress is selected.

Egress allow rows:

Allow destinations that selected pods may reach. Leave blank for deny-all egress when Egress is selected.

Output package:

Choose the artifact shape before copying or downloading the generated output.

Fix policy inputs

{{ error }}

Review before applying

{{ warning }}

Kubernetes compatibility:

Use portable mode when the cluster or CNI does not support NetworkPolicy endPort.

Namespace name label key:

Used when a peer row references ns:name or nspod:name|labels.

Add managed-by labels

Adds app.kubernetes.io/managed-by: simplified-tools to generated metadata labels.

Add review annotations

Includes policy template and generated-by annotations for pull-request review.

Visible row limit:

Use a compact value for screenshots or a larger value for review handoffs.

rows

{{ result.yaml }}

{{ result.commands }}

{{ header }}	Copy
{{ cell }}
No rows for the current policy input.

Policy flow chart renderer unavailable.

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Kubernetes NetworkPolicy controls traffic to and from selected pods. It is an allowlist model: once a pod is isolated for ingress or egress, only traffic allowed by matching policy rules in that direction can pass. Traffic that is not selected, or clusters whose network plugin does not enforce NetworkPolicy, may behave differently than the YAML alone suggests.

The main decision is scope. A policy can target one workload by label, all pods in a namespace with an empty selector, or a broader application slice such as backend pods. Rules then name who may connect in, where selected pods may connect out, and which ports and protocols are allowed. Small selector mistakes can accidentally create a deny-all policy, a namespace-wide policy, or a broad allow.

Ingress and egress are evaluated separately. Ingress rules describe traffic arriving at selected pods. Egress rules describe traffic leaving selected pods. When both the source and destination pods are isolated by policies, the connection must satisfy the relevant egress rule on the source side and the relevant ingress rule on the destination side.

NetworkPolicy is portable only within the standard fields that the target cluster and network plugin support. Some environments add richer policy resources for domain names, application-layer rules, clusterwide policy, or tiered policy, but standard NetworkPolicy remains a useful baseline for workload isolation, default-deny rollouts, and pull-request review.

How to Use This Tool:

Start from a policy posture, then edit the namespace, selected pod labels, allow rows, and output shape. The generated YAML, rollout commands, review tables, peer syntax guide, policy flow map, and JSON output are built from the same parsed rules.

Choose a Policy template, such as app ingress plus controlled egress, ingress allowlist, egress allowlist, selected-pod default deny, or namespace default deny.
Set Policy name, Namespace, and Target pod selector. Leave the selector blank only when the policy should select every pod in the namespace.
Choose Policy directions. Ingress isolates traffic to selected pods; egress isolates traffic leaving selected pods.
Enter Ingress allow rows and Egress allow rows as CSV-style lines: name, peer, ports, protocol, and note. You can paste, browse, drop, load samples, normalize parsed rows, or reset each direction.
Use peer tokens such as pod:, ns:, nslabel:, nspod:, cidr:, or any. Open Peer Syntax when a row is unclear.
Pick the output shape and compatibility target, then review Policy YAML, Rollout Commands, Rule Ledger, Policy Review, and Policy Flow Map before applying anything to a cluster.

Interpreting Results:

Policy YAML is the generated manifest or manifest set. It uses networking.k8s.io/v1, a normalized metadata name, optional namespace, the selected pod selector, policy types, and rule blocks for the selected directions.

Rule Ledger translates each allow row into a human-readable direction, peer, selector shape, port list, effect, and note. Policy Review flags invalid inputs, broad peers, empty selectors, missing DNS egress, default-deny posture, no namespace, and profile-specific cautions. Policy Flow Map is a quick topology check, not a simulator.

Kubernetes NetworkPolicy result interpretation
Result area	Useful reading	Risk to check
Policy YAML	Shows the manifest that can be copied, downloaded, or split into a Kustomize-style base.	Run server-side dry-run and diff against the target cluster before applying.
Rule Ledger	Confirms how each CSV row became a peer selector, IP block, port rule, or broad peer.	Look for unexpected `any` peers, empty selectors, and private CIDRs used as IP blocks.
Policy Review	Summarizes readiness, warnings, DNS egress, selector scope, CNI support, and chosen review profile.	Warnings are not harmless; they mark assumptions that should be confirmed before rollout.
Rollout Commands	Gives dry-run, diff, apply, get, and describe commands for the selected output shape.	Commands do not prove application connectivity; test real client and dependency paths after rollout.

Technical Details:

A NetworkPolicy is namespaced and selects pods with spec.podSelector. If the selector is empty, every pod in the namespace is selected. policyTypes determines which directions are isolated. A selected pod with ingress isolation denies ingress unless at least one ingress rule allows the connection. A selected pod with egress isolation denies egress unless at least one egress rule allows the connection.

Rules are additive. Multiple NetworkPolicies that select the same pod do not conflict by priority; their allowed connections are combined. That means a restrictive-looking policy can be widened by another policy that selects the same pod. Review should consider the namespace's existing policies, not only the newly generated manifest.

Rule Core:

Kubernetes NetworkPolicy rule core
Rule area	Generated shape	Important boundary
Target selector	`spec.podSelector.matchLabels` when labels are supplied, or `podSelector: {}` when blank.	Blank selector selects every pod in the namespace.
Ingress row	Adds an `ingress` item with optional `from` peer list and optional `ports`.	No ingress rows in an ingress-isolating policy means deny all ingress to selected pods.
Egress row	Adds an `egress` item with optional `to` peer list and optional `ports`.	No egress rows in an egress-isolating policy means deny all egress from selected pods.
Port range	Uses `port` plus `endPort` when current compatibility is selected.	Portable mode collapses ranges to a single starting port and warns about the change.
Companion default deny	Adds a baseline policy selecting all pods with both directions isolated and no allow rows.	Useful for strict rollouts, but it can break workloads until required allows are present.

Peer Syntax Map:

Kubernetes NetworkPolicy peer syntax map
Token	Peer meaning	Typical use
`pod:`	Same-namespace pod labels.	Allow a workload in the same namespace.
`ns:`	Named namespace through the configured namespace-name label.	Allow every pod from a known namespace.
`nslabel:`	Namespaces matched by labels.	Allow a team, environment, or tenant namespace group.
`nspod:`	Namespace selector plus pod selector in one peer.	Allow specific pods in a specific namespace.
`cidr:`	IP block with optional exceptions.	Allow cluster-external IP ranges when that matches CNI behavior.
`any`	Empty peer object, meaning every source or destination for that rule direction.	Use only for a deliberate broad allow.

Rollout Checks:

A safe rollout normally starts with kubectl apply --dry-run=server, then kubectl diff, then a staged apply in a namespace or canary workload where connectivity can be tested. Confirm DNS, health checks, service-to-service calls, ingress controller paths, webhook sources, metrics scraping, and package registry access before widening a default-deny policy.

Limitations and Safety Notes:

Generated YAML cannot confirm that the target cluster's network plugin enforces NetworkPolicy. Some plugins ignore the object, and others support the standard object while offering separate resources for application-layer, fully qualified domain name, node, global, or tiered controls.

IP block behavior deserves special care. Kubernetes documentation describes ipBlock mainly for cluster-external IP ranges because pod IP rewriting and CNI behavior vary. Avoid using pod or service CIDRs in ipBlock unless the target CNI documentation says that is the intended model.

The generator does not inspect live cluster policies. Existing policies that also select the same pods can add more allowed traffic, so review the namespace before relying on a new manifest as the complete connectivity boundary.

Worked Examples:

Backend allowlist. Select app ingress plus controlled egress, target app=orders-api and tier=backend, allow ingress from a frontend namespace-and-pod selector on TCP 443, and add egress rows for DNS and the payments API. The review should show both directions and no missing DNS warning.

Namespace default deny. Select namespace default deny and clear the target selector. The generated policy selects every pod in the namespace and isolates ingress and egress with no allow rows. Apply this only after the workload-specific allows are ready.

Portable port review. If a rule uses a range such as 3000-3100, current mode can emit endPort. Portable mode keeps the starting port and warns that the range was collapsed.

FAQ:

Does NetworkPolicy block traffic by default?

Not for every pod automatically. A pod is isolated only when at least one NetworkPolicy selects it for the relevant direction. Once isolated, traffic must be allowed by policy rules.

Why is DNS egress flagged?

Workloads with egress isolation often need explicit DNS access. Without a UDP/53 row to the cluster DNS pods or namespace, ordinary service discovery and external host lookup can fail.

Can this generate CiliumNetworkPolicy or Calico GlobalNetworkPolicy?

No. It generates standard Kubernetes NetworkPolicy YAML and review notes for common CNI-backed environments. Use vendor-specific resources separately when you need their advanced features.

Glossary:

NetworkPolicy: A namespaced Kubernetes object that controls allowed ingress and egress traffic for selected pods.
Pod selector: The label selector that decides which pods a policy isolates.
Ingress: Traffic arriving at selected pods.
Egress: Traffic leaving selected pods.
CNI: Container Network Interface plugin. NetworkPolicy enforcement depends on the cluster networking plugin.
Default deny: A policy posture where selected pods have no allowed traffic in one or both directions until explicit allow rules are added.