For the past eighteen months, our platform team had been using Claw, a powerful but intricate policy-as-code framework, to manage security and compliance guardrails for our Kubernetes deployments. While its expressive language was technically impressive, our operational data revealed a growing problem: the average time for a developer's pull request to pass security review had ballooned to 72 hours. This wasn't due to a lack of reviewer bandwidth, but rather the complexity of the policy definitions themselves. Diagnosing a "REJECT" decision often required tracing through a chain of interdependent rules, a task that demanded deep Claw expertise possessed by only three team members.
We conducted a root cause analysis and identified three primary friction points:
* **Cognitive Load for Developers:** A failed policy yielded a generic "policy violation" message. The onus was on the developer to either decipher the Claw rule logic or wait for a platform engineer to interpret it.
* **Maintenance Overhead:** Writing and testing a new Claw policy was a project unto itself, discouraging the creation of simple, situational guardrails.
* **Slow Feedback Loop:** Because the system was opaque, developers would often push code, wait for the CI pipeline to fail, and then begin the lengthy diagnosis process, wasting valuable cycle time.
We decided on a radical simplification. We replaced the core of our system with a combination of **Open Policy Agent (OPA) with the Conftest utility** for static analysis of manifests, and a small set of targeted, mutating **Kyverno policies** for live cluster enforcement. The key was not just the tools, but a strict design philosophy: one policy, one clear purpose, one actionable error message.
Our new structure is split into two clear phases:
**Phase 1: Static Validation (CI Pipeline)**
We use `conftest` to test Kubernetes YAML *before* it even reaches a cluster. Each policy is a standalone Rego file with a descriptive name. The critical improvement is the custom failure message.
```rego
# policy/container_image_repo.rego
package main
deny[msg] {
input.kind == "Deployment"
image := input.spec.template.spec.containers[_].image
not startswith(image, "mycompany.azurecr.io/")
msg := sprintf("Container image '%s' must be sourced from company registry 'mycompany.azurecr.io/'", [image])
}
```
A pipeline failure now outputs: `FAIL - container_image_repo - Container image 'nginx:latest' must be sourced from company registry 'mycompany.azurecr.io/'`. The developer knows exactly what to fix.
**Phase 2: Cluster Enforcement (Kyverno)**
For policies that require mutation or runtime context, we use Kyverno. Its policies are Kubernetes-native CRDs, which are easier for our SREs to read and audit.
```yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-pod-requests-limits
spec:
validationFailureAction: Enforce
rules:
- name: validate-resources
match:
resources:
kinds:
- Pod
validate:
message: "CPU and memory resource requests and limits are required."
pattern:
spec:
containers:
- resources:
requests:
memory: "?*"
cpu: "?*"
limits:
memory: "?*"
cpu: "?*"
```
**The Results & What We Learned**
After a three-month transition period, we measured the impact over the following month:
* **Mean Security Review Time:** Dropped from 72 hours to **14 hours** (80.5% reduction).
* **Policy Creation Time:** New, simple guardrails are now drafted and deployed in under 2 hours, versus 2+ days previously.
* **Platform Team Interruptions:** Reduced by approximately 70%, as developers act on clear messages without requiring escalation.
The primary lesson was that **elegant complexity often creates operational drag**. For our mid-scale platform (managing ~200 services), the raw power of a system like Claw was grossly underutilized and came with a hidden tax. By opting for simpler, more transparent tools and investing effort into crafting human-readable outcomes, we shifted left *effectively*. Developers are now empowered with information, not blocked by a mysterious system. Our role has evolved from being decipherers of policy logic to curators of a clear and actionable rulebook.
—Chris
Data over dogma
We ran a very similar migration last year. I'm a marketing ops tech lead at a mid-market SaaS company, around 500 employees. Our dev and platform teams own our Kubernetes tooling, but my team's services run on it and we manage the security policies for our own marketing workloads. We replaced Claw with OPA (Open Policy Agent) for most of our guardrails.
* **Cognitive Load for Developers:** This is the biggest win. With OPA, we write rules in Rego, but we pair it with the `conftest` CLI tool. When a policy fails, we can output specific, human-readable violation messages pointing to the exact manifest and field. Our average "time to diagnose" for devs went from hours to under 10 minutes. No more generic "policy violation" blocks.
* **Maintenance Overhead:** Claw felt like building a car to go to the corner store. For straightforward guardrails (required labels, blocked image registries, allowed resource types), an OPA/Rego policy is often 10-15 lines. We went from one major policy update per quarter to being able to spin up a situational rule in an afternoon. The learning curve from zero to basic policies is a week, not a month.
* **Hidden Cost - Expertise Concentration:** You hit on this: with Claw, we had 2 "gurus." With OPA, we've trained up 8 people who can confidently write and debug policies because the community and examples are vast. The bus factor matters. The real cost was the blocker those 2 gurus represented on every project.
* **Where It Clearly Wins:** Speed of feedback. We integrated OPA directly into our CI pipeline using `conftest`. Policy evaluation happens in under 30 seconds when a PR is opened. Developers get a pass/fail with details *before* a platform engineer even looks at it. That alone cut our security review cycle time by more than half.
My pick is OPA, specifically if your primary use case is straightforward Kubernetes manifest validation and you need to scale policy ownership beyond a tiny team. It's the pragmatic choice. If your needs are highly complex, like evaluating runtime data across multiple cloud services, then Claw's depth might still be justified. To make a clean call, tell us the most complex policy you have and how often you need to create new ones.
Cheers, Henry