Verifying Cedar Policy’s correctness with property-based and differential response testing

Presented at Bug Bash 2026: https://antithesis.com/bugbash/conference2026/agenda/
Recording: TBA
Location: 1201 K St NW, Washington, DC 20005

Transcript

1. Verifying Cedar Policy’s correctness with property-based and differential response testing Lucas Käldström Kubernetes Contributor & Cedar Maintainer Staff Software Engineer, @luxas.dev Bug Bash, Washington DC, April 23, 2026
2. $ whoami - Kubernetes contributor, first around SIG Cluster Lifecycle, now SIG Auth - Staff Software Engineer at Upbound, working on access control - Explored making Kubernetes access control more granular, found Cedar ⇒ Kubernetes Enhancement: Conditional Authorization (KEP-5681) ⇒ Prototype for implementing Kubernetes ACLs using Cedar - Newly-accepted Cedar maintainer, lots of new stuff to learn @luxas.dev
3. Paper highlight FSE Companion ’24, July 15–19, 2024, Porto de Galinhas, Brazil arXiv:2407.01688v1 [cs.SE] 1 Jul 2024 @luxas.dev
4. Expressive Curated Lifestyle For Unsplash+
5. Fast Expressive Curated Lifestyle For Unsplash+
6. Fast Safe Expressive Curated Lifestyle For Unsplash+
7. Fast Safe Analyzable Expressive Curated Lifestyle For Unsplash+
8. Fast Safe Analyzable Expressive Correct Curated Lifestyle For Unsplash+
9. Photo by Yung Chang on Unsplash Should everyone (need to) build an access control engine?
10. So with the risk of… …let’s proceed Credit: XKCD
11. Authorization language and engine, for your trusted computing base @luxas.dev part of
12. The Cedar language: Policies - Separate from application code ⇒ declarative rules, independent auditing and analysis @luxas.dev Sample policy from the article
13. The Cedar language: Policies - Separate from application code ⇒ declarative rules, independent auditing and analysis - Permit and Forbid effects - Attribute-, Role-, and Relation-based Access Control @luxas.dev Sample policy from the article
14. The Cedar language: Policies - Separate from application code ⇒ declarative rules, independent auditing and analysis - Permit and Forbid effects - Attribute-, Role-, and Relation-based Access Control - (Optional) Sound type-checking through a Schema @luxas.dev Sample policy from the article
15. The Cedar language: Policies - Separate from application code ⇒ declarative rules, independent auditing and analysis - Permit and Forbid effects - Attribute-, Role-, and Relation-based Access Control - (Optional) Sound type-checking through a Schema - Sound, complete, and decidable SMT encoding @luxas.dev Sample policy from the article
16. The Cedar language: The Authorizer Produces an Allow or Deny decision, given: - a set of policies, - an entity store, - a (principal, action, resource) tuple, and - (optional) context data Uses an interpreter, which evaluates every policy AST expr to true, false, or an error. @luxas.dev
17. The Cedar language: The Authorizer Produces an Allow or Deny decision, given: - a set of policies, - an entity store, - a (principal, action, resource) tuple, and - (optional) context data Uses an interpreter, which evaluates every policy AST expr to true, false, or an error. Formally-proved invariants in Lean include: 1. Explicit allow 2. Forbid trumps permit 3. Order independence 4. Validation soundness 5. Termination @luxas.dev
18. Ok, we’ve got the spec, now implement and ship it? @luxas.dev
19. Verification-Guided Development Combine all three: 1. Formal Verification 2. Differential Response Testing 3. Property-based Testing @luxas.dev
20. Cedar engine implementation verification @luxas.dev Image from the article
21. Engine impl verification: Formal Verification Lean model designed for human readability. Core implementation LoC: 1600 (Lean) vs 11600 (Rust) @luxas.dev Image from the article
22. Formal model in Lean Executable Implementation Code @luxas.dev
23. Formal model in Lean Executable Implementation Code Proof ⇒
24. Engine impl verification: Differential Response testing cargo fuzz Structured: 1. Schema 2. Entities 3. Policies impl Arbitrary Runs nightly for approx. 12h, fresh data each run (DRT is also used to verify other components, not only the authorizer) Image from the article
25. Engine impl verification: Differential Response testing cargo fuzz Structured: 1. Schema 2. Entities 3. Policies impl Arbitrary Minimized test corpus for integration tests in CI Runs nightly for approx. 12h, fresh data each run (DRT is also used to verify other components, not only the authorizer) Image from the article
26. Engine impl verification: Differential Response testing The integration test corpus, with millions of test cases, has led to it being feasible to fully re-implement the authorizer engine also in Go: @luxas.dev
27. Engine impl verification: Property-based testing Main use-cases: - Conversions between policy formats have bounded (or no) lossiness @luxas.dev
28. Engine impl verification: Property-based testing Main use-cases: - Conversions between policy formats have bounded (or no) lossiness - Policy formatting always succeeds, and roundtrips successfully @luxas.dev
29. Engine impl verification: Property-based testing Main use-cases: - Conversions between policy formats have bounded (or no) lossiness - Policy formatting always succeeds, and roundtrips successfully - If got partial and batched authorizer decision ⇒ equals the main authorizer @luxas.dev
30. Engine impl verification: Property-based testing Main use-cases: - Conversions between policy formats have bounded (or no) lossiness - Policy formatting always succeeds, and roundtrips successfully - If got partial and batched authorizer decision ⇒ equals the main authorizer - The parser never panics, nor emits internal errors @luxas.dev
31. Property-based testing example: Policy roundtrips There are many conversion possibilities, and thus lots of room for error. Property-based testing helps ensure the conversions are correct. Cedar policy string CST AST EST JSON string PST @luxas.dev
32. Property-based testing example: Cedar-to-JSON How do we know that the converted JSON-encoded policy string semantically matches the initial policy? ⇒ Compare the ASTs! Cedar policy string CST AST EST JSON string (serde::Serialize) (lalrpop) @luxas.dev
33. Property-based testing example: Cedar-to-JSON Cedar policy string CST AST1 EST JSON string Cedar policy string CST AST2 EST JSON string assert AST1 == AST2 @luxas.dev
34. Conclusion: Verification-Guided Development At least 21 bugs were found using these methods, but also 9 were not detected. @luxas.dev
35. Conclusion: Verification-Guided Development At least 21 bugs were found using these methods, but also 9 were not detected. The project does not release unless DRT+PBT is passing. @luxas.dev
36. Conclusion: Verification-Guided Development At least 21 bugs were found using these methods, but also 9 were not detected. The project does not release unless DRT+PBT is passing. Lean+DRT+PBT needed to graduate a feature from experimental. Code changes might need to be reflected in the Lean model. @luxas.dev
37. Conclusion: Verification-Guided Development At least 21 bugs were found using these methods, but also 9 were not detected. The project does not release unless DRT+PBT is passing. Lean+DRT+PBT needed to graduate a feature from experimental. Code changes might need to be reflected in the Lean model. Overall, the method has yielded high quality and assurance! @luxas.dev
38. Thank you! Special thanks to Katherine Hough and John Kastner who answering questions as I built the presentation, and to the Cedar maintainers that actually built all of this 😁 Try out Cedar at github.com/cedar-policy/cedar Cedar’s specification is available at github.com/cedar-policy/cedar-spec Join the community, use it and contribute if you like 😎 @luxas.dev