Generating Network Policies

Learn how to generate Kubernetes and Cilium Network Policies from observed runtime traffic.

Overview

Network Policies in Kubernetes are like firewalls for your pods - they control which pods can communicate with each other. kguardian observes actual traffic patterns and generates policies that allow only the connections your application actually uses.

Best Practice: Let your application run under normal load for at least 5-15 minutes before generating policies. This ensures you capture all typical communication patterns.

Basic Usage

Generate for a Single Pod

The simplest use case - generate a policy for one specific pod:

kubectl kguardian gen networkpolicy my-app -n production \
  --output-dir ./policies

kguardian discovers the pod

The CLI queries the broker for all traffic involving my-app in the production namespace

Analyzes traffic patterns

Identifies all unique source IPs (for ingress rules)
Identifies all destination IPs (for egress rules)
Resolves IPs to pods/services
Groups by port and protocol

Generates YAML

Creates production-my-app-standard-networkpolicy.yaml in the ./policies directory

Generated policy example:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: my-app-standard-policy
  namespace: production
  labels:
    app.kubernetes.io/name: my-app
    app.kubernetes.io/component: standard-policy
    app.kubernetes.io/part-of: kguardian
spec:
  podSelector:
    matchLabels:
      app: my-app
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: api-gateway
          namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: production
      ports:
        - protocol: TCP
          port: 8080
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: postgres
          namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: production
      ports:
        - protocol: TCP
          port: 5432
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53

Batch Generation

All Pods in a Namespace

Generate policies for every pod in a namespace:

kubectl kguardian gen networkpolicy --all -n staging \
  --output-dir ./staging-policies

This will create one policy file per pod in the namespace.

All Pods Across All Namespaces

For cluster-wide policy generation:

kubectl kguardian gen networkpolicy -A \
  --output-dir ./cluster-policies

This can generate hundreds of files in large clusters. Use with caution and review before applying.

Cilium Network Policies

Cilium is an advanced CNI that provides enhanced network policies with L7 (HTTP, gRPC, Kafka) visibility and identity-based rules.

Generate Cilium Policies

kubectl kguardian gen networkpolicy my-app -n production \
  --type cilium \
  --output-dir ./cilium-policies

Cilium policy example:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: my-app-cilium-policy
  namespace: production
  labels:
    app.kubernetes.io/name: my-app
    app.kubernetes.io/component: cilium-policy
    app.kubernetes.io/part-of: kguardian
spec:
  endpointSelector:
    matchLabels:
      k8s:app: my-app
  ingress:
    - fromEndpoints:
        - matchLabels:
            k8s:app: api-gateway
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
  egress:
    - toEndpoints:
        - matchLabels:
            k8s:app: postgres
      toPorts:
        - ports:
            - port: "5432"
              protocol: TCP
    - toEndpoints:
        - matchLabels:
            k8s:k8s-app: kube-dns
      toPorts:
        - ports:
            - port: "53"
              protocol: UDP

Each peer gets a single endpoint selector built from that peer’s labels: the Service’s selector when the IP resolves to a Service (as with kube-dns above), the pod’s labels otherwise. toCIDR/fromCIDR entries appear only for IPs that can’t be resolved to a pod or Service. Label keys in the generated YAML carry Cilium’s k8s: source prefix.

Cilium vs Kubernetes Policies

Feature	Kubernetes	Cilium
Namespace selectors	✅	✅
Pod selectors	✅	✅
Port/protocol rules	✅	✅
CIDR blocks	✅	✅
L7 rules (HTTP, gRPC)	❌	✅
DNS-based rules	❌	✅
Identity-based	❌	✅
Cluster-wide policies	❌	✅

If you’re running Cilium CNI, use --type cilium for better security and features. Otherwise, stick with --type kubernetes (the default).

Dry Run and Applying

Dry Run (Default)

By default, gen networkpolicy runs in dry-run mode - it saves policies to files without applying them to the cluster:

kubectl kguardian gen netpol my-app -n prod --output-dir ./policies

# Policies are saved but NOT applied
# Review them first:
cat ./policies/prod-my-app-standard-networkpolicy.yaml

Applying directly from the CLI is not implemented. Passing --dry-run=false currently behaves the same as dry-run — policies are only saved to files — and the CLI logs a warning to that effect. Apply the generated files with kubectl apply -f.

Recommended Workflow

Generate policies in dry-run mode
Review the generated YAML files
Test in a staging environment
Apply with kubectl after validation:

kubectl apply -f ./policies/

Use with caution! Applying network policies can break communication if the observed traffic was incomplete. Always test in non-production first.

Advanced Options

Custom Output Directory

Save policies to a specific location:

kubectl kguardian gen netpol my-app -n prod \
  --output-dir /path/to/gitops/repo/network-policies

Print to Stdout Only

Skip file creation and just print the policy:

kubectl kguardian gen netpol my-app -n prod --output-dir=""

Useful for piping to other tools:

kubectl kguardian gen netpol my-app -n prod --output-dir="" | kubectl apply -f -

Understanding Generated Policies

Policy Structure

Every generated policy includes:

podSelector: Identifies which pods this policy applies to
policyTypes: Declares whether it has Ingress, Egress, or both
ingress: List of allowed incoming connections
egress: List of allowed outgoing connections

How Peers are Identified

kguardian resolves IPs to Kubernetes resources:

Pod-to-Pod Traffic

When traffic is between pods, kguardian generates:

- podSelector:
    matchLabels:
      app: my-service
  namespaceSelector:
    matchLabels:
      kubernetes.io/metadata.name: production

