"Not a Pentest" Notice: Policy enforcement guide for your own Kubernetes clusters.

Runtime Policy Enforcement · Policy-as-Code

Runtime Policy Enforcement: OPA, Falco & Cilium

Three enforcement layers, three time points: OPA stops bad deployments before they start. Falco detects bad behavior during execution. Cilium blocks unauthorized network traffic in real-time.

Enforcement layers

OPA

Deploy-time

Falco

Runtime

Cilium

Network

3 Policy Layers

Admission (Deploy-time)OPA Gatekeeper

When: Before workload is admitted to cluster

Example policies:

Block images from untrusted registriesRequire resource limits on all containersDeny privileged containersEnforce pod security standardsRequire labels (owner, env, app)

# OPA policy: deny privileged containers
package kubernetes.admission

deny[msg] {
  input.request.kind.kind == "Pod"
  container := input.request.object.spec.containers[_]
  container.securityContext.privileged == true
  msg := sprintf("Privileged container denied: %v", [container.name])
}

Runtime (Execution-time)Falco

When: While workload is running

Example policies:

Alert on unexpected shell in containerDetect /etc/shadow readAlert on outbound connection to unexpected IPDetect process spawning from unexpected parentAlert on kernel module load

- rule: Shell Spawned in Container
  desc: Unexpected shell execution in container
  condition: >
    spawned_process and container
    and proc.name in (shell_binaries)
    and not proc.pname in (allowed_shell_parents)
  output: >
    Shell spawned (user=%user.name container=%container.name
    parent=%proc.pname shell=%proc.name)
  priority: WARNING

Network (Traffic-time)Cilium NetworkPolicy

When: On every network packet

Example policies:

Deny all egress by defaultAllow only declared service-to-service pathsBlock direct pod-to-pod across namespacesRequire L7 HTTP policy for external traffic

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
spec:
  endpointSelector:
    matchLabels: {app: api-server}
  ingress:
  - fromEndpoints:
    - matchLabels: {app: frontend}
    toPorts:
    - ports: [{port: "8080", protocol: TCP}]
  egress:
  - toEndpoints:
    - matchLabels: {app: postgres}

Frequently Asked Questions

What is the difference between admission control and runtime enforcement?

Admission control (OPA Gatekeeper, Kyverno) runs at deploy-time — when you kubectl apply or Helm install. It acts as a gatekeeper: if the manifest violates policy, deployment is rejected before any container starts. Runtime enforcement (Falco) runs while containers are executing. It can't prevent a violating container from starting (if admission didn't catch it), but it detects violations in real-time and triggers alerts or automatic responses. Both are necessary: admission prevents known-bad deployments; runtime catches unexpected behavior in already-running workloads.

Should I use OPA Gatekeeper or Kyverno?

Both are CNCF projects for Kubernetes policy enforcement. Key differences: OPA Gatekeeper uses Rego (OPA's policy language) — very powerful but has a learning curve. Kyverno uses YAML-based policies — much easier to start with, less powerful for complex logic. For most teams: start with Kyverno for quick policy wins (deny privileged, require labels, enforce image registry). Graduate to OPA Gatekeeper if you need complex logic (cross-resource validation, external data lookups). OpenClaw integrates with both.

How do I write Falco rules without false positives overwhelming my team?

Falco rule tuning strategy: 1) Start with Falco's default rules — don't write custom rules until you understand the noise. 2) Run in alert-only mode for 2 weeks — collect what fires. 3) Add exceptions for known-good patterns: not (proc.name = 'my-app' and proc.pname = 'supervisord'). 4) Use tagged rules — enable only rules relevant to your stack. 5) Set up Falco alerts → OpenClaw → suppress duplicate alerts with a 5-minute dedup window. 6) Only escalate CRITICAL and ERROR priority to on-call. WARNING goes to a monitoring dashboard for weekly review.

How does OpenClaw integrate OPA and Falco into unified policy management?

OpenClaw provides a unified policy dashboard that aggregates: OPA Gatekeeper audit results (which running workloads currently violate policy), Falco alert stream (runtime violations in real-time), Cilium network policy violations, and custom OpenClaw security check results. From the OpenClaw dashboard you can: push updated OPA policies to Gatekeeper, enable/disable Falco rules, see policy coverage (what % of your workloads have each policy applied), and trigger automated remediation for common violations.