What happens to traffic that isn't explicitly allowed?

Once any NetworkPolicy selects a Pod for a given direction (Ingress or Egress), that direction becomes default-deny for that Pod, only traffic matching at least one rule from at least one selecting policy is allowed; everything else is dropped. If no NetworkPolicy selects a Pod at all, traffic to and from it remains unrestricted.

What's the difference between podSelector, namespaceSelector, and ipBlock as a rule source?

podSelector matches Pods by label within the same namespace as the NetworkPolicy. namespaceSelector matches all Pods in namespaces carrying a given label, regardless of Pod-level labels. ipBlock matches traffic by source/destination CIDR range instead of Kubernetes identity, useful for allowing traffic to/from something outside the cluster, or from a specific known IP range.

Why does an ingress rule need both a podSelector and a namespaceSelector sometimes?

When both are set on the same `from`/`to` entry, Kubernetes AND's them together (Pods matching both selectors, in namespaces matching the namespace selector). This generator keeps each rule to a single source type at a time for clarity, add rows for each combination you need if a rule genuinely requires matching both conditions.

Does a NetworkPolicy actually do anything without a CNI plugin that supports it?

No. NetworkPolicy is an API object, not an implementation, it only takes effect if your cluster's CNI plugin (Calico, Cilium, Weave Net, etc.) implements the NetworkPolicy API. Some CNIs (like the basic kubenet) ignore NetworkPolicy objects entirely, so traffic won't actually be restricted even though `kubectl apply` succeeds.

NetworkPolicy YAML Generator

Overview

Introduction

NetworkPolicy YAML has one of the least intuitive shapes in the whole Kubernetes API: `from`/`to` are lists of peer objects, each peer can be a podSelector, namespaceSelector, or ipBlock, and ports are a separate sibling list rather than nested inside the peer, none of which is obvious without the docs open.

This tool builds a NetworkPolicy manifest from a form: a pod selector for the policy's target, a toggle for which directions to restrict, and repeatable ingress/egress rules built from whichever source type each rule needs.

What Is Kubernetes NetworkPolicy Generator?

A form-based generator for the `networking.k8s.io/v1/NetworkPolicy` resource, which restricts which traffic is allowed to and from a set of Pods, effectively a namespace-scoped firewall rule set enforced by the CNI plugin.

It supports all three rule source types (podSelector, namespaceSelector, ipBlock) for both ingress (`from`) and egress (`to`) rules, each optionally scoped to a specific port and protocol.

How Kubernetes NetworkPolicy Generator Works

Your podSelector labels become the policy's target selector (an empty selector matches all Pods in the namespace); the policyTypes toggle determines whether `ingress`, `egress`, or both blocks are emitted.

Each rule row becomes one `from`/`to` peer entry: podSelector and namespaceSelector rows render as `matchLabels` blocks, ipBlock rows render a `cidr` field (validated as a real CIDR), and a port, if set, is added as a sibling `ports` list on that same rule.

When To Use Kubernetes NetworkPolicy Generator

Use it to lock down which Pods, namespaces, or external IP ranges can reach a sensitive workload (a database, an internal API) or which destinations a workload is allowed to call out to.

It's also useful for implementing basic zero-trust segmentation, denying all traffic by default within a namespace and then explicitly allowing only the specific paths an application needs.

Often used alongside Kubernetes RBAC Generator.

Features

Advantages

Handles all three peer types correctly, including the CIDR validation that catches a malformed ipBlock before it reaches `kubectl apply`.
Keeps ports as a rule-level sibling list rather than incorrectly nesting them inside the peer object, matching the actual NetworkPolicy schema.
Supports both Ingress and Egress independently, so you can restrict just one direction without over-specifying the other.

Limitations

Each rule supports one peer (podSelector, namespaceSelector, or ipBlock) and one optional port; policies needing multiple peers or ports within a single rule block will need hand-merging after generation.
Doesn't emit `ipBlock.except` (CIDR carve-outs); add that by hand if you need to exclude a sub-range from an otherwise-allowed block.

Examples

Allow only the frontend Pods to reach a backend on port 8080

Input

name: backend-allow-frontend, podSelectorLabels: [{key: app, value: backend}], policyTypes: [Ingress], ingressRules: [{sourceType: podSelector, selectorKey: app, selectorValue: frontend, port: 8080, protocol: TCP}]

Output

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-allow-frontend
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

Pods labeled app=backend only accept inbound traffic on port 8080 from Pods labeled app=frontend in the same namespace; all other inbound traffic is denied.

Best Practices & Notes

Best Practices

Start with a default-deny policy (an empty podSelector with no rules) per namespace, then layer specific allow rules on top, rather than trying to enumerate every allow rule in one giant policy.
Prefer namespaceSelector over ipBlock when the source is another workload inside the same cluster, ipBlock is for genuinely external or non-Kubernetes traffic.
Always set a port when you know the workload only needs one, an unscoped rule with no ports allows all ports to the matched peers.

Developer Notes

Rule rendering keeps each `from`/`to` entry to a single peer type per generated policy rule (one podSelector, namespaceSelector, or ipBlock), matching the common case documented in the upstream NetworkPolicy recipes; combining multiple peer types with AND semantics within one rule is an advanced pattern best hand-edited after generation. CIDR validation is a basic IPv4 dotted-quad plus prefix-length regex; IPv6 CIDRs are not validated and would need to be entered and verified manually.

Kubernetes NetworkPolicy Generator Use Cases

Restricting a database Pod to only accept connections from a specific application's Pods
Allowing egress to an external service's IP range while denying all other outbound traffic
Implementing namespace-level network segmentation in a multi-tenant cluster

Common Mistakes

Assuming a NetworkPolicy takes effect on any cluster, without a NetworkPolicy-aware CNI plugin installed, the object is accepted by the API server but has no actual effect.
Forgetting that selecting a Pod for Ingress (or Egress) makes that direction default-deny, an empty ingress rule list plus Ingress in policyTypes blocks all inbound traffic, not none.
Using ipBlock for cluster-internal traffic instead of a selector, Pod IPs are ephemeral and an ipBlock rule can silently stop matching after a reschedule.

Tips

Pair this with the RBAC Generator when locking down a namespace: RBAC controls who can change the cluster's objects, NetworkPolicy controls what network traffic those objects can send and receive.

Kubernetes NetworkPolicy Generator