This allows traffic from any pod with app=my-service in the production namespace.

Service Traffic

For traffic to a Kubernetes Service, kguardian uses the service’s selector:

- podSelector:
    matchLabels:
      app: postgres  # Service selector
  namespaceSelector:
    matchLabels:
      kubernetes.io/metadata.name: databases

External Traffic

For traffic to external IPs (e.g., public APIs), kguardian generates CIDR blocks:

- to:
    - ipBlock:
        cidr: 52.1.2.3/32
  ports:
    - protocol: TCP
      port: 443

DNS Traffic

kguardian automatically detects DNS queries:

- to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          k8s-app: kube-dns
  ports:
    - protocol: UDP
      port: 53

Common Scenarios

Scenario 1: Microservices Application

You have a 3-tier app: frontend → backend → database.

# Generate policies for all three
kubectl kguardian gen netpol frontend -n myapp --output-dir ./policies
kubectl kguardian gen netpol backend -n myapp --output-dir ./policies
kubectl kguardian gen netpol database -n myapp --output-dir ./policies

# Review and apply
kubectl apply -f ./policies/

Result:

frontend policy allows ingress from ingress controller, egress to backend
backend policy allows ingress from frontend, egress to database
database policy allows ingress from backend only

Scenario 2: Multi-Namespace Communication

Your app in staging talks to a shared database in data:

kubectl kguardian gen netpol my-app -n staging --output-dir ./policies

Generated egress rule includes:

egress:
  - to:
      - namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: data
        podSelector:
          matchLabels:
            app: postgres
    ports:
      - protocol: TCP
        port: 5432

Scenario 3: Default Deny + Allowlist

Start with default-deny, then allowlist only observed traffic:

# 1. Apply default deny policy
cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
EOF

# 2. Generate allowlist policies
kubectl kguardian gen netpol --all -n production \
  --output-dir ./production-policies

# 3. Apply allowlist policies
kubectl apply -f ./production-policies/

Now your namespace runs default-deny — only explicitly observed communication is allowed.

Troubleshooting

No Traffic Data

Symptom: CLI says “No traffic data found for pod” Solutions:

Ensure the pod has been running for at least 5 minutes
Generate some traffic (hit HTTP endpoints, trigger background jobs, etc.)

Check broker has data:

kubectl port-forward -n kguardian svc/kguardian-broker 9090:9090 &
curl http://localhost:9090/pod/traffic/mypod

Generated Policy Too Permissive

Symptom: Policy allows more than expected (e.g., allows entire namespace) Cause: Pods may lack specific labels, so kguardian falls back to broader selectors. Solution:

Add specific labels to your pods
Manually edit generated policies to tighten selectors
Re-generate after labeling

Policy Breaks Communication

Symptom: After applying policy, some connections fail Cause: Incomplete observation period - not all traffic was captured Solution:

Check pod logs for connection errors
Identify missing ingress/egress rules
Manually add missing rules or extend observation period

Generate Seccomp Profiles

Restrict syscalls based on observed behavior

CLI Reference

Complete flag documentation

Policy Gallery

Worked examples for nginx, Postgres, Prometheus, Istio, and more

Getting Started

Core Concepts

User Guides

Policy Gallery

CLI Reference

Advanced

Roadmap

Generating Network Policies

Overview

Basic Usage

Generate for a Single Pod

Batch Generation

All Pods in a Namespace

All Pods Across All Namespaces

Cilium Network Policies

Generate Cilium Policies

Cilium vs Kubernetes Policies

Dry Run and Applying

Dry Run (Default)

Recommended Workflow

Advanced Options

Custom Output Directory

Print to Stdout Only

Understanding Generated Policies

Policy Structure

How Peers are Identified

Common Scenarios

Scenario 1: Microservices Application

Scenario 2: Multi-Namespace Communication

Scenario 3: Default Deny + Allowlist

Troubleshooting

No Traffic Data

Generated Policy Too Permissive

Policy Breaks Communication

Generate Seccomp Profiles

CLI Reference

Policy Gallery

​Overview

​Basic Usage

​Generate for a Single Pod

​Batch Generation

​All Pods in a Namespace

​All Pods Across All Namespaces

​Cilium Network Policies

​Generate Cilium Policies

​Cilium vs Kubernetes Policies

​Dry Run and Applying

​Dry Run (Default)

​Recommended Workflow

​Advanced Options

​Custom Output Directory

​Print to Stdout Only

​Understanding Generated Policies

​Policy Structure

​How Peers are Identified

​Common Scenarios

​Scenario 1: Microservices Application

​Scenario 2: Multi-Namespace Communication

​Scenario 3: Default Deny + Allowlist

​Troubleshooting

​No Traffic Data

​Generated Policy Too Permissive

​Policy Breaks Communication

Generate Seccomp Profiles

CLI Reference

Policy Gallery

Overview

Basic Usage

Generate for a Single Pod

Batch Generation

All Pods in a Namespace

All Pods Across All Namespaces

Cilium Network Policies

Generate Cilium Policies

Cilium vs Kubernetes Policies

Dry Run and Applying

Dry Run (Default)

Recommended Workflow

Advanced Options

Custom Output Directory

Print to Stdout Only

Understanding Generated Policies

Policy Structure

How Peers are Identified

Common Scenarios

Scenario 1: Microservices Application

Scenario 2: Multi-Namespace Communication

Scenario 3: Default Deny + Allowlist

Troubleshooting

No Traffic Data

Generated Policy Too Permissive

Policy Breaks Communication