Distributed Authorization with Open Policy Agent.pdf
•
0 likes•18 views
A talk given by Anders Eknert, Developer Advocate at Styra, at the 2023 Platform Summit in Stockholm.
Recommended
Recommended
More Related Content
Similar to Distributed Authorization with Open Policy Agent.pdf
Similar to Distributed Authorization with Open Policy Agent.pdf (20)
More from Nordic APIs
More from Nordic APIs (20)
Recently uploaded
Recently uploaded (20)
Distributed Authorization with Open Policy Agent.pdf
- 1. Distributed Authorization with Open Policy Agent Nordic APIs, Stockholm, 2023 Anders Eknert
- 2. Anders Eknert ● Developer advocate at ● Software development ● Background in identity systems ● Four years working with OPA ● Cooking and food ● Football anderseknert anderseknert anderseknert anderseknert@hachyderm.io
- 3. Problem: How do we do authorization in distributed APIs?
- 5. The evolution of identity
- 6. From monolith Authentication Authorization Data Access Business logic Orchestration Data Access Data Access Business logic Business logic User interface
- 7. To microservices Authentication Authorization Data Access Business logic Orchestration Data Access Data Access Business logic Business logic User interface
- 8. To microservices Authentication Authorization Data Access Business logic Orchestration Data Access Data Access Business logic Business logic User interface
- 9. The evolution of identity Application Data Permissions Users credentials ● The application handles everything - including authentication and access control. The user authenticates in the application, a session is established, access control performed in code, commonly with a database serving permission data. ● In the distributed application, authentication is delegated elsewhere. ● But up until now, access control has remained pretty much the same, in code, with a database serving permission data per request. Monolith architecture
- 10. The evolution of identity Service Users Permissions Service Service Service Service Data Service Data Data credentials credentials credentials credentials credentials credentials Naive monolith architecture using microservices
- 11. The evolution of identity Service Users Permissions Service Service Service Service Data Service Data Data credentials credentials credentials credentials credentials credentials Naive monolith architecture using microservices
- 12. The evolution of identity Service Users Permissions Service Service Service Service Data Service Data Data Identity system token token token token token token token credentials Slightly less naive monolith architecture using microservices Rather than passing around credentials, we exchange them for tokens
- 13. The evolution of identity Service Users Permissions Service Service Service Service Data Service Data Data Identity system token token token token token token token Slightly less naive monolith architecture using microservices Everyone wants a token!
- 14. The evolution of identity Service Users Permissions Service Service Service Service Data Service Data Data Identity system token token token token token token token Slightly less naive monolith architecture using microservices So.. how are these tokens obtained?
- 15. The evolution of identity Service Users Permissions Service Service Service Service Data Service Data Data Identity system token token token token token token token Slightly less naive monolith architecture using microservices
- 16. The evolution of identity Service Users Permissions Service Service Service Service Data Service Data Data Identity system token token token token token token token OAuth2 Defines a set of flows for users (interactive flows) and clients (non-interactive) to authenticate at the authorization server in order to obtain access tokens for use as credentials to services. Does not detail what an access token should look like. Despite labeled an “authorization framework” provides little in terms of authorization - rather about delegation. Scopes provide basic boundaries for where an access token may be used. Commonly used for external identity providers, “social login”, etc.
- 17. The evolution of identity Service Users Permissions Service Service Service Service Data Service Data Data Identity system token token token token token token token
- 18. The evolution of identity Service Users Permissions Service Service Service Service Data Service Data Data Identity system token token token token token token token
- 19. The evolution of identity Service Users Permissions Service Service Service Service Data Service Data Data Identity system token token token token token token token
- 20. The evolution of identity Service Users Permissions Service Service Service Service Data Service Data Data Identity system token token token token token token token
- 21. The evolution of identity Service Users Permissions Service Service Service Service Data Service Data Data Identity system token token token token token token token
- 22. The evolution of identity Service Users Permissions Service Service Service Service Data Service Data Data Identity system token token token token token token token JSON Web Tokens (JWTs) A JWT is a signed self-contained collection of claims, i.e. attributes claimed to be true. Tokens are created by an issuer. Claims often (but not always) provided by the backing identity provider. Expiry time (and other standard attributes) of JWT included in payload. JWTs are immutable - no claim may be changed without breaking signature verification. JWTs are everywhere - libraries for both encoding and decoding available for all languages and platforms.
- 23. Distributed identity, solved ☑ Service Users Permissions Service Service Service Service Data Service Data Data Identity system Token/JWT JWT JWT JWT Token/JWT JWT JWT JSON Web Tokens
- 24. Great, now do authorization
- 25. The evolution of access control
- 26. Distributed Authorization? Service Users Permissions Service Service Service Service Data Service Data Data Identity system Token/JWT JWT JWT JWT Token/JWT JWT JWT JSON Web Tokens Naive model — authorization logic embedded in application code, querying database for permissions
- 27. So, where should we do authorization?
- 28. Gateway Model Gateway Users Permissions Service Service Service Service Data Service Data Data Identity system Token/JWT JWT JWT JWT Token/JWT JWT JWT JSON Web Tokens Authorization performed at perimeter of environment ● Fast! ● Single point of failure ● Insecure ● External dependency
- 29. Zero Trust Model Service Users Permissions Service Service Service Service Data Service Data Data Identity system Token/JWT JWT JWT JWT Token/JWT JWT JWT JSON Web Tokens Authorization — just like identity — must be verified in each service. Make no assumptions. ● Slow ● Single point of failure ● Secure ● External dependency ● Authorization embedded in business logic
- 30. Great, we’re back where we started
- 31. Zero Trust Model Service Users Permissions Service Service Service Service Data Service Data Data Identity system Token/JWT JWT JWT JWT Token/JWT JWT JWT JSON Web Tokens How do we make it better? ● Slow ● Single point of failure ● Secure ● External dependency ● Authorization embedded in business logic
- 32. Zero Trust Model Service Users Permissions Service Service Service Service Data Service Data Data Identity system Token/JWT JWT JWT JWT Token/JWT JWT JWT JSON Web Tokens Remove online dependency for permissions data, store copy in applications ● Slow ● Single point of failure ● Secure ● External dependency ● Authorization embedded in business logic
- 33. Zero Trust Model Service Users Permissions Service Service Service Service Data Service Data Data Identity system Token/JWT JWT JWT JWT Token/JWT JWT JWT JSON Web Tokens Authorization still hardcoded in applications — changes are cumbersome, coordination between teams required, very hard to audit ● Slow ● Single point of failure ● Secure ● External dependency ● Authorization embedded in business logic
- 34. Zero Trust Model Service Users Permissions Service Service Service Service Data Service Data Data Identity system Token/JWT JWT JWT JWT Token/JWT JWT JWT JSON Web Tokens
- 35. ● Open source general purpose policy engine ● Unified toolset and framework for policy across the stack ● Decouples policy from application logic ● Separates policy decision from enforcement ● Policies written in declarative language Rego ● Popular use cases ranging from kubernetes admission control, microservice authorization, infrastructure, data source filtering, to CI/CD pipeline policies and many more.
- 37. Policy decision model Service OPA Policy (Rego) Data (JSON) Request Policy Decision Policy Query Input can be ANY JSON value Output can be ANY JSON value Request Policy Decision Linux PAM
- 38. Deployment model ● OPA runs as a lightweight self-contained server binary ● OPA ideally deployed as close to service as possible. This usually means running on the same host, either as a daemon or in a sidecar deployment ● Applications communicate with the OPA server through its REST API ● Go library available for Go applications ● Envoy/Istio based applications. Wasm, Intermediate Representation (IR), more...
- 39. Policy authoring and Rego ● Rego — declarative high-level policy language used by OPA. ● Policy consists of any number of rules. ● Rules commonly return true/false but may return any type available in JSON, like strings, lists and objects. ● Policy testing is easy with provided unit test framework. ● Well documented! https://www.openpolicyagent.org/docs/latest/ ● Try it out! https://play.openpolicyagent.org/
- 40. Zero Trust Model Service Users Permissions Service Service Service Service Data Service Data Data Identity system Token/JWT JWT JWT JWT Token/JWT JWT JWT JSON Web Tokens Decisions delegated to OPA — unified authorization across the stack, with policy decoupled from application logic ● Slow ● Single point of failure ● Secure ● External dependency ● Authorization embedded in business logic
- 41. Distributed authorization, solved ☑ Service Users Service Service Service Service Data Service Data Data Identity system Token/JWT JWT JWT JWT Token/JWT JWT JWT JSON Web Tokens Permissions Control Plane Policies
- 42. Distributed authorization, solved ☑ Service Users Service Service Service Service Data Service Data Data Identity system Token/JWT JWT JWT JWT Token/JWT JWT JWT JSON Web Tokens Permissions Policies
- 44. Getting started ● Start small – write a few simple policies and tests. ● Browse the OPA documentation. Get a feel for the basics and the built-ins. ● Consider possible applications near to you - previous apps and libraries you’ve worked with. Consider the informal policies it dealt with. ● Delegate policy responsibilities to OPA. Again, start small! Perhaps a single endpoint to begin somewhere. Deploy and build experience. ● Styra Academy ● Join the OPA Slack community!
- 45. Questions?
- 46. Thank you!