# ADR-008: Cedar Authorization Policy Engine Integration\n\n**Status**: Accepted\n**Date**: 2025-10-08\n**Deciders**: Architecture Team\n**Tags**: security, authorization, cedar, policy-engine\n\n## Context and Problem Statement\n\nThe Provisioning platform requires fine-grained authorization controls to manage access to infrastructure resources across multiple environments\n(development, staging, production). The authorization system must:\n\n1. Support complex authorization rules (MFA, IP restrictions, time windows, approvals)\n2. Be auditable and version-controlled\n3. Allow hot-reload of policies without restart\n4. Integrate with JWT tokens for identity\n5. Scale to thousands of authorization decisions per second\n6. Be maintainable by security team without code changes\n\nTraditional code-based authorization (if/else statements) is difficult to audit, maintain, and scale.\n\n## Decision Drivers\n\n- **Security**: Critical for production infrastructure access\n- **Auditability**: Compliance requirements demand clear authorization policies\n- **Flexibility**: Policies change more frequently than code\n- **Performance**: Low-latency authorization decisions (<10 ms)\n- **Maintainability**: Security team should update policies without developers\n- **Type Safety**: Prevent policy errors before deployment\n\n## Considered Options\n\n### Option 1: Code-Based Authorization (Current State)\n\nImplement authorization logic directly in Rust/Nushell code.\n\n**Pros**:\n\n- Full control and flexibility\n- No external dependencies\n- Simple to understand for small use cases\n\n**Cons**:\n\n- Hard to audit and maintain\n- Requires code deployment for policy changes\n- No type safety for policies\n- Difficult to test all combinations\n- Not declarative\n\n### Option 2: OPA (Open Policy Agent)\n\nUse OPA with Rego policy language.\n\n**Pros**:\n\n- Industry standard\n- Rich ecosystem\n- Rego is powerful\n\n**Cons**:\n\n- Rego is complex to learn\n- Requires separate service deployment\n- Performance overhead (HTTP calls)\n- Policies not type-checked\n\n### Option 3: Cedar Policy Engine (Chosen)\n\nUse AWS Cedar policy language integrated directly into orchestrator.\n\n**Pros**:\n\n- Type-safe policy language\n- Fast (compiled, no network overhead)\n- Schema-based validation\n- Declarative and auditable\n- Hot-reload support\n- Rust library (no external service)\n- Deny-by-default security model\n\n**Cons**:\n\n- Recently introduced (2023)\n- Smaller ecosystem than OPA\n- Learning curve for policy authors\n\n### Option 4: Casbin\n\nUse Casbin authorization library.\n\n**Pros**:\n\n- Multiple policy models (ACL, RBAC, ABAC)\n- Rust bindings available\n\n**Cons**:\n\n- Less declarative than Cedar\n- Weaker type safety\n- More imperative style\n\n## Decision Outcome\n\n**Chosen Option**: Option 3 - Cedar Policy Engine\n\n### Rationale\n\n1. **Type Safety**: Cedar's schema validation prevents policy errors before deployment\n2. **Performance**: Native Rust library, no network overhead, <1 ms authorization decisions\n3. **Auditability**: Declarative policies in version control\n4. **Hot Reload**: Update policies without orchestrator restart\n5. **AWS Standard**: Used in production by AWS for AVP (Amazon Verified Permissions)\n6. **Deny-by-Default**: Secure by design\n\n### Implementation Details\n\n#### Architecture\n\n```\n┌─────────────────────────────────────────────────────────┐\n│ Orchestrator │\n├─────────────────────────────────────────────────────────┤\n│ │\n│ HTTP Request │\n│ ↓ │\n│ ┌──────────────────┐ │\n<><6E>
