Kubernetes Security: Implementing Policy-as-Code with OPA Gatekeeper

Why Manual Governance Fails

If you’re still relying on documentation to enforce cluster standards, you’ve already lost. I’ve seen teams spend weeks auditing YAML files, only to find a developer deployed an image from a public registry with root privileges. It’s exhausting, and more importantly, it’s not scalable.

To build a resilient platform, you need Policy-as-Code. By treating security rules like application code—version-controlled, tested, and automated—you shift security left. In the Kubernetes ecosystem, OPA Gatekeeper is the industry standard for this. It acts as a validating admission controller, intercepting requests before they touch your etcd storage.

How OPA Gatekeeper Works

Gatekeeper leverages the Open Policy Agent (OPA) engine but wraps it in a Kubernetes-native experience using Custom Resource Definitions (CRDs). Instead of writing complex Rego policies from scratch every time, you define two things:

1. ConstraintTemplates: The "logic" (Rego code) that defines what to check.
2. Constraints: The "configuration" that tells Gatekeeper which resources to apply that logic to.

Setting Up Gatekeeper

I recommend installing Gatekeeper via Helm. It’s the cleanest way to manage versions. At the time of writing, I’m using version 3.15.0.

Bash
helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts
helm install gatekeeper gatekeeper/gatekeeper -n gatekeeper-system --create-namespace

Once installed, you’ll see the gatekeeper-controller-manager pod running. It’s now ready to intercept API requests.

Implementing Your First Policy

Let’s solve a common problem: preventing containers from running as root. We’ll create a ConstraintTemplate that looks for the runAsNonRoot field in the SecurityContext.

1. Define the ConstraintTemplate

YAML
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8spspunprivileged
spec:
  crd:
    spec:
      names:
        kind: K8sPSPUnprivileged
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8spspunprivileged
        violation[{"msg": msg}] {
          not input.review.object.spec.securityContext.runAsNonRoot
          msg := "Containers must run as non-root"
        }

2. Apply the Constraint

Now, apply a Constraint to enforce this rule across your entire cluster.

YAML
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPUnprivileged
metadata:
  name: must-run-as-non-root
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]

Why This Matters for Cloud-Native Governance

When you implement Kubernetes security this way, you remove the human element from compliance. If a developer tries to apply a deployment manifest that violates your K8sPSPUnprivileged constraint, the Kubernetes API server will reject the request with a clear error message.

You aren't just blocking bad deployments; you’re providing feedback. When the API rejects their request, the developer sees exactly why their YAML failed. This creates a self-service culture where security is baked into the developer workflow rather than being a roadblock at the end of the pipeline.

Best Practices for Production

1. Audit Mode First: Don’t jump straight to enforcementAction: deny. Use dryrun or warn first. Gatekeeper’s audit feature will log violations without blocking deployments, allowing you to see what would break before you flip the switch.
2. Use Constraint Libraries: Don't reinvent the wheel. The Gatekeeper Library has pre-written Rego policies for common scenarios like ingress host conflicts, image registry restrictions, and resource limits.
3. Monitor Performance: Gatekeeper runs as a webhook. If your policies are inefficiently written, you will add latency to your kubectl apply commands. Keep your Rego logic simple and performant.
4. Version Control: Store your templates and constraints in your GitOps repository. Treat them exactly like your application code—PRs, reviews, and automated tests.

Final Thoughts

Adopting admission controllers via OPA Gatekeeper is the single most effective way to secure a multi-tenant cluster. It’s not just about stopping hackers; it’s about preventing "configuration drift" that eventually leads to production outages. Start small, audit your existing environment, and gradually tighten your policies. Your future self will thank you when the next audit comes around.