KiloClawPowered by OpenClaw
Back to Cookbook

Kubernetes Network Policy Generator

aka “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
Try in KiloClawFree 7-day trial

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

Related Recipes

Firewall Janitor

Find the 0.0.0.0/0 rule that was "temporary" 3 years ago

Audits AWS security groups and K8s network policies for overly permissive rules, unused rules, and conflicts. Cross-references VPC Flow Logs to identify rules that are never hit and can be safely removed.

Work3 min

Dockerfile Doctor

Faster builds, smaller images, fewer headaches

Paste your Dockerfile and get it back cleaner, smaller, and easier to cache. Good starter recipe for developers because the advice is concrete and the output is easy to compare against the original.

Work1 min

Scam Shield & Identity Theft Response

A calm checklist when fraud hits

Immediate steps, reporting sequences, and long-term hardening for scams and identity theft. Organized by urgency so you know what to do first.

Personal2 min

Scam Sponsorship Screener

Verify brand offers before you click anything

Screens incoming partnership offers for phishing and scam patterns: suspicious domains, attachments, fake checks, requests to "connect your account," and vague contracts. Outputs a risk rating and safe verification steps.

Personal4 min