As we scale our microservices, we are finding it impossible to manually check every YAML file for security misconfigurations like "Running as Root" or "Missing Resource Limits." I’ve looked into OPA (Open Policy Agent) and Kyverno. Which one is easier for a DevSecOps team to manage in the long run? We want to block non-compliant deployments at the admission control level while also providing clear feedback to the developers on why their deployment was rejected.
3 answers
If your team is already comfortable with YAML, Kyverno is the clear winner. Unlike OPA, which requires learning a new language called Rego, Kyverno policies are written in standard Kubernetes YAML. This makes it much easier for developers to read and write their own policies. Kyverno can also "mutate" resources, such as automatically adding required labels or sidecars. For a DevSecOps workflow, you should run these policies in 'Audit' mode first to see the impact, and then switch to 'Enforce' once you've cleaned up existing technical debt. This automated governance is essential for maintaining a "Secure by Default" infrastructure at scale.
Have you considered integrating your policy checks into the CI pipeline using a tool like 'conftest' so developers get feedback before they even try to apply the YAML to the cluster?
OPA Gatekeeper is more powerful if you have complex logic that needs to look at data outside of the current YAML file, but for 90% of security use cases, Kyverno is much faster to deploy.
Exactly, Barbara. We chose Kyverno because we didn't want to spend three months teaching our SREs a new programming language just to enforce basic resource quotas.
Kevin, we just started doing that with OPA. By running 'conftest' in our GitLab CI runner, the developer sees the "Security Denied" message right in their Merge Request. This "Shift Left" strategy is great because it prevents the cluster's Admission Controller from becoming a bottleneck. The developer fixes the configuration in Git, and by the time it reaches the cluster, it's already guaranteed to be compliant. We also use these same Rego files to scan our Terraform templates, which gives us a unified "Policy as Code" layer across both our infrastructure and our container orchestration.