of) Kubernetes Access Control Evaluated Tools: - Relation-based Access Control with SpiceDB - Analyzable Access Control with Cedar Policy Contributions: - Kubernetes Access Control improvements implemented with Cedar @luxas.dev
@luxas.dev Declarative, uniform, extensible API server Clients Clients Controlled System 1 Read desired state Controlled System 2 Write actual state Act Act Database
kind: Gateway metadata: name: my-route labels: owner: lucas spec: gatewayClassName: test-gateway addresses: - value: 1.2.3.4 status: conditions: - type: Ready Type Metadata always encoded Uniform Object Metadata for all objects User declares the desired state System updates actual state
deploy-workloads 1:1 *:* Rule 1 Rule 2 OR OR (Rule 1 and Role deploy-workloads omitted for brevity) 1:* apiGroup resource namespace name AND Role Bindings Roles Role Rules Predicates @luxas.dev
deploy-workloads 1:1 *:* Rule 1 Rule 2 OR OR (Rule 1 and Role deploy-workloads omitted for brevity) 1:* apiGroup Obj 1 resource namespace name Obj 2 Obj 3 AND Role Bindings Roles Role Rules Predicates Objects @luxas.dev
deploy-workloads 1:1 *:* Rule 1 Rule 2 OR OR (Rule 1 and Role deploy-workloads omitted for brevity) 1:* apiGroup Obj 1 resource namespace name Obj 2 Obj 3 AND Role Bindings Roles Role Rules Predicates Objects “RBAC” “ABAC” @luxas.dev
become increasingly popular to turn the access control problem into a graph reachability problem (“Relation-Based Access Control”) @luxas.dev Published 2013 and 2019
(ironically) heavy ABAC use, a graph-based mapping wasn’t expressive enough. The lack of expressiveness in the graph resulted in the actual access control logic moving to the (Turing-complete) reconciler from user intent to graph representation. In other words, the result was not very analyzable. ⇒ I pivoted from graph- to logic-based methods @luxas.dev
Controllers* Storage 401 403 40X RequestInfo UserInfo Body Body Webhook OIDC CA Webhook RBAC CEL Webhook 200 * Admission only for CREATE/UPDATE/PATCH/DELETE Slide from my and Jimmy’s talk at KubeCon Salt Lake City
not available in the authorization stage. Thus, we need to “over-grant” in authorization, and remove the extra permissions in the admission stage. create, update, delete gateways — object=* oldobject=* Authorization .class != test-gateway .class == test-gateway Admission Control Amount of permissions for lucas Desired permissions
API in Kubernetes, which allows specifying the deny rule using Common Expression Language (CEL). @luxas.dev create, update, delete gateways — object=* oldobject=* Kubernetes RBAC .class != test-gateway .class == test-gateway CEL Rule Amount of permissions for lucas Desired permissions
authorization RBAC Role Binding Allow in authorization CEL Policy Deny in admission create, update, delete gateways — object=* oldobject=* .class != test-gateway .class == test-gateway Kubernetes RBAC CEL Rule Amount of permissions for lucas Desired permissions
applies to writes, so reads are still unconstrained to all gateway classes. ✅ There is an experimental feature to include label and field selectors 🟡 Selectors won’t become accessible in Kubernetes RBAC, however. create, update, delete gateways — object=* oldobject=* .class != test-gateway .class == test-gateway Kubernetes RBAC CEL Rule Amount of permissions for lucas Desired permissions
Authorization Engine @luxas.dev Aims to be expressive, fast, safe, and analyzable *Means in practice that the language does not have loops or ordered lists
Authorization Engine @luxas.dev Aims to be expressive, fast, safe, and analyzable *Means in practice that the language does not have loops or ordered lists Supports RBAC, ReBAC and ABAC paradigms
Authorization Engine @luxas.dev Aims to be expressive, fast, safe, and analyzable *Means in practice that the language does not have loops or ordered lists AWS is donating Cedar to the CNCF Supports RBAC, ReBAC and ABAC paradigms
authoring usability with typed schema and autocompletion 2. Unify policy authoring for both authorization and admission 3. Unify policy authoring targeting label/field selectors for reads and writes 4. Find an expression language that allow policy querying and comparisons 5. Solve hard authorization problems once, re-use for various user experiences @luxas.dev
RequestInfo UserInfo Admission Control RequestInfo UserInfo Body Body Kubernetes Path for write request Project Partial Evaluation Yes, No, Maybe Full Evaluation Yes, No 403 403 Policies Webhooks Authentication Storage @luxas.dev
The last example, but for any action, including reads. Predicates targeting resource.stored determine if a concrete object is allowed to be read from storage. @luxas.dev
“what resources can principal P perform what actions on?” Ask “what principals can perform what actions on resource R?” Check for logical inconsistencies in a policy set Check for equality Prevent privilege escalation ← No effect ← Allow shadows allow ← Deny shadows allow Allow policy Deny policy
all five goals & two research questions ✅ I already made two contributions to Cedar ✅ Potential interest to contribute some of these features to Kubernetes
all five goals & two research questions ✅ I already made two contributions to Cedar ✅ Potential interest to contribute some of these features to Kubernetes 🟡 More work to be done in Cedar to get production-ready partial evaluation & SMT compilation
all five goals & two research questions ✅ I already made two contributions to Cedar ✅ Potential interest to contribute some of these features to Kubernetes 🟡 More work to be done in Cedar to get production-ready partial evaluation & SMT compilation 🟡 Need to keep getting Kubernetes user feedback
all five goals & two research questions ✅ I already made two contributions to Cedar ✅ Potential interest to contribute some of these features to Kubernetes 🟡 More work to be done in Cedar to get production-ready partial evaluation & SMT compilation 🟡 Need to keep getting Kubernetes user feedback 🟡 Time will tell how useful the analysis properties are in practice
all five goals & two research questions ✅ I already made two contributions to Cedar ✅ Potential interest to contribute some of these features to Kubernetes 🟡 More work to be done in Cedar to get production-ready partial evaluation & SMT compilation 🟡 Need to keep getting Kubernetes user feedback 🟡 Time will tell how useful the analysis properties are in practice ❌ Will always exist cases where analyzable access control isn’t expressive enough