Should OPA only be used to make decisions based solely on trusted data?

[clsweeting]

It seems that providing all of the necessary context (i.e. data relationships) for OPA to make decisions based on fully-validated data could add additional overhead to OPA/Rego. I'm wondering how others are approaching this, and whether it was the original design goal of OPA to actually solve for this or to allow the making of 'provisional decisions'.

For example, consider an API to update the information for a 'device':

1. We wish to authorize requests to an API endpoint such as:

   PUT /customers/{customerId}/devices/{deviceId}

2. Only users who have the device:admin role should be able to perform the above operation.

3. The user's access token (JWT) contains a roles claim which indicates the user's roles. The access token also includes the customerId.

   {
     "sub": "1234567890",
     "name": "Alice",
     "customerId": "xxxxxx-xxxx-xxxx-xxxxxxxx,
     "roles": [
          "device:admin",
          "data:reader" 
      ]
   }
   

   However all of the devices in the particular customer (tenant) are not included in the access token due to the sheer number of possible devices.

4. We have an Envoy proxy forwarding incoming requests to an OPA sidecar using the external authorization filter to validate the request based on the path and access token.

5. We then will have a Rego policy which:

   • identifies the operation ("update device") based on the pattern of the request path (/customers/{customerId}/devices/{deviceId}) and method (PUT).
   • checks whether the user has the necessary roles (in the access token) required to perform the operation
   • extracts the customerId from the request path, and ensures that it matches the customerId in the access token.

In the above scenario, OPA can trust the customerId since it is in the user's access token (signed JWT) but OPA does not validate that the device with ID deviceId actually belongs to the customer with ID customerId. Is this a problem?

On the one hand, OPA can make a policy decision based on the operation and OPA can validate that the user belongs to the Customer (tenant). BUT any authorization approval would be provisional on the API endpoint performing the data integrity check - i.e. validating that the Device belongs to the Customer. (This adds little overhead and should be done anyway by an API making CRUD updates to a relational database.)

Alternatively, we could have OPA/Rego make an external call to the database (potentially via an internal API) to verify that the device (identified by deviceId) belongs to the customer identified by customerId. This adds latency to the OPA authorization call, adds more complexity to OPA/Rego, and seems to defeat much of the distributed policy-decision-making which we had.... but provides the guarantee that OPA's decisions are based on 100% trusted data.

I'd be interested in any thoughts on how to approach this.

Thank you very much.

[anderseknert]

It is true that the provider of the device ID data in your case needs to be trusted. If you wish to avoid making external calls at policy evaluation time, the common approach is to provide data via bundles. Bundles are commonly deployed via servers like Nginx, or AWS S3. TLS should help ensure the server is who it says it is, and you can optionally sign the bundles to if you want something close to what you get from JWTs in the input. See the section on bundle signing in the bundle docs for that.

[clsweeting]

Thanks for taking the time to reply, @anderseknert. I was aware of the use of Bundles for policy updates but had envisioned that more for occasional changes to business rules... and had not considered using them to sync context data with the OPA sidecars. It's certainly appealing from the point of view of scalability and low-latency.

Timing of the policy updates will be critical given that there may literally be ~2 seconds between a user creating a device (POST /customers/{customerId}/devices) and then trying to edit or access it (GET/PUT /customers/{customerId}/devices/{deviceId}). But the HTTP Long Polling approach described on the Bundle page looks promising and we will have to test that.

Thanks again for your suggestion - it's given me much food for thought.

[anderseknert]

Great! Yeah delta bundles should definitely help with that. For the scenario where you'd want to POST a new device and immediately GET a list of devices back, I guess it could make sense to consider a temporary, and short-lived, cache that could be used as an additional datasource by the client to determine whethere a device belongs to a user before that data has made it into OPA's memory store. It all depends on your requirements of course :)