OPA vs Cedar: policy engines compared for application authorisation

OPA evaluates Rego rules against an input document (the request) and a data document (loaded facts). Rules are queries: a rule is true if all its expressions hold for some binding of variables, and you can generate sets, objects and messages. OPA has no built-in notion of users or resources; you model everything. Since OPA 1.0, Rego v1 syntax with if and contains is the default.

Cedar evaluates permit and forbid policies over a request of principal, action, resource and context, plus an entity store with attributes and parent relationships. The language is deliberately limited (no loops, no arbitrary recursion) so it always terminates, can be validated against a schema, and can be analysed to answer questions such as whether two policy sets allow the same requests.

Rule: a user can view a document they own or one from their department, but nobody can view an archived document.

package docs.authz

default allow := false

allow if {
	input.action == "view"
	not input.resource.archived
	input.resource.owner == input.principal.id
}

allow if {
	input.action == "view"
	not input.resource.archived
	input.resource.department == input.principal.department
}

permit (
  principal,
  action == Action::"view",
  resource is Document
)
when { resource.owner == principal };

permit (
  principal is User,
  action == Action::"view",
  resource is Document
)
when { resource.department == principal.department };

forbid (principal, action, resource is Document)
when { resource.archived };

Note the difference in how the exception is expressed. In Rego the archived check has to be repeated in every allow rule, or factored into a helper. In Cedar a single forbid overrides every permit, so a new permit added later cannot accidentally reopen archived documents.

• Kubernetes admission, Terraform plans, CI config checks or Envoy ext_authz: OPA, with Gatekeeper or conftest. The ecosystem is there and the output is often a list of violations, not a yes or no.
• Fine-grained permissions in your own application, especially multi-tenant SaaS: Cedar. The principal, action, resource model and forbid-wins semantics match the problem.
• You need to prove properties of policy changes, such as a refactor allowing nothing new: Cedar's analysis tooling is built for this.
• Large relationship graphs (Google Docs style sharing at scale): neither alone. Cedar needs the relevant entities passed in with each request; consider a Zanzibar-style ReBAC system and use Cedar or OPA for the attribute rules on top.
• Data filtering (which rows can this user see): OPA partial evaluation can compile policy into query conditions; Cedar's equivalent is less mature.

• Rego: writing rules that are undefined rather than false and forgetting a default. Always set default allow := false.
• Rego: mixing pre-1.0 syntax (no if, no contains) with OPA 1.x. Run opa fmt and opa check, or the rego.v1 import on older versions.
• Cedar: expecting policies to fetch data. Cedar evaluates only the entities you supply, so your app must load the principal, resource and their parents first.
• Both: putting the engine on the network path for every request without caching or a local sidecar. Authorisation latency adds to every call.
• Migrating Rego to Cedar: translate deny rules into forbid policies and let them stand alone, rather than folding conditions into every permit.