Opa in the api management world
1 like•166 views
This document provides an overview of authorization models and how Open Policy Agent (OPA) can be used for authorization in microservices. It defines common authorization models like ACL, DAC, MAC, RBAC, and ABAC and provides examples of how they work. It then discusses how OPA uses a declarative policy language called Rego to specify authorization policies and can offload policy decision making through REST APIs. The document demonstrates integrating OPA by evaluating policies and managing policies. It shows a demo of OPA enforcing a simple salary access policy.
![Policies evaluation
OPA supports different ways to evaluate policies:
● REST API returns decisions as JSON over HTTP.
● The Go API (GoDoc) returns decisions as simple Go types (bool, string,
map[string]interface{}, etc.)
● WebAssembly compiles Rego policies into WASM instructions so they can be
embedded and evaluated by any WebAssembly runtime
● The SDK provides high-level APIs for obtaining the output of query evaluation as
simple Go types (bool, string, map[string]interface{}, etc.)
36](https://image.slidesharecdn.com/opaintheapimanagementworld-211124172033/85/Opa-in-the-api-management-world-30-320.jpg)
Opa in the api management world
- 1. Public Version 0.9 beta OPA in the API management world -- Luca Ferrari
- 2. VP of myself Luca Ferrari Started from REST expanding to the rest (of the modern technologies) 2
- 5. AuthN and AuthZ AuthN: “please show me your ID or Passport” AuthZ: “please scan your boarding pass on the bar code reader” 5
- 7. Models There are several models out there, we will be summarizing the following ones: ACL DAC MAC RBAC ABAC AuthZ has been there since the beginning of computer systems, for example the first implementation of ACLs was in the filesystem of Multics in 1965 7
- 8. ACL An Access-Control List is a list of permissions associated with a system resource. An ACL specifies which users or system are granted access to objects, as well as what operations are allowed on given objects. Each entry in a typical ACL specifies a subject and an operation. It specifies individual users or groups. In real world: Filesystems 8
- 9. ACL in practice Subject Object Action Alice Report Create Bob Report Read 9
- 10. DAC Discretionary Access Control is a way to restrict access to objects based on the identity of subjects and/or groups to which they belong. The controls are discretionary in the sense that a subject is capable of passing that permission (perhaps indirectly) on to any other subject (unless restrained by mandatory access control). Two implementations: ● Through ownership ● Through capabilities 10
- 11. DAC in practice Subject Object Action Alice Report Create Alice Subjects Grant grant Subject Object Action Bob Report Create 11
- 12. MAC Mandatory access control is a way to control where the operating system or database constrains the ability of a subject to access or perform an action on an object or target. Whenever a subject attempts to access an object, an authorization rule enforced by the OS examines these security attributes and decides if the access can take place. Any operation by any subject on any object is tested against the set of authorization rules (aka policy) to determine if the operation is allowed. With mandatory access control, this security policy is centrally controlled by a security policy administrator; users do not have the ability to override the policy in contrast to discretionary access control (DAC). In real world: SELINUX 12
- 13. MAC in practice Subject Object Action Alice Report Create Subject Object Action Report Alice Be created grant 13
- 14. RBAC Role-Based Access Control is a way to restrict system access to authorized users with policies defined around roles and privileges. The components of RBAC such as role-permissions, user-role and role-role relationships make it simple to perform user assignments across a wide organization with 1000s of users. There are 3 elements to RBAC: 1. Role assignment 2. Role authorization: A subject's active role must be authorized for the subject. 3. Permission authorization: A subject can exercise a permission only if the permission is authorized for the subject's active role. In the real world: IDP 14
- 15. RBAC in practice Subject Role Alice Creator Name Action Object Create report Create Report Update Report Read Report Manage report Approve Report Read Report grant Name Permission Creator Create report Permissions Role
- 16. ABAC Attribute-Based Access Control is defined as a system where access rights are granted to users through the use of policies which combine attributes together. The policies can use any type of attributes (user attributes, resource attributes, object, environment attributes etc.). This model supports Boolean logic, in which rules contain "IF, THEN" statements about who is making the request, the resource, and the action. Attribute-based access control is also known as Policy-Based Access Control (PBAC) or Claims-Based Access Control (CBAC) or IAM in AWS 16
- 17. ABAC The Policy Enforcement Point inspects the request and generates an authorization request from it which it sends to the PDP. The Policy Decision Point evaluates incoming requests against policies it has been configured with. The PDP returns a Permit / Deny decision. The PDP may also use PIPs to retrieve missing metadata The Policy Information Point bridges the PDP to external sources of attributes e.g. LDAP or databases. 17
- 18. ABAC in practice 18 Policies Subject: Name: Alice Department: Marketing Action: Type: Update Object: Type: Report Mode: Draft Department: Marketing Context: Location: London Time: between 9am and 6pm GMT
- 19. XACML 24
- 20. XACML The "eXtensible Access Control Markup Language" defines a declarative fine-grained, attribute-based access control policy language, an architecture, and a processing model describing how to evaluate access requests according to the rules defined in policies. This was thought to promote interoperability between different implementations by multiple vendors. XACML can be considered: ● ABAC ● PBAC ● RBAC 25
- 21. XACML 26
- 23. New challenges ● Authentication and authorization needs to be handled in each microservice ● Microservices should follow the principle of single responsibility. A microservice only handles its own business logic. ● Authentication and authorization in the microservices architecture involves scenarios that are more complex, involving users accessing microservice applications, third-party applications accessing microservice applications, and multiple microservice applications accessing each other. 28
- 24. OPA 30
- 25. In brief Open Policy Agent main characteristics: ● open source ● general-purpose policy engine ● high-level declarative language (Rego) that lets you specify policy as code ● REST APIs to offload policy decision-making ● decoupling policy decision-making from policy enforcement ● Being able to receive and reply with arbitrary structured data (e.g., JSON) 31
- 26. In brief 32
- 27. Rego Rego queries are assertions on data stored in OPA. These queries can be used to define policies that enumerate instances of data that violate the expected state of the system. Using Rego for defining policy is easy to read and write. Rego is declarative so policy authors can focus on what queries should return rather than how queries should be executed. These queries are simpler and more concise than the equivalent in an imperative language. https://play.openpolicyagent.org/ 33
- 28. XACML Open Policy Agent is similar to XACML in that it provides a policy decision point, externalized authorization, and a policy language (REGO). It specializes in infrastructure authorization (e.g. for Kubernetes, Istio...) rather than general-purpose, API-centric, or data-centric which XACML addresses. 34
- 29. Integrating OPA 2 main interfaces: 1. Evaluation: OPA’s interface for querying for policy decisions. 2. Management: OPA’s interface for deploying policies, understanding status, uploading logs, and so on. Distributing policy, retrieving status, and storing logs in the same way across all OPAs provides a unified management plane for policy across many different software systems. 35
- 30. Policies evaluation OPA supports different ways to evaluate policies: ● REST API returns decisions as JSON over HTTP. ● The Go API (GoDoc) returns decisions as simple Go types (bool, string, map[string]interface{}, etc.) ● WebAssembly compiles Rego policies into WASM instructions so they can be embedded and evaluated by any WebAssembly runtime ● The SDK provides high-level APIs for obtaining the output of query evaluation as simple Go types (bool, string, map[string]interface{}, etc.) 36
- 31. OPA and / or API Management 37
- 32. Brothers in arms OPA is the perfect companion of an API Management especially in the new microservice / lightweight oriented new world. While XACML was standardized and has been adopted by some vendors, it was considered heavyweight and more difficult to define in terms of policies (XML horror, reminds you of anything you REST aficionados?) On the base of this vision and of a more modular approach to API Management, several projects have been initiated, including https://github.com/kuadrant/authorino 38
- 33. Demo 39
- 34. Setup A simple HTTP web server that accepts any HTTP GET request that you issue and echoes the OPA decision back as text. Our policy is: ● People can see their own salaries (GET /finance/salary/{user} is permitted for {user}) ● A manager can see their direct reports' salaries (GET /finance/salary/{user} is permitted for {user}’s manager) 40
- 35. Components 41 OPA REST Microservice Bundle OPA can periodically download bundles of policy and data from remote HTTP servers. The policies and data are loaded on the fly without requiring a restart of OPA Authorize ? Sync policies Alice request
- 36. Steps ❏ Executing a request as Alice ❏ Executing a request as Bob ❏ Executing a request as Betty 42
- 37. Loading … PLEASE WAIT Demo time 43
- 38. What just happened ✓ Executing a request as Alice ✓ Executing a request as Bob ✓ Executing a request as Betty 44
- 39. Comments 45
- 40. Thank you. 46