Usable Access Control in Cloud Management Systems

Slide 1

Slide 1 text

Usable Access Control in Cloud Management Systems Lucas Käldström, Upbound @luxas.dev

Slide 2

Slide 2 text

MSc student Staff Software Engineer Contributor @luxas.dev

Slide 3

Slide 3 text

Outline Project Context: - Find gaps in and improve (usability 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

Slide 4

Slide 4 text

Production-grade Container Orchestrator Released as open source by Google in 2014, donated to Kubernetes @luxas.dev Published 2013 and 2015

Slide 5

Slide 5 text

Kubernetes Control Plane framework and control plane for workload orchestration @luxas.dev Generic Control Plane Framework Container Orchestration Project Targets Any software system Container Workloads, SDN, etc.

Slide 6

Slide 6 text

Kubernetes Control Plane framework and control plane for workload orchestration @luxas.dev Generic Control Plane Framework Project Targets Any software system

Slide 7

Slide 7 text

Kubernetes Control Plane framework and control plane for workload orchestration @luxas.dev Declarative, uniform, extensible API server Clients Clients Controlled System 1 Read desired state Controlled System 2 Write actual state Act Act Database

Slide 8

Slide 8 text

@luxas.dev Available at https://github.com/luxas/research Published in 2021 More context in my BSc thesis

Slide 9

Slide 9 text

Anatomy of an uniform and extensible API server apiVersion: gateway.networking.k8s.io/v1 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

Slide 10

Slide 10 text

Anatomy of an uniform and extensible API server apiVersion: gateway.networking.k8s.io/v1 kind: Gateway* metadata: name: my-route labels: … Type Metadata always encoded Uniform Object Metadata for all objects list, watch, create, deletecollection: /apis///** get, update, patch, delete: /apis////** *resource != kind, but almost, simpliﬁed here **Plus namespace scoping if namespaced @luxas.dev

Slide 11

Slide 11 text

Kubernetes RBAC Subjects RoleBinding admin RoleBinding deploy-workloads *:* OR Role Bindings @luxas.dev

Slide 12

Slide 12 text

Kubernetes RBAC Subjects RoleBinding admin RoleBinding deploy-workloads Role admin Role deploy-workloads 1:1 *:* OR Role Bindings Roles @luxas.dev

Slide 13

Slide 13 text

Kubernetes RBAC Subjects RoleBinding admin RoleBinding deploy-workloads Role admin Role deploy-workloads 1:1 *:* Rule 1 Rule 2 OR OR (Rule 1 and Role deploy-workloads omitted for brevity) 1:* Role Bindings Roles Role Rules @luxas.dev

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Kubernetes RBAC mapping into ReBAC In recent years, it has become increasingly popular to turn the access control problem into a graph reachability problem (“Relation-Based Access Control”) @luxas.dev Published 2013 and 2019

Slide 18

Slide 18 text

@luxas @luxas API Server Slide from my talk at Disobey 18 User Authenticator ReBAC Server Flow Control Authorizer Admission Privilege Escalation Prevention Authorization State Update List Filter ReBAC Database Storage Audit Log Policy Engine Check ListResources WriteRelations

Slide 19

Slide 19 text

Kubernetes RBAC mapping into ReBAC However, due to Kubernetes RBAC’s (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

Slide 20

Slide 20 text

Usability issues with Kubernetes RBAC

Slide 21

Slide 21 text

Kubernetes Access Control Request Flow @luxas.dev

Slide 22

Slide 22 text

Kubernetes Access Control Request Flow

Slide 23

Slide 23 text

Kubernetes API Server structure Authenticators RequestInfo UserInfo 401 Webhook OIDC CA Slide from my and Jimmy’s talk at KubeCon Salt Lake City

Slide 24

Slide 24 text

Kubernetes API Server structure Authenticators Authorizers RequestInfo UserInfo 401 403 RequestInfo UserInfo Body Webhook OIDC CA Webhook RBAC Slide from my and Jimmy’s talk at KubeCon Salt Lake City

Slide 25

Slide 25 text

Kubernetes API Server structure Authenticators Authorizers RequestInfo UserInfo Mutating/Validating Admission 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

Slide 26

Slide 26 text

Authorization and Admission Control are separate The request payload is 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

Slide 27

Slide 27 text

Authorization and Admission Control are separate There is a ValidationAdmissionPolicy 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

Slide 28

Slide 28 text

Authorization and Admission Control are separate RBAC Role Allow in 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

Slide 29

Slide 29 text

Admission Control is not available for reads ❌ Admission only applies to writes, so reads are still unconstrained to all gateway classes. ✅ There is an experimental feature to include label and ﬁeld 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

Slide 30

Slide 30 text

Research Question 1: How to unify Kubernetes authorization and admission? @luxas.dev

Slide 31

Slide 31 text

Desired properties of an Authorization Engine @luxas.dev

Slide 32

Slide 32 text

Expressive

Slide 33

Slide 33 text

Fast Expressive

Slide 34

Slide 34 text

Fast Safe Expressive

Slide 35

Slide 35 text

Fast Safe Analyzable Expressive

Slide 36

Slide 36 text

Fast Safe Analyzable Expressive Correct

Slide 37

Slide 37 text

Published 2024 @luxas.dev

Slide 38

Slide 38 text

Open Source Authorization Engine @luxas.dev

Slide 39

Slide 39 text

Open Source Authorization Engine @luxas.dev Aims to be expressive, fast, safe, and analyzable

Slide 40

Slide 40 text

Maintains a decidable encoding into Satisﬁability Modulo Theories* Open Source 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

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

1. Developer Experience is key @luxas.dev

Slide 44

Slide 44 text

2. Analyze: Which policy is larger? old @luxas.dev

Slide 45

Slide 45 text

2. Analyze: Which policy is larger? old new @luxas.dev

Slide 46

Slide 46 text

3. Formal Veriﬁcation Image Source: https://aws.amazon.com/blogs/opensource/lean-into-veriﬁed-software-development/ @luxas.dev

Slide 47

Slide 47 text

Research Question 2: Can Kubernetes access control be mapped into SMT? @luxas.dev

Slide 48

Slide 48 text

MSc thesis project: Integrate Kubernetes and Cedar 1. Improve policy authoring usability with typed schema and autocompletion 2. Unify policy authoring for both authorization and admission 3. Unify policy authoring targeting label/ﬁeld 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

Slide 49

Slide 49 text

1. Improve policy authoring usability with typed schema @luxas.dev

Slide 50

Slide 50 text

Kubernetes API Server /openapi/v3/ API Discovery Document /apis// 1. Improve policy authoring usability with typed schema Project Schema IDE Dev loop @luxas.dev

Slide 51

Slide 51 text

2. Unify policy authoring for both authorization and admission Previous example shown in the project’s proposed syntax. Only one policy object is needed, not three like before. @luxas.dev

Slide 52

Slide 52 text

2. Unify policy authoring for both authorization and admission Authorization RequestInfo UserInfo Kubernetes Path for write request Project Partial Evaluation Yes, No, Maybe 403 Policies Webhook Authentication @luxas.dev

Slide 53

Slide 53 text

2. Unify policy authoring for both authorization and admission Authorization 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

Slide 54

Slide 54 text

3. Unify policy authoring targeting selectors for reads and writes 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

Slide 55

Slide 55 text

3. Unify policy authoring targeting selectors for reads and writes Authorization Kubernetes Path for read request Project Full Evaluation Yes, No 403 Authentication Storage Example selectors: “Label owner value in (‘alice’, ‘bob’)” “Field .spec.gatewayClassName != ‘production’” @luxas.dev Policies RequestInfo UserInfo Selectors

Slide 56

Slide 56 text

3. Unify policy authoring targeting selectors for reads and writes Authorization RequestInfo UserInfo Selectors Kubernetes Path for read request Project 1. Partial Evaluation => Yes, No, Maybe 2. If Maybe, turn Selectors and Residual into SMT => Yield Yes or No 403 Policies Authentication Storage Authorize IFF: ∀o : objectSelected(o) ⇒ isAuthorized(o) ≡ ∃o : objectSelected(o) ∧ ¬isAuthorized(o) = UNSAT @luxas.dev

Slide 57

Slide 57 text

4. Find an expression language that allow policy analysis Ask “what resources can principal P perform what actions on?” Ask “what principals can perform what actions on resource R?”

Slide 58

Slide 58 text

4. Find an expression language that allow policy analysis Ask “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

Slide 59

Slide 59 text

4. Find an expression language that allow policy analysis Queries achievable through Partial Evaluation @luxas.dev

Slide 60

Slide 60 text

4. Find an expression language that allow policy analysis Queries achievable through Partial Evaluation If the policies are compiled into equivalent SMT formulas, then: Equality if: policy1 ⊨ policy2 ∧ policy2 ⊨ policy1 Policy 2 > Policy 1 if: policy1 ⊨ policy2 ∧ ¬(policy2 ⊨ policy1) Policy change not an escalation if: current_privileges ⊨ new_privileges @luxas.dev

Slide 61

Slide 61 text

5. Write backend once, use for multiple “frontends” Kubernetes CEL (portion w/o loops) Kubernetes RBAC New Selector-based Authorization paradigm? New Multi-cluster Policies? Project SMT Solvers @luxas.dev Policies Engine

Slide 62

Slide 62 text

Results ✅ There seems to be a path forward for all ﬁve goals & two research questions

Slide 63

Slide 63 text

Results ✅ There seems to be a path forward for all ﬁve goals & two research questions ✅ I already made two contributions to Cedar

Slide 64

Slide 64 text

Slide 65

Slide 65 text

Slide 66

Slide 66 text

Slide 67

Slide 67 text

Results ✅ There seems to be a path forward for all ﬁve 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

Slide 68

Slide 68 text

Slide 69

Slide 69 text

Thanks! Please give feedback! Email: [email protected] Bluesky: @luxas.dev LinkedIn: luxas CNCF/Kubernetes Slack: luxas Credits: Icons by Flaticon