“Policy as code” covers a wider range of tools than it first appears. Some enforce rules on who can do what inside an application; others enforce rules on how infrastructure is allowed to be configured in the first place. This piece is about the second kind — a different, complementary layer to the relationship-based authorization systems covered in our Zanzibar/ReBAC explainer. Open Policy Agent (OPA), Kyverno, and AWS Config all let teams encode infrastructure and configuration rules as version-controlled policy rather than tribal knowledge or manual review, but they enforce those rules at different points, for different scopes, and with meaningfully different deployment models. Here’s how each actually works.
At a Glance
| Factor | Open Policy Agent (OPA) | Kyverno | AWS Config |
|---|---|---|---|
| Scope | General-purpose — Kubernetes, microservices, CI/CD, Terraform, CloudFormation, APIs | Kubernetes-native (usable outside clusters too) | AWS resource configuration only |
| Policy language | Rego (custom declarative language) | YAML + CEL, as native Kubernetes resources | Managed or custom rules (Guard DSL or Lambda) |
| Enforcement point | Decision engine queried by your software (sidecar, server, or library) | Kubernetes admission controller, CLI scanner, or runtime | Evaluates recorded resource configs; can auto-remediate |
| Learning curve | Higher — Rego is a new, Datalog-like language | Lower — “no new language to learn” per its own docs | Low for managed rules; higher for custom logic |
| Pricing model | Free, open source (CNCF graduated) | Free, open source (CNCF) | Metered: billed per configuration item and per rule evaluation |
| Governance body | CNCF (graduated) | CNCF | AWS proprietary service |
Two Different Layers: Authorization vs Infrastructure Policy
It’s worth being precise about what these tools are not. Systems like Google Zanzibar, SpiceDB, and OpenFGA answer application-level authorization questions — “can this user view this document?” — by modeling relationships between users and resources. OPA, Kyverno, and AWS Config answer a different question entirely: “is this piece of infrastructure, Kubernetes manifest, or cloud resource configured the way our policy says it should be?” One layer governs who can do what inside your product; the other governs whether the systems your product runs on are compliant, secure, and consistent. A mature security posture typically uses both, and conflating them is a common mistake when teams first adopt policy-as-code.
Open Policy Agent (OPA): The General-Purpose Engine
OPA, a CNCF graduated project, describes itself in its own documentation as “a general-purpose policy engine that unifies policy enforcement across the stack.” Its design is deliberately decoupled from any one system: your application or infrastructure component sends OPA structured data (typically JSON) as input, and OPA evaluates that input against policies written in Rego, its purpose-built declarative language for reasoning over complex, hierarchical data, then returns a decision — which can be a simple allow/deny or arbitrary structured output.
That generality is OPA’s core trade-off. Its documentation lists an unusually wide integration surface: Kubernetes admission control, microservices and API gateways, Envoy and Istio service meshes, HTTP and GraphQL APIs, Kafka, Docker, SSH/sudo access control, Terraform plans, and AWS CloudFormation hooks. OPA typically runs as a standalone HTTP server (opa run --server, listening on localhost:8181 by default) that other systems query, or it can be embedded directly into Go programs via its rego package. The cost of that flexibility is Rego itself: it’s a genuinely new, Datalog-inspired language, and teams adopting OPA for the first time generally need to budget real ramp-up time for it, which is the single most common criticism leveled at OPA versus more narrowly scoped alternatives.
Kyverno: Kubernetes-Native, No New Language
Kyverno (also CNCF-hosted) was purpose-built for Kubernetes and has since expanded to work outside clusters as a more general policy tool, but its design center of gravity remains Kubernetes-native resource governance. Its own documentation leads with the contrast to Rego-based tools directly: policies are authored in YAML and CEL (Common Expression Language) as native Kubernetes resources managed the same way as any other manifest — with kubectl, Git, and kustomize — rather than in a separate policy language, which Kyverno’s docs frame as “no new language to learn.”
Functionally, Kyverno can validate, mutate, generate, or clean up Kubernetes resources, and it can verify container images and their metadata for supply-chain security — a feature set aimed squarely at platform engineering teams who need to enforce security and compliance baselines on application teams without those teams learning a new DSL. Deployment is correspondingly Kubernetes-centric: as an admission controller intercepting the API server, as a CLI-based scanner for CI pipelines, or evaluated at runtime, with results reported in the OpenReport format for integration with other tooling. Kyverno is the right fit when the governance problem is specifically “Kubernetes resources,” and the wrong fit when policy needs to span non-Kubernetes systems the way OPA can.
AWS Config: Cloud Resource Configuration, Metered
AWS Config is a different animal again: a managed AWS service, not an open source project, scoped specifically to AWS resource configuration rather than Kubernetes manifests or arbitrary application data. It continuously records the configuration of supported AWS resources and evaluates those recorded configurations against rules — either AWS-managed rules for common best practices or custom rules written against AWS’s own Guard policy DSL or backed by a Lambda function — flagging or, with remediation configured, automatically correcting non-compliant resources.
Unlike OPA and Kyverno, AWS Config is not free. According to AWS’s own pricing page (checked November 2026), the core charges are $0.003 per configuration item recorded with continuous recording (versus $0.012 per item under periodic recording), plus $0.001 per conformance pack evaluation and $0.001 per active Config rule evaluation for the first 100,000 evaluations in a region per month, with AWS’s documentation noting proactive evaluations from rules that support both proactive and detective modes are priced at $0 when run in combination. AWS states there is no free tier for this service and no minimum commitment — you pay purely for configuration items recorded and rule evaluations run, which means cost scales directly with both the size of your AWS footprint and the number of rules you turn on.
Choosing Between Them
- Choose OPA when policy needs to span multiple, heterogeneous systems — Kubernetes admission control alongside API authorization, CI/CD gates, and Terraform plan checks — and your team can invest in learning Rego, or already has.
- Choose Kyverno when the governance problem is specifically Kubernetes, your platform team wants policies that look like any other Kubernetes YAML manifest, and you want to avoid introducing a new policy language to application teams.
- Choose AWS Config when you’re all-in on AWS and need continuous, automatic auditing of actual deployed resource configuration against compliance baselines (CIS benchmarks, internal standards), accepting its per-evaluation metered cost as the price of that continuous visibility.
- Many mature AWS + Kubernetes shops run more than one: AWS Config for account- and resource-level compliance drift detection, plus Kyverno or OPA/Gatekeeper for admission-time enforcement inside the cluster — because Config audits after the fact, while Kyverno/OPA can block a non-compliant resource before it’s ever created.
Trade-offs Summary
- OPA pros: broadest scope, CNCF-graduated maturity, works across Kubernetes and non-Kubernetes systems alike.
- OPA cons: Rego’s learning curve is real and frequently cited as the main adoption barrier.
- Kyverno pros: no new language, deeply Kubernetes-native, straightforward GitOps-style policy management.
- Kyverno cons: scope is narrower than OPA’s outside the Kubernetes world.
- AWS Config pros: deep, continuous AWS-native visibility and automatic remediation options, managed rule library for common compliance frameworks.
- AWS Config cons: real metered cost that scales with resource count and rule evaluations, and it’s AWS-only — no multi-cloud coverage.
The Bottom Line
OPA, Kyverno, and AWS Config aren’t really competitors so much as three tools covering overlapping but distinct ground: general-purpose policy across many systems, Kubernetes-native governance without a new language, and AWS-specific continuous configuration auditing with a real metered bill attached. The practical pattern in 2026 is less “pick one” and more “pick the layer that matches the gap”: Kubernetes shops that want zero new languages lean Kyverno; teams with policy needs spanning multiple systems lean OPA; AWS-centric organizations layer Config on top of either for continuous drift detection, budgeting for its per-evaluation pricing as an operating cost rather than a one-time setup fee.
FAQ
Is this the same thing as Zanzibar/ReBAC authorization?
No. ReBAC systems like Zanzibar, SpiceDB, and OpenFGA govern application-level access decisions (who can see or edit what). OPA, Kyverno, and AWS Config govern infrastructure and resource configuration — a separate, complementary layer, not a substitute.
Does Kyverno replace OPA/Gatekeeper?
For Kubernetes-only use cases, many teams choose Kyverno specifically to avoid Rego. For policy needs spanning beyond Kubernetes, OPA’s broader integration surface still has no direct Kyverno equivalent.
How much does AWS Config actually cost for a mid-sized account?
It depends entirely on resource count and rules enabled, since pricing is per configuration item recorded plus per rule evaluation, with no free tier. AWS’s own pricing page is the authoritative source and should be checked directly, since the component rates ($0.003 per config item, $0.001 per rule evaluation for the first 100,000) can change.
Can OPA and AWS Config be used together?
Yes, and it’s a common pattern — OPA (often via Gatekeeper) enforcing policy at Kubernetes admission time inside a cluster, while AWS Config continuously audits the broader AWS account for drift and compliance across resources Kubernetes doesn’t touch.
Is Rego hard to learn?
It has a real learning curve — it’s a declarative, Datalog-style language unlike most imperative languages developers already know — which is why Kyverno’s YAML/CEL approach markets itself explicitly against that friction for Kubernetes-only use cases.
Sources
Related reading on this site: Google Zanzibar Explained: Relationship-Based Authorization and Secrets Management for Cloud-Native Pipelines in 2026.