If you run Kubernetes, and you haven’t heard of OPA Gatekeeper,  you need to get across it. Its the only sure-fire way to ensure you Kubernetes cluster(s) are actually running safe and compliant workloads.

Think of OPA Gatekeeper as the bouncer at the door of your Kubernetes cluster. Its job is to check every deployment request as it comes in and decide who gets in and who gets turned away (aka an admission controller). Developers and operators can line up with whatever they want to deploy, but OPA is there to stop anything that looks risky, such as containers running as root, host paths, or images from unapproved registries.

It is a brilliant concept. Kubernetes needs guardrails, and OPA, short for Open Policy Agent, provides them. It lets you define security and compliance policies cluster-wide, so that risky deployments never make it into the cluster in the first place. For a manager, that sounds like the holy grail. Every cluster follows the same rules, every deployment is automatically checked, and no one can accidentally introduce something dangerous.

Because OPA was the first of its kind, it quickly became the gold standard for policy enforcement in Kubernetes. Its younger cousins, Kyverno and KubeWarden, were later built on the same idea. They promise easier syntax and tighter Kubernetes integration, but the goal remains the same: define the rules, enforce them automatically, and sleep better at night.

At least, that is the theory.

In practice, OPA can feel less like a bouncer and more like a bureaucrat with a bad temper. It speaks its own language called Rego, and you need to write your policies carefully. One misplaced condition can end up blocking critical system services or, worse, locking your own team out of the cluster entirely. To prevent that, you have to write long lists of exclusions for namespaces, service accounts, and controllers. Miss one, and everything grinds to a halt.

Soon you are not just enforcing policy, you are managing a miniature legal system. Every rule needs testing, every exclusion needs tracking, and every cluster ends up with its own variation. Kyverno tried to make this easier by using YAML instead of Rego, but the result is the same. Enforcing security policies sounds simple until you realise it becomes another full-time job.

This is exactly why Styra, the creators and maintainers of OPA, built a commercial control plane for it. Their product, Styra Declarative Authorization Service, makes managing all those policies far easier by adding dashboards, drift detection, versioning, and the guardrails you wish OPA had out of the box. Of course, those guardrails come at a price. The open-source OPA gives you the power, while the commercial version makes it manageable.

Or you could just use Portainer.

With Portainer, you do not need to understand Rego or worry about exclusions. You simply enable ‘Security Constraints” for each cluster, select the rules you want, such as “no privileged containers” or “no host paths,” and Portainer handles the rest.

Behind the scenes, Portainer deploys and configures OPA Gatekeeper for you with safe defaults that will not lock you out or break your cluster. You get all the policy control you want without the syntax headaches, the risk, or the extra licensing cost.

So if your Kubernetes platform is not running OPA Gatekeeper, due to concerns about its complexity, stop avoiding best-practice security, and use Portainer to manage it for you.