When authorization rules are scattered across application code, configuration, and database queries, access becomes difficult to audit and change. A policy repository provides a managed, human-facing source location where authorization policies, schemas, tests, reviews, and revisions are maintained before deployment to a policy store. section 10.2 section 10.5
A repository supports a controlled path from policy change to runtime enforcement:
- Edit Cedar policies, schemas, and tests in the repository. section 10.2
- Review changes through pull requests, preserving ownership, rationale, and version history. section 10.2 section 10.5
- Validate syntax and schemas, run static analysis and tests, then build a signed policy bundle. section 10.2.4
- Promote the approved bundle to the corresponding policy store, where the authorizer retrieves it for runtime decisions. section 10.2 section 10.2.4
- Observe decisions and retain rollback capability when a deployment needs correction. section 10.2 section 10.5
ACME’s repository-to-store mapping
ACME maintains a collab-policy repository for Customer Collaboration and a deploy-policy repository for production deployments, each paired with a policy store. A global-guardrails repository feeds a centrally managed Guardrails store. Repositories hold authoring and history; stores serve runtime enforcement. section 10.2
Figure 10.6 Continuous integration for policies. Bob’s pull request triggers validation, analysis, and testing. After the checks pass, his changes are merged, bundled into a signed package, and published to a policy store, where the authorizer uses them to evaluate requests at runtime.
The workflow diagram shows a pull request passing validation, analysis, and testing before producing a signed bundle for the policy store and runtime authorizer. section 10.2.4
