OPA vs Cedar (Cedar Agent and OPAL)
Charlie Egan
Rego and Cedar are both open source languages for policy as code. In order to use each of these languages for a policy as code use case, such as externalized authorization, a wider context of tooling is required. Policy code needs to be authored, distributed, and enforced to be effective, so an effective comparison of the two languages takes this wider context into consideration as well.
OPA is a general-purpose policy engine. It supports a range of policy as code use cases, including authorization, with the Rego language. OPA is an open source project created and maintained by Styra and is hosted by the Cloud Native Computing Foundation.
Enterprise OPA Platform builds on the capabilities of OPA, offering a comprehensive authorization platform. The platform provides compliance, governance, no-code policy, and lifecycle management capabilities to scale policy as code authorization in complex, enterprise domains.
Cedar is an open source policy language for authorization policy. While it can describe authorization policies, being only a language, it is not a standalone solution. For policy to be enforced, Cedar code needs to be evaluated within a policy engine or product.
Cedar Agent is an early stage, open source policy engine for Cedar. The agent is concerned with the evaluation and reloading of Cedar policies in response to API requests.
Open Policy Administration Layer (OPAL) is a self-hosted control plane that can manage the Cedar agent, a minimal Cedar-based policy engine. OPAL facilitates the management of Cedar policies, offering a way to distribute policies.
Key Differences:
- Deployment: OPA and the Enterprise OPA Platform can be deployed anywhere and offer all that’s needed to run a policy as code platform. Cedar, being just a language, also needs a Cedar agent managed by OPAL to be able to provide a complete solution so it involves deploying more components.
- Use Cases: OPA is a general-purpose policy engine suitable for various use cases beyond authorization. Cedar is a policy language focused solely on authorization while OPAL makes it possible to use the language outside of its usual home, as part of the APIs in AWS.
See also OPA vs Cedar with Amazon Verified Permissions
| Enterprise OPA Platform | Open Source OPA | Cedar with cedar-agent and OPAL | |
|---|---|---|---|
Use Cases |
|||
| Application Authorization | |||
| Run as a sidecar | ✅ | ✅ | ✅ |
| Run as a centralized service | ✅ | ✅ | ✅ |
| Run as a daemon on the same host | ✅ | ✅ | ✅ |
| Custom Integration via REST | ✅ | ✅ | ✅ |
| Custom Embedded Integration | ✅ | ✅ | 🟡 Rust Only |
| Istio / Envoy Proxy | ✅ | ✅ | ❌ |
| Kong Gateway & Mesh | ✅ | ✅ | ❌ |
| Gloo Gateway | ✅ | ✅ | ❌ |
| Emissary | ✅ | ✅ | ❌ |
| AWS API Gateway | ✅ | ✅ | ❌ |
| Arbitrary JSON in/out | ✅ | ✅ | 🟡 Input Only (Fixed response format) |
| Other Authorization | |||
| Kubernetes Admission | ✅ | 🟡 Via OPA Gatekeeper or kube-mgmt | ❌ |
| Terraform | ✅ | 🟡 Via conftest | ❌ |
| Kafka Topics | ✅ | ✅ | ❌ |
| Cloud Formation | ✅ | ✅ | ❌ |
| Docker | ✅ | ✅ | ❌ |
| SSH | ✅ | ✅ | ❌ |
| Arbitrary JSON in/out | ✅ | ✅ | 🟡 Input Only (Fixed response format) |
| Data Sources | |||
| SQL | ✅ | ❌ | ✅ |
| HTTP | ✅ | ✅ | ✅ |
| MongoDB | ✅ Native Client Support | ❌ | 🟡 Via MongoDB REST API Only |
| Neo4j | ✅ | ❌ | 🟡 Via Neo4j REST API Only |
| Kafka | ✅ | ❌ | ❌ |
| S3 | ✅ | ❌ | ❌ |
| Git | ✅ | ❌ | ❌ |
| CosmosDB | ❌ | ❌ | ✅ |
| Identity Data Sources | |||
| Okta | ✅ | ❌ | ❌ |
| LDAP | ✅ | ❌ | ✅ |
| Language SDK Availability | |||
| Java | ✅ | Community REST Client | 🟡 Via Custom REST Integration |
| C# | ✅ | Community REST Client | 🟡 Via Custom REST Integration |
| Typescript | ✅ | Community REST Client | 🟡 Via Custom REST Integration |
| Python | Community REST Client | Community REST Client | 🟡 Via Custom REST Integration |
| Go | ✅ | ✅ | 🟡 Via Custom REST Integration |
| Node.js | ✅ | Community REST Client | 🟡 Via Custom REST Integration |
| PHP | Community REST Client | Community REST Client | 🟡 Via Custom REST Integration |
| Rust | 🟡 Via Custom REST Integration | 🟡 Via Custom REST Integration | ✅ |
| Web Assembly | 🟡 Agent Support Only | ✅ | 🟡 Via Custom REST Integration |
Policy Lifecycle |
|||
| ‘Policy as Code’ | |||
| Versioned Policy Distribution | ✅ | ✅ | ✅ |
| Git / GitOps Updates | ✅ | ❌ | ✅ |
| Policy Testing | |||
| Policy Testing (CLI) | ✅ | ✅ | ❌ |
| Policy Testing (UI) | ✅ | ❌ | ❌ |
| Historic Impact Analysis | ✅ | ❌ | ❌ |
| Live Impact Analysis | ✅ | ❌ | ❌ |
| Policy Authoring | |||
| Editor Extensions | ✅ | ✅ | ✅ |
| CLI REPL | ✅ | ✅ | ❌ |
| Web IDE | ✅ | ❌ | ❌ |
| Learning Resources | |||
| Online Playground | ✅ | ✅ | ✅ |
| Linter | ✅ | ✅ | ❌ |
| Free Online Courses | ✅ | ✅ | ❌ Not Available |
Audit Functionality |
|||
| Logging of Policy Version | ✅ | ✅ | ❌ |
| Structured Logging | ✅ | ✅ | ❌ |
| Log Sinks | |||
| Console (stdout) Log Sink | ✅ | ✅ | ✅ |
| HTTP Log Sink | ✅ | ✅ | ❌ |
| Splunk Log Sink | ✅ | ❌ | ❌ |
| Kafka Log Sink | ✅ | ❌ | ❌ |
| S3 Log Sink | ✅ | ❌ | ❌ |
Language Functionality |
|||
| General Functionality | |||
| Logic Operations | ✅ | ✅ | ✅ |
| Built-in Type Comparisons | ✅ | ✅ | ✅ |
| Arithmetic Operations | ✅ | ✅ | 🟡 +, -, * only |
| Regex | ✅ | ✅ | ❌ |
| String Operations | ✅ | ✅ | 🟡 LIKE with Wildcard Only |
| HTTP Request Support | ✅ | ✅ | ❌ |
| base64 Enc/Dec | ✅ | ✅ | ❌ |
| Authz-specific Functionality | |||
| CIDR Range Testing | ✅ | ✅ | 🟡 In Range Testing only |
| IP Address Validation | 🟡 User Defined | 🟡 User Defined | ✅ |
| JWT Parsing and Verification | ✅ | ✅ | ❌ |
| X509 Certificate & Key Pair Parsing and Verification | ✅ | ✅ | ❌ |
| UUID Functionality | ✅ Parsing and Generation | ✅ Parsing and Generation | ❌ |
