Skip to main content

Governing Cedar-compatible PDPs

Objective​

Explain that Writ governs Cedar-compatible PDPs (AWS Verified Permissions and other Cedar engines) as well as OPA and Enterprise OPA, that Cedar is a separate policy language and not Rego, and that Writ's job of signing and promoting governed policy is the same regardless of the target PDP's dialect.

Concept​

Lesson 1 stated the boundary: Writ governs OPA, Enterprise OPA, and Cedar-compatible PDPs, and it is never a PDP on the request path. The OPA lab in this course makes the OPA half concrete. This lesson makes the Cedar half concrete, because a common misread is that Writ is "an OPA tool." It is not. Writ governs authorization policy, and the target decision engine can speak more than one dialect.

Cedar is a different policy language, not Rego​

Cedar is a policy language used by Cedar-compatible PDPs such as AWS Verified Permissions. It is not Rego, and it does not run under opa. opa evaluates Rego; a Cedar engine evaluates Cedar. They are separate languages with separate evaluators. You cannot opa test a Cedar policy, which is exactly why this lesson ships no runnable Cedar lab: there is no Cedar engine installed here, and pretending opa could run Cedar would be wrong.

What the two share is the shape of the problem. Both answer the same question, "for this subject, action, and resource, allow or deny?", and both are default-deny: anything not explicitly permitted is denied. Cedar expresses that with permit statements against an implicit deny; Rego expresses it with allow rules on top of default allow := false. Same intent, different syntax.

Writ's job is dialect-agnostic​

Here is the point that matters for the control plane. Everything you learned in the previous lessons, policy lives in Git, Writ builds and signs an artifact, promotion moves that one signed artifact dev to staging to prod, rollback keys on a prior commit_sha, and decision logs plus replay give you an audit trail, is about governing policy. None of it depends on the policy being Rego.

Writ signs and promotes the governed policy artifact and scopes it on the tenant, org, system, app hierarchy no matter which dialect the target PDP speaks. A team standardized on AWS Verified Permissions still gets Git as the source of truth, a signed and promotable artifact, environment promotion, and audit. Writ governs the lifecycle; the PDP evaluates the decision in its own language.

One caveat to keep the mental model honest: the artifact opa build produces is specifically an OPA bundle for OPA and Enterprise OPA. A Cedar-compatible PDP loads Cedar policy in its own form, not an OPA bundle. So "same bundle format everywhere" is not the claim. The claim is that the governance workflow (Git provenance, signing, promotion, rollback by commit_sha, decision logs, replay) is the same control-plane experience across dialects, even though the underlying policy artifact matches whatever the target PDP consumes.

The same intent in two dialects​

Take the exact rules the lab policy models: admins may do anything; editors may read or write within their own org; viewers may read within their own org; everything else is denied. First, the Rego the lab actually runs (this is what opa evaluates on the PDP):

# Rego — runnable in this lab; evaluated by OPA / Enterprise OPA.
package university.writ.docs_authz

default allow := false

# Admins may perform any action.
allow if {
	input.subject.role == "admin"
}

# Editors may read or write within their own org.
allow if {
	input.subject.role == "editor"
	input.action in {"read", "write"}
	input.subject.org == input.resource.org
}

# Viewers may read within their own org.
allow if {
	input.subject.role == "viewer"
	input.action == "read"
	input.subject.org == input.resource.org
}

Now the same authorization intent expressed in Cedar. This snippet is illustrative Cedar, not runnable in this lab: there is no Cedar engine here, and opa cannot evaluate it. It is here so you can see that the governed policy is not always Rego.

// Cedar — illustrative only. A separate policy language; NOT Rego.
// Evaluated by a Cedar-compatible PDP (e.g. AWS Verified Permissions),
// never by opa. Cedar is default-deny: anything not permitted is denied.

// Admins may perform any action on any document.
permit (
  principal in Role::"admin",
  action,
  resource
);

// Editors may read or write a document owned by their own org.
permit (
  principal in Role::"editor",
  action in [Action::"read", Action::"write"],
  resource is Document
)
when { principal.org == resource.org };

// Viewers may read a document owned by their own org.
permit (
  principal in Role::"viewer",
  action == Action::"read",
  resource is Document
)
when { principal.org == resource.org };

Read them side by side. Rego's default allow := false and Cedar's implicit deny are the same default-deny posture. Rego's allow if { ... } rules and Cedar's permit ( ... ) when { ... } statements both add explicit allow paths on top of that default. The org check (input.subject.org == input.resource.org in Rego, principal.org == resource.org in Cedar) is the same condition. What differs is only the language the PDP reads. Writ governs either one the same way.

Hands-on lab​

There is nothing new to run here, and that is the lesson: the governed artifact in this course stays the OPA policy, and the OPA suite is still your ground truth. Run it and confirm it is green:

git clone https://github.com/EnforceAuth/university-labs.git
cd university-labs
opa test courses/govern-with-writ -v

Expected once you have completed the earlier lessons' TODO(learner): PASS: 6/6.

Now do a paper exercise, no tooling. Open ../lab/policy.rego and put the Cedar snippet above next to it. For each of the lab's tests (admin delete, editor write own org, editor write other org, viewer read own org, viewer write own org), trace which Cedar permit statement would fire, or whether the request falls through to Cedar's implicit deny. You should reach the same allow/deny for every case that the Rego reaches, because the intent is identical. Do not try to opa test the Cedar snippet: opa evaluates Rego only, and Cedar has no evaluator in this lab. The takeaway is that Writ would sign, promote, and audit either policy the same way, while the PDP evaluates whichever dialect it speaks.

Check for understanding​

  1. A teammate says "Writ is an OPA tool, so it can only govern Rego." Correct them in one sentence: what else does Writ govern, and is Cedar the same language as Rego?
  2. Why does this lesson ship no runnable Cedar lab, and what would go wrong if you tried to opa test the Cedar snippet?
  3. Name three parts of the Writ governance workflow that are the same whether the target PDP evaluates Rego or Cedar, and name the one thing that is not the same (the artifact the PDP loads).