Skip to main content
Hand-authored illustrations. The YAML in this gallery illustrates the shape of the policies kguardian generates for each workload — it is not captured generator output. Exact metadata, rule grouping, and selectors produced by kubectl kguardian gen will differ, and regeneration from a live cluster is planned. Always verify against your own runtime before applying.
Reading the CLI flag reference tells you what kguardian can do. Reading a generated policy tells you what kguardian actually does — what gets allowed, what gets denied, and how readable the output is. Each page in this gallery walks through one real workload pattern:
  • A 3-line description of the workload and what it talks to.
  • The generated NetworkPolicy YAML.
  • The generated CiliumNetworkPolicy YAML (where Cilium-specific fields add value — CIDR-based L4 egress, endpoint selectors, and default-deny semantics).
  • The generated seccomp profile JSON (or a representative excerpt with the full syscall count).
  • A short paragraph on what kguardian observed at runtime that produced each rule.

​
Workloads

nginx

HTTP frontend — ingress from peer pods, DNS egress, no upstream dependencies.

Postgres

Stateful database — accepts connections from app namespace, no egress beyond DNS.

CoreDNS / kube-dns

Cluster DNS resolver — ingress on 53/UDP+TCP, egress to upstream resolvers.

Prometheus

Scraping monitor — outbound HTTP to scrape targets, ingress from Grafana.

Istio sidecar (envoy)

Service-mesh proxy — mTLS to peers and control-plane traffic to istiod.

Go microservice

Typical HTTP API — ingress on a service port, egress to DB and a few SaaS endpoints.

​
How to read each example

The YAML on each page follows what kubectl kguardian gen networkpolicy <pod> --output-dir ./policies writes after the controller has observed the workload for at least a few minutes (add --type cilium for the CiliumNetworkPolicy variant — the default output type is kubernetes). The seccomp JSON is what kubectl kguardian gen seccomp <pod> --output-dir ./seccomp produces. If a workload’s observed behavior is empty or noisy in your cluster (no traffic captured yet, very short-lived pods, host-network pods), the generator emits a minimal policy and warns. None of the gallery examples reflect that path — see Troubleshooting instead.
The seccomp excerpts in this gallery are abbreviated for readability — real profiles contain far more syscall names than shown here.