trino-opa-plugin

[rodolfototaro]

Developing a plugin that provides a SystemAccessControl implementation that delegates authorization decisions to OPA (Open Policy Access) technology

[kokosing]

OPA is a framework. You would need to first implement authorization model in OPA that you would need to use. Or do you think about a generic plugin that communicates with with OPA but authorization model is some injected into a plugin via configuration?

Can you please elaborate how you would like to address this?

[rodolfototaro]

I'm already implementing a plugin for OPA that delegates the decision to OPA Server. So the plugin just queries OPA server with parameters of the authorization method and address the responses from it. i.e.

for the method
default Set<String> filterCatalogs(SystemSecurityContext context, Set<String> catalogs)

the plugin ask to OPA server to evaluate the rule filterCatalogs with the following input:

{
  "catalogs": [
    "system",
    "jmx",
    "tpch"
  ],
  "context": {
    "identity": {
      "user": "bob",
      "groups": [],
      "principal": {
        "name": "bob"
      }
    }
  }
}

the result will be

{
  "result": [
    "tpch"
  ]
}

the policy is like the following

filterCatalogs[catalog]{
    check_any_catalog_access(input.catalogs[i])
    catalog = input.catalogs[i]
}

[omissis]

For validating the approach I wrote OPA policies implementing the same logics of the FileBasedSystemAccessControl reading json configuration as OPA data files. I ported the current test suite of FileBasedSystemAccessControl in my plugin. This set of rego files could be used as a starting point for customizing your opa based access control.

[kokosing]

Would it be possible that we run same set of tests for your OPA and FileBasedSystemAccessControl to make sure they are coherent? The best if we would simply reuse tests but only have different infrastructure.

[rodolfototaro]

IMO It is not needed that they are coherent. The goal is to test the plugin opa wrapper and to validate the approach. Moreover you could use the rego files written for the tests as a starting point for your policies but if you need the behaviour of the FileBasedSystemAccessControl you can use it directly.

[kokosing]

IMO It is not needed that they are coherent.

I mean we should provide rego files for OPA where we would be able to get the same behavior. FileBasedSystemAccessControl is something that we maintain for a long time and it has lot thoughts inside. I think being able to follow the same authorization model in OPA would validate the approach. Otherwise, it will be a challenge to make sure that authorization model you might have with OPA is secure.

[kokosing]

But I hear your point. We could have some kind of API that we require OPA to provide and users might implement it differently according to their needs. However we need to have something decent that users can use out of the box. Like a recommended template.

[vagaerg]

We've been in touch with the developers of https://github.com/stackabletech/trino-opa-authorizerhttps://github.com/stackabletech/trino-opa-authorizer and created a fork of their code to be mainlined and with some tweaks.

This is a WIP, but see #17940

[YuriyGavrilov]

+1

[ebyhr]

Closing as #19532