Back to Cookbook

NetPol Builder

Write K8s network policies from "A talks to B on port 443" instead of YAML puzzles

Generates Kubernetes NetworkPolicies from plain-English connectivity requirements. Also audits existing policies, detects missing coverage, and validates that policies match intended behavior.

House RecipeWork2 min

INGREDIENTS

🐙GitHub

PROMPT

Create a skill called "NetPol Builder". Generate and audit Kubernetes NetworkPolicies: Mode 1 — Generate: When I describe connectivity requirements in plain English (e.g., "frontend pods can reach backend on port 8080, backend can reach postgres on 5432, nothing else"), generate: - Default-deny ingress and egress policies per namespace - Explicit allow policies for each connectivity requirement - DNS egress rules (port 53 to kube-dns — don't forget this!) - Labels and selectors that match existing pod labels Mode 2 — Audit: Analyze existing NetworkPolicies in a namespace: - Identify pods with no NetworkPolicy coverage - Check for policies with selectors that don't match any pods - Build a connectivity matrix (which pods can reach which) - Compare intended vs. actual connectivity - Flag overly permissive policies (allow-all patterns) Validate by running `kubectl get pods --show-labels` to match selectors.

How It Works

Kubernetes NetworkPolicies use unintuitive YAML with subtle gotchas (a single

policy selecting a pod changes its default behavior from allow-all to deny-all).

This skill generates correct policies from simple connectivity descriptions.

What You Get

  • NetworkPolicy generation from plain English ("frontend can reach backend on port 8080")
  • Default-deny policies for namespace isolation
  • Audit of existing policies for gaps and misconfigurations
  • Connectivity matrix visualization (who can talk to whom)
  • Policy testing against actual cluster state
  • Calico or Cilium-specific policy generation if applicable

Setup Steps

  1. Describe your connectivity requirements in plain English
  2. Or ask your Claw to audit existing policies in a namespace
  3. Review and apply the generated policies
  4. Test with `kubectl exec` to verify connectivity

Tips

  • Start with default-deny in each namespace, then add explicit allow rules
  • Remember: adding ANY NetworkPolicy to a pod changes its default from allow-all to deny-all for the direction specified
  • DNS (port 53 UDP/TCP to kube-dns) is easy to forget and breaks everything
  • Test policies before applying broadly — start with a non-critical namespace
  • Pairs well with Firewall Janitor for AWS security group + K8s policy consistency
Tags:#kubernetes#networking#security#devops