Cedar: A rock-solid access control building block for the cloud native ecosystem

Location: Globe of Science and Innovation, CERN, Espl. des Particules 1, 1217 Meyrin, Schweiz
Schedule link: https://sessionize.com/view/rlq5we3p/GridSmart

Abstract: Building fine-grained access controls into your open source project is a difficult challenge.

We can reduce and amortize this challenge by centralizing the complexity in a general-purpose authorization engine. Before Kubernetes, everyone built stacks from the ground up. With Kubernetes, distributed systems complexity is centralized and shared by the community, saving everyone time and effort.

Cedar Policy, an open source project proposed to be donated to the CNCF, aims to remove the heavy lifting of building access controls. Cedar supports role-, relation-, and attribute-based access controls. It can be embedded into any application or run as a service. It has a flexible, typed schema that enables syntax hints in VS Code. Uniquely, Cedar policies are analyzable, allowing answering questions like “is the refactored policy equal to the previous one?”

This talk introduces Cedar and presents a case study on how it can be used in the context of Kubernetes access controls.

Transcript

1. Cedar: A rock-solid access control building block for the cloud native ecosystem Lucas Käldström Kubernetes Contributor Staff Software Engineer, @luxas.dev
2. Access Control @luxas.dev
3. Can P do A on R? P = some principal (user) A = some action R = some resource with object known Muska Create For Unsplash+ @luxas.dev
4. Can P do A on R? What can P do directly? Muska Create For Unsplash+ @luxas.dev P = some principal (user) A = some action R = some resource with object known
5. Can P do A on R? What can P do directly? What can P do indirectly? Muska Create For Unsplash+ @luxas.dev P = some principal (user) A = some action R = some resource with object known
6. Can P do A on R? What can P do directly? What can P do indirectly? Block bound-to-fail requests fast Muska Create For Unsplash+ @luxas.dev P = some principal (user) A = some action R = some resource with object known
7. Can P do A on R? What can P do directly? Who can access R? What can P do indirectly? Muska Create For Unsplash+ @luxas.dev P = some principal (user) A = some action R = some resource with object known Block bound-to-fail requests fast
8. Can P do A on R? What can P do directly? Who can access R? What can P do indirectly? Are two policies equal? Muska Create For Unsplash+ @luxas.dev P = some principal (user) A = some action R = some resource with object known Block bound-to-fail requests fast
9. Can P do A on R? What can P do directly? Who can access R? What can P do indirectly? Are two policies equal? Are policies inconsistent? Muska Create For Unsplash+ @luxas.dev P = some principal (user) A = some action R = some resource with object known Block bound-to-fail requests fast
10. Expressive Curated Lifestyle For Unsplash+
11. Fast Expressive Curated Lifestyle For Unsplash+
12. Fast Safe Expressive Curated Lifestyle For Unsplash+
13. Fast Safe Analyzable Expressive Curated Lifestyle For Unsplash+
14. Fast Safe Analyzable Expressive Correct Curated Lifestyle For Unsplash+
15. Photo by Yung Chang on Unsplash Should everyone (need to) build an access control engine?
16. Photo by Yung Chang on Unsplash Should everyone (need to) build an access control engine? Hopefully not. Consider how Kubernetes absorbs orchestration complexity.
17. So with the risk of… …let’s proceed Credit: XKCD
18. Open Source Authorization Engine @luxas.dev
19. Open Source Authorization Engine @luxas.dev Supports RBAC, ReBAC and ABAC paradigms
20. Open Source Authorization Engine @luxas.dev Rock-solid: Logic formally verified in Lean Supports RBAC, ReBAC and ABAC paradigms
21. Open Source Authorization Engine @luxas.dev Rock-solid: Logic formally verified in Lean Supports RBAC, ReBAC and ABAC paradigms AWS has donated Cedar to the CNCF \o/
22. 1. Developer Experience is key @luxas.dev Autocompletion
23. 1. Developer Experience is key @luxas.dev Autocompletion Schema validation
24. 2. Analyze: Which policy is larger? @luxas.dev old new Help refactor: Uses mathematical, automated reasoning (SMT)
25. 2. Analyze: Which policy is larger? old new @luxas.dev Allow policy Deny policy ← Deny shadows allow Help refactor: Find logical inconsistencies by comparing policy “size”: Uses mathematical, automated reasoning (SMT)
26. 2. Analyze: Which policy is larger? old new @luxas.dev Allow policy Deny policy ← Allow shadows allow Help refactor: ← Deny shadows allow Find logical inconsistencies by comparing policy “size”: Uses mathematical, automated reasoning (SMT)
27. 2. Analyze: Which policy is larger? old new @luxas.dev Allow policy Deny policy ← No effect Help refactor: Find logical inconsistencies by comparing policy “size”: ← Deny shadows allow ← Allow shadows allow Uses mathematical, automated reasoning (SMT)
28. 3. Ability to deal with incomplete data @luxas.dev “Let user lucas only write secrets with .type=tls”
29. 3. Ability to deal with incomplete data @luxas.dev How can we audit who can write a given TLS Secret “supersecret”? Partially Evaluate the policy with unknown principal
30. 3. Ability to deal with incomplete data @luxas.dev How can we audit who can write a given TLS Secret “supersecret”? Partially Evaluate the policy with unknown principal True Unknown
31. 3. Ability to deal with incomplete data @luxas.dev How can we audit who can write a given TLS Secret “supersecret”? Partially Evaluate the policy with unknown principal True Unknown
32. 3. Ability to deal with incomplete data @luxas.dev How can we audit who can write a given TLS Secret “supersecret”? Partially Evaluate the policy with unknown principal True Unknown
33. 3. Ability to deal with incomplete data @luxas.dev How can we audit who can write a given TLS Secret “supersecret”? Partially Evaluate the policy with unknown principal True Unknown
34. 3. Ability to deal with incomplete data @luxas.dev How can we audit who can write a given TLS Secret “supersecret”? Partially Evaluate the policy with unknown principal True Unknown
35. 3. Ability to deal with incomplete data @luxas.dev How can we audit who can write a given TLS Secret “supersecret”? Partially Evaluate the policy with unknown principal => ‘principal is k8s::User && principal.username == “lucas”’ can write True Unknown
36. Use-case: Kubernetes @luxas.dev
37. @luxas.dev MSc thesis: Usable Access Control in Cloud Management Systems github.com/luxas/research
38. unified Kubernetes authorization using the Cedar Policy Language github.com/upbound/kubernetes-cedar-authorizer @luxas.dev
39. “Let lucas only write TLS secrets” tls lucas *Image adapted from my and Micah’s KubeCon talk @luxas.dev
40. Kubernetes Enhancement Proposal 5681: Conditional Authorization Image credit Howdy! Is the request with <metadata> authorized? Authorizer new It depends. Only if secret.type == “tls” @luxas.dev
41. “Let lucas only read TLS secrets” *Image adapted from my and Micah’s KubeCon talk lucas lucas tls tls @luxas.dev lucas
42. Photo by Yung Chang on Unsplash Beyond Kubernetes: Cedar as a “lingua franca”?
43. Allow multiple “frontends”, but re-use one “backend” Kubernetes “RBAC++” Kubernetes RBAC Other projects’ (e.g. ArgoCD’s) ACLs New Multi-cluster Policies? SMT Solvers @luxas.dev Policies Engine
44. Thanks! Please reach out to me if you are interested in this! @luxas.dev Check out Kubernetes Enhancement Proposal 5681 github.com/upbound/kubernetes-cedar-authorizer