Cedar

Cedar#

Cedar is an authorization policy language released by AWS in 2023 (open source under Apache 2.0). The design goal: simpler than Rego, fast, formally analyzable, and focused on application-level authorization questions (“can principal P do action A on resource R?”).

Used by AWS Verified Permissions, AWS Verified Access, Cedar agents embedded in services, and a growing number of community projects.

The Mental Model#

A Cedar request is a tuple.

(principal, action, resource, context)

Cedar policies decide Allow or Deny. Decisions are pure functions of the request and the policy set. The engine’s strong analyzability comes from the deliberately limited language.

A Minimal Policy#

permit (
  principal in Group::"Admins",
  action,
  resource
);

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

forbid (
  principal,
  action,
  resource is Document
) when {
  resource.tags.contains("classified")
} unless {
  principal in Group::"ClearedStaff"
};

Effects#

Cedar policies can permit or forbid. The semantics are deliberately blunt: any matching forbid wins, otherwise at least one matching permit is required. There is no “most-specific match” rule; the engine evaluates every policy and combines results predictably.

Two effects.

  • permit, “this combination is allowed”.

  • forbid, “this combination is forbidden, regardless of permits”.

Cedar’s evaluation is straightforward: any forbid that applies wins. Otherwise, if at least one permit applies, the request is allowed.

Scopes and Conditions#

Each Cedar policy has a head and an optional body. The head binds principal, action, and resource; in and is filter by entity hierarchy or type; when and unless add boolean conditions over attributes. Together they shape exactly which requests the policy applies to.

The “head” of a policy filters by entity.

permit (
  principal in Group::"Admins",
  action == Action::"DeleteDocument",
  resource is Document
) when {
  resource.created_at < datetime("2024-01-01T00:00:00Z")
};

  • principal / action / resource, entity scope.

  • in <Entity>, membership test (groups, parents).

  • is <Type>, type test.

  • when { ... }, additional condition; must be true.

  • unless { ... }, additional condition; must be false.

Entities#

Cedar models the world as typed entities with attributes and parents.

[
  {
    "uid":    { "type": "User", "id": "operator" },
    "attrs":  { "department": "engineering" },
    "parents":[{ "type": "Group", "id": "Admins" }]
  },
  {
    "uid":    { "type": "Document", "id": "doc-1" },
    "attrs":  { "owner": { "__entity": { "type": "User", "id": "operator" } },
                "tags":  ["public"] },
    "parents":[]
  }
]

Parents form a hierarchy used by in, as in principal in Group::"Admins".

Schemas#

Cedar policies validate against a schema describing entity types, actions, and attributes. The schema lets the engine catch bad policies at deploy time.

namespace Acme {
  entity User { name: String, department: String };
  entity Group;
  entity Document { owner: User, tags: Set<String>, created_at: String };
  action ReadDocument
    appliesTo {
      principal: [User],
      resource:  [Document]
    };
}

Why “Formally Analyzable”#

Cedar policies can be statically reasoned about: equivalence checks, “is permission P implied by policies?”, “are these two policy sets equivalent?”. The deliberate restrictions on the language (no unbounded recursion, total functions, side-effect-free) enable analysis that Rego policies don’t get.

In practice this means.

  • You can prove that a refactor doesn’t widen access.

  • You can find dead policies.

  • You can compare two policy sets.

AWS ships these tools; community implementations are catching up.

Common Use Cases#

The kinds of work Cedar was designed for. Application-level authorization, API gateway pre-checks, multi-tenant SaaS isolation, and shared policy bundles across microservices – each one fits the “can principal do action on resource” question Cedar answers natively.

  • Application-level authz, “can user X do action Y on object Z?”.

  • API gateways, before hitting backend services.

  • Multi-tenant SaaS, per-tenant isolation, role definitions.

  • Microservices, shared policy bundle distributed to each service.

Tooling#

The CLI, language bindings, managed services, and IDE extensions that surround Cedar in 2026. The Rust core compiles to Wasm so JavaScript and TypeScript bindings cover the browser; AWS Verified Permissions runs Cedar as a managed service with a familiar API.

  • cedar-cli, evaluate, validate, analyze policies.

  • AWS Verified Permissions, managed Cedar service.

  • Bindings, Rust, JavaScript / TypeScript (via Wasm), Go, Python, Java; the Rust core compiles everywhere.

  • Visual Studio Code extension, syntax highlighting and validation.

Cedar vs. Rego#

The most common policy-language comparison an operator faces when picking a stack. Cedar is narrower and analyzable; Rego is broader and Turing-complete. The right pick depends on whether the workload is application authorization (Cedar) or cross-cutting policy across heterogeneous systems (Rego).

Aspect

Cedar Rego (OPA)

Domain

Application authz General-purpose policy

Power

Limited (deliberate) Turing-complete

Analyzability

Strong (formal verification) Weak

Schema

First-class Optional

Engine

Embedded library or service Sidecar daemon (typical)

Integrations

AWS-first; growing Massive ecosystem

Learning curve

Smaller Steeper

For straightforward “who can do what” decisions, Cedar is often easier and safer. For cross-cutting policy across heterogeneous systems (Kubernetes admission, Terraform plan, microservice authz, CI gating), Rego’s broader ecosystem usually wins.

Pitfalls#

The traps that catch teams new to Cedar. Missing schemas hide type errors; absent attributes silently propagate as errors; set-versus-list semantics surprise; the forbid-wins resolution model differs from “most-specific” intuition. Each is fixable once the rule is internalized.

  • Type errors at runtime, without a schema, expressions silently evaluate to nothing. Always validate against a schema.

  • Entity attribute lookup, attributes that might be missing produce error, which propagates. Use has to check first.

  • Set vs. list, Cedar sets are unordered and de-duplicated; contains works on both but with different semantics.

  • Resolution of overlapping policies, forbid always wins; newcomers expect “most specific” precedence.

When to Pick Cedar#

The kinds of project where Cedar is the right call. AWS- native services using Verified Permissions, greenfield application authz that values simplicity, multi-tenant SaaS where per-tenant policy edits must be safe, and any system that benefits from formal analysis of policy changes.

  • AWS-native applications using Verified Permissions.

  • Greenfield application authz where simplicity matters.

  • Multi-tenant SaaS with per-tenant policies that must be safe to edit.

  • Anywhere formal analysis of policy changes pays back.

See Also#

Contents