Secure Kubernetes using OPA Gatekeeper

What this lab covers

You deploy OPA Gatekeeper into a cluster and write policies enforcing four specific requirements: read-only root filesystems, no privilege escalation, no host network, and restricted hostPath volumes.

Each of those maps directly to an escape path. Privilege escalation and host mounts are how a pod reaches the node, and host network removes the isolation between the workload and the machine, so this is the defensive counterpart to the RBAC and container escape labs.

It assumes familiarity with Kubernetes manifests and suits platform engineers as much as security teams, since policy that breaks deployments is policy that gets removed.

How admission control works

When a resource is submitted to the API server, admission webhooks are consulted before it is persisted. Gatekeeper registers as a validating webhook, evaluates the object against policy, and returns an allow or deny decision with a message.

Policy is expressed in two layers. A constraint template defines the rule and its parameters in Rego, and a constraint instantiates that template against specific resource kinds and scopes. The separation exists so one rule can be applied several ways without being rewritten.

The evaluation point is what matters. A scanner that finds a privileged pod running has found an incident, and an admission policy that rejects it has prevented one, which is the difference between reporting and enforcing.

Rolling policy out without breaking things

Start in audit mode. Gatekeeper can evaluate and record violations without rejecting anything, which tells you exactly what would have broken before it does, and that list is nearly always longer than expected.

Exempt deliberately and narrowly. Some workloads genuinely need host access, monitoring agents and storage drivers among them, and the correct response is a documented exemption for those namespaces rather than a weakened rule for everyone.

Communicate the rejection clearly. A deny message that names the policy and explains the fix turns policy from an obstacle into guidance, and it is the difference between engineers working with the control and working around it.

Where this fits alongside other controls

Pod Security Standards cover much of the same ground with less flexibility and considerably less setup. If the built-in levels meet your needs, they are the simpler choice, and Gatekeeper earns its place when you need rules the standards do not express.

Policy engines also handle requirements beyond security, such as mandatory labels, approved registries and resource limits. That breadth is why platform teams frequently adopt them for governance and inherit the security benefit.

None of this replaces RBAC. Admission control governs what workloads may look like, and RBAC governs who may submit them, so the two answer different questions and a cluster needs both.

Applying this at work

• Deploy a policy engine in audit mode first and review what would be rejected before enforcing anything.
• Start with the four rules in this lab, which map directly to container escape paths.
• Document exemptions per namespace for workloads that genuinely require host access, rather than weakening the rule globally.
• Write deny messages that name the policy and explain the fix.
• Check whether Pod Security Standards already meet your requirements, since they are simpler where they suffice.

Frequently asked questions

What is the difference between a constraint template and a constraint?

The template defines the rule and its parameters in Rego. The constraint instantiates that template against specific resource kinds and scopes. The separation lets one rule be applied in several ways without rewriting it.

Should I use OPA Gatekeeper or Pod Security Standards?

Pod Security Standards are simpler and cover the common workload restrictions. A policy engine is worth adopting when you need rules the standards cannot express, or when you also want governance rules such as approved registries and mandatory labels.

How do I roll out policy without breaking deployments?

Run in audit mode first so violations are recorded without being rejected. That produces the list of what would break, which is almost always longer than expected, and lets you handle exemptions before enforcement.

Do I need my own cluster to practice this?

No. The lab runs in a live environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own infrastructure.

Which certification covers this in depth?

The Kubernetes Attack and Defense Bootcamp, Professional Edition (KRTP) covers Kubernetes attack and defense end to end, including RBAC, workload restrictions, admission control and the route from a cluster into the cloud account behind it.