Fine-Grained Policies RBAC with OpenFGA

The fine-grained nature of cloud native deployments requires fine-grained authorization at each component. However, this may require security policies to be centrally defined and the configurations reflecting them to be defined in each microservice to enable uniform, consistent enforcement across the entire system which is hard to model and maintain. OpenFGA is an open source solution to Fine-Grained Authorization that applies the concept of Relationship-based access control (ReBAC) where a subject's permission to access a resource is defined by the presence of relationships between those subjects and resources. It was designed for reliability and low latency at a high scale. This talk will offer an overview of OpenFGA, ReBAC and its advantages over more traditional RBAC and ABAC in the context of Zero Trust.

Transcript

1. © Okta and/or its affiliates. All rights reserved. © Okta and/or its affiliates. All rights reserved. Fine Grained Policies RBAC with OpenFGA José Carlos Chávez Security Software Engineer @ Okta Open Source Summit Europe September 16th, 2024 - Vienna @jcchavezs
2. © Okta and/or its affiliates. All rights reserved. © Okta and/or its affiliates. All rights reserved. Fine Grained Policies RBAC are back with OpenFGA José Carlos Chávez Security Software Engineer @ Okta Open Source Summit Europe September 16th, 2024 - Vienna @jcchavezs
3. © Okta and/or its affiliates. All rights reserved. José Carlos Chávez Security Software Engineer - Okta • Open Source enthusiast for 10+ years • OWASP Coraza WAF co-leader, OpenFGA contributor • Loving father of 2 • Mathematician in quarantine @jcchavezs
4. © Okta and/or its affiliates. All rights reserved. Access control [...] determines who is allowed to access certain data, apps, and resources—and in what circumstances. What is access control? - Security 101, Microsoft @jcchavezs
5. © Okta and/or its affiliates. All rights reserved. Various mechanisms State of art • Discretionary access control (DAC): every object has an owner, and owners grant access to users at their discretion. • Mandatory access control (MAC): users are granted access in the form of a clearance. A central authority regulates access rights and organizes them into security levels. • Role-based access control (RBAC): access rights are granted based on defined business functions (role), rather than individuals’ identity. • Attribute-based access control (ABAC): access is granted flexibly based on a combination of attributes and environmental conditions. @jcchavezs
6. © Okta and/or its affiliates. All rights reserved. Protocols & implementations State of art OAuth2.0 @jcchavezs OpenID Connect JWT JWS Scopes JWE sub alg
7. © Okta and/or its affiliates. All rights reserved. @jcchavezs
8. © Okta and/or its affiliates. All rights reserved. OWASP Top 10 2017 vs 2021 Is it solved yet? @jcchavezs
9. © Okta and/or its affiliates. All rights reserved. OWASP Top 10 API 2023 Is it solved yet? @jcchavezs
10. © Okta and/or its affiliates. All rights reserved. Mechanism problem State of art meets reality • Discretionary access control (DAC): every object has an owner, and owners grant access to users at their discretion. Case by case and hence not scalable. • Mandatory access control (MAC): users are granted access in the form of a clearance. A central authority regulates access rights and organizes them into security levels. Works on static and rigid environments. • Role-based access control (RBAC): access rights are granted based on defined business functions (role), rather than individuals’ identity. Easy to understand and author policies rightly but hard to scale (e.g. role explosion). • Attribute-based access control (ABAC): access is granted flexibly based on a combination of attributes and environmental conditions. It is hard to understand and author policies rightly (e.g. permissions overlap) but easy to scale and model. @jcchavezs
11. © Okta and/or its affiliates. All rights reserved. Protocols and implementation challenges Shift left done wrong • Each service does its own authorization. • Coarse-grained roles baked into apps e.g. access to /documents vs /documents/:id. • Authorization “spaghetti code” on each service e.g. is_admin function or if user_id == 1 {...}. • OAuth2 scopes in lieu of permissions. • Missing or inconsistent authorization/audit logs. @jcchavezs
12. © Okta and/or its affiliates. All rights reserved. @jcchavezs
13. © Okta and/or its affiliates. All rights reserved. Mechanism solution ReBAC to the rescue • Provides high flexibility and it is designed to express complex policies. • Defines permissions based on relationships between entities e.g. user, team, blob, cluster, etc. • Dynamic and context-aware, environmental conditions can be expressed in policies e.g. time and location. @jcchavezs Alice Bob Eng HR Company resumes contracts HR docs contract _alice member member parent owner parent parent parent viewer contract _bob parent parent
14. © Okta and/or its affiliates. All rights reserved. OpenFGA: An Authorization System for Everyone @jcchavezs
15. © Okta and/or its affiliates. All rights reserved. Inspired by Google Zanzibar Used in Google Drive, Google Cloud, Youtube, etc. Flexible enough to model any application domain. OpenFGA Relationship Based Access Control (ReBAC) An evolution of Role Based Access Control (RBAC) and Attribute Based Access Control (ABAC). Build to Scale Can scale to millions of globally distributed users and billions of resources. People Friendly Enable user collaboration and fine grained access control in your applications using developer friendly APIs and people friendly readable models. @jcchavezs
16. © Okta and/or its affiliates. All rights reserved. Cloud Native Authorization requirements • Support a consistent model that address fine grained access requirements. • Policies should be a first class citizen and not an application’s detail. • Authorization checks should be a local call embracing real-time access decisions. • Policies and subject/resource/relations data should be centrally managed. • Decision/Audit logs should be aggregated and stored centrally. • Access decisions must be easy to audit and explain. @jcchavezs
17. © Okta and/or its affiliates. All rights reserved. Opinionated solution Shift left done right • Models follow reality, not the other way around. • Decoupling the policies from the application code and use a standard DSL enables central management in a SDLC fashion e.g. gitops like. • The transparency of the SDLC provides audit trails on policy changes. • A central source of truth for policies guarantees consistency and conformance validation across the system. • Enforcement is now possible beyond the application layer (e.g. network layer) which is crucial towards zero trust model. @jcchavezs
18. © Okta and/or its affiliates. All rights reserved. if you can model it you can enforce it Unlimited possibilities • Secure access: ▪ user to API (endpoint, method, host, etc) ▪ user to user ▪ user to resource ▪ service to service, namespace to namespace, namespace to cluster, tier to tier, environment to environment, cluster to cluster, cloud to cloud, etc • Easy integration: SDK, Ingress gateway, sidecar, etc. • Auditability and forensic analysis by inspecting audit logs and access decisions • Observability and controllability by processing logs and taking actions. @jcchavezs
19. © Okta and/or its affiliates. All rights reserved. Conclusions • ReBAC is a natural fit for the class of cloud-native applications whose design is based on microservices due to its flexibility and also because it empowers any stakeholder of the system to understand and contribute to policies. • Being able to understand an access decision in a human readable way is crucial to understand access leaks, unsecure points and forensic research. • Performance is a key in access decisions as making decisions in the critical path could have huge impact in latency. @jcchavezs
20. © Okta and/or its affiliates. All rights reserved. @jcchavezs
21. © Okta and/or its affiliates. All rights reserved. Questions? © Okta and/or its affiliates. All rights reserved. You can also reach me at • josecarlos.chavez@okta.com • https://www.linkedin.com/in/jcchavezs/ • https://twitter.com/jcchavezs @jcchavezs
22. © Okta and/or its affiliates. All rights reserved. Recommended readings Zanzibar: Google’s Consistent, Global Authorization System - Ruoming Pang et al, Google Announcing OpenFGA - Auth0’s Open Source Fine Grained Authorization System - Andrés Aguiar, Okta OPA, Cedar, OpenFGA: Why are Policy Languages Trending Right Now? - Daniel Bass, Permit.io @jcchavezs
23. © Okta and/or its affiliates. All rights reserved. © Okta and/or its affiliates. All rights reserved. Fine Grained Policies RBAC are back with OpenFGA José Carlos Chávez Security Software Engineer @ Okta Open Source Summit Europe September 16th, 2024 - Vienna @jcchavezs
24. © Okta and/or its affiliates. All rights reserved. OpenFGA vs OPA In case someone wonders… OPA • Logic-based language, higher learning curve as it is designed for devs. • Lack of administrative tooling to align policies with business requirements. • Difficulties on keeping track of which policies exist and which rules they contain. @jcchavezs