Skip to main content
This guide will help you install kguardian and generate your first security policy.

Prerequisites

Before you begin, ensure you have:
  • Kubernetes v1.19 or later
  • Linux nodes with kernel 6.2+ (for eBPF support)
  • kubectl configured and connected to your cluster
  • Admin access to install the controller (DaemonSet, RBAC, etc.)
  • Permission to create resources in your target namespaces
The kguardian controller needs the privileged Pod Security Admission level because it loads eBPF programs. If your cluster enforces Pod Security Admission, label the install namespace before running helm install:
If you skip this on a PSA-enforced cluster, the controller pods will fail to admit with a violates PodSecurity "restricted:..." error.
Kernel Version Check: kguardian requires Linux kernel 6.2+ for eBPF functionality. Run uname -r on your nodes to verify.

Step 1: Install kguardian

A single Helm install deploys the full stack: the Controller DaemonSet (eBPF observation), Broker, database, frontend, and evaluator.
For specific versions, custom Helm values, Kind-based local development, and external PostgreSQL setups, see the Installation Guide — that page is the canonical install reference.

Verify Installation

Check that all components are running:
All pods should show Running status. If not, see Troubleshooting.

Step 2: Install the CLI Plugin

The kguardian CLI is a kubectl plugin for generating policies.

Step 3: Let Your Workloads Run

kguardian learns from actual runtime behavior, so let your applications run normally for 5-15 minutes to collect meaningful data.
1

Deploy Test Workload (Optional)

If you don’t have existing workloads, deploy a small test app:
2

Monitor Data Collection

Check that the broker is receiving data:
The longer you let workloads run, the more traffic and syscall variety the controller will capture, and the closer the generated policy will be to your real runtime profile.

Step 4: Generate Your First Network Policy

Now generate a network policy based on observed traffic. --dry-run=true is the default — the CLI writes YAML to --output-dir and does not apply anything to the cluster:
To apply directly during generation instead of writing files for review, pass --dry-run=false. See gen networkpolicy for the full flag reference.
Success! kguardian automatically discovered that your nginx pod receives traffic from the curl-pod on port 80 and makes DNS queries.

Apply the Policy

The default --dry-run=true only writes the YAML file. To put the policy on the cluster, either re-run the CLI with --dry-run=false, or kubectl apply the saved file:

Step 5: Generate a Seccomp Profile

Generate a seccomp profile to restrict syscalls:

Apply the Seccomp Profile

kguardian generates the profile JSON. Distributing the profile to each node’s /var/lib/kubelet/seccomp/ directory is the user’s responsibility — kguardian does not push profiles to nodes today. Recommended distribution options:
  • Security Profiles Operator (SPO) — Wrap the generated JSON in a SeccompProfile CRD; SPO’s DaemonSet writes it to the kubelet seccomp directory on every node. See the SPO docs for the CRD schema and DaemonSet behavior.
  • A custom hostPath DaemonSet — Mount /var/lib/kubelet/seccomp/ and copy the profile in. Suitable if you do not want a separate operator.
  • Image-baked profiles — Bake the profile into a config map or container image and ship it with your existing deployment pipeline.
Once the profile file lives at /var/lib/kubelet/seccomp/nginx-profile.json on every node that may run the pod, reference it from your workload:
Automated seccomp profile distribution from kguardian is on the roadmap. Until then, pair kguardian with SPO or a DaemonSet of your own.

Next Steps

Architecture

See how the Controller, Broker, and UI fit together

Generate Cilium Policies

Create enhanced L7-aware policies

Batch Generation

Generate policies for all pods at once

Policy Gallery

Worked examples for nginx, Postgres, kube-dns, Prometheus, Istio, Go

Common Issues

Solution: Ensure your pods have been running and generating traffic for at least 5 minutes. Check broker logs:
Solution: Verify kernel version (6.2+) and that nodes support eBPF:
Solution: The CLI auto-discovers the broker via port-forwarding. Ensure you have permissions:
For more troubleshooting, see the Troubleshooting Guide.

Learn more about kguardian's architecture

Understand how the components work together →