What needs to know about the microservices logic to write OPA policies for authorization (boundaries between OPA policies and microservices logic)

[rkhalyleh]

Hi All,
I'm new to OPA, I've microservices deployed on Kubernetes, and I plan to use OPA for authorization, main goal is to separate authorization decision making outside microservices logic.
My question is, What are the information needed to know about microservices side in order to implement the OPA policies (level of details)? such as whoever write these policies, Is it enough to be aware about what are the REST APIs exposed from microservices to write policies?
What are levels in microservices can OPA cover for authorization? e.g. can only cover endpoints (REST APIs)? Or more levels on microservices logic?

Thanks!

[anderseknert]

Hi Rami! And welcome to the OPA community :) Sounds like you are on the right track decoupling authorization policies from you application.

The information needed to make policy decisions vary widely between applications, but some things that are pretty common to want to include to make an informed policy decision includes:

• Information about the request: method (POST, GET, DELETE, etc), the request path and query parameters, maybe some headers and other information that might be useful.
• Information about the user or client making the request. This is ideally transferred from the identity server in the form of a signed JSON Web Token, but could be provided as part of the input in other forms as well.
• Information about the resource being accessed, including permissions needed for viewing or modifying it.

The docs section on RBAC provides a basic example of what this might look like, and there are also a couple of examples in the Rego Playground (see Examples and Access Control).

Let me know if there's anything more specific you'd want me to expand on.

[rkhalyleh]

Thanks a lot @anderseknert for the information, I will start looking into resources you shared.

Question, suppose that I have 2 users, with 2 different roles, both users access the same REST API, and the REST API should return different data based on user's role, e.g. one of the users, should receive detailed information, and the other one not. Can handle this case on OPA policy level? Or should handle such a on endpoints level (REST API)?

[anderseknert]

If you want to do data filtering based on roles, there are a couple of ways you can approach this:

• Retrieve the data beforehand an send to OPA as input, return the data filtered based on role and/or other attributes.
• Retrieve the data in-policy using the http.send built-in and return a filtered version based on role and/or other attributes.
• Pre-populate data into OPA using bundles or the OPA REST API, return a filtered version based on role and/or other attributes.
• Use the compile API and partial evaluation to return a new query to the client, which could be translated into something like SQL for fetching a filtered version of the data based on role and/or other attributes.

If you're just starting out with OPA I'd suggest maybe using http.send to keep it simple, then evaluate other approaches if your needs require that, like if you have huge datasets, etc.

[rkhalyleh]

Thanks a lot for clarifications
I started looking into the details