tsandall

> Did you guys build your own engine? I took a quick look at the repo but don't see anything that looks like a datalog library in your glide package list.

Yes, the language implementation (parser/compiler/evaluator) is implemented from scratch.

> Last but not least, thanks for making and open sourcing such an awesome tool!

Thanks for the kind words! If you have questions or need help, feel free to file issues on Github or ask questions on Slack.

(OPA co-founder here.)

The semantics of OPA's policy language are based on Datalog, a non-Turing complete subset of Prolog. This means that all policy queries in OPA are guaranteed to terminate (which makes it a good fit for problems like authorization.)

Beyond regular Datalog, OPA adds first-class support for querying complex/nested data structures like JSON.

As a side note, OPA was not developed at Netflix, but they were one of the early adopters and continue to use it today.

Hello! You can certainly use OPA to answer the kinds of policy questions in your examples. OPA is not tied to a particular domain (which is why we call it general-purpose.) Whether you're writing policy over movies, games, etc. it's all the same to OPA (JSON).

There are no Greeks among the core contributors :-(

OPA draws some inspiration from XACML. For example, OPA helps systems separate policy decision-making from policy enforcement. Decoupling means that policy decisions can be more easily updated and more readily understood.

XACML as a specification covers multiple things (e.g., access control language, overall architecture, etc.) If you wanted to map OPA to a component in XACML, it's closest to the PDP.

That being said, OPA gives you a more expressive language to author policy. Also, OPA is intended to be used as building block in other systems. OPA exposes APIs to offload policy decisions from services and manage the policies and data that are evaluated. One of the non-goals of OPA is management-plane concerns around policy storage, policy administration, etc.

Hello! The semantics are based on Datalog--but we've added a few features that make it more expressive than just plain Datalog. For example, OPA has first-class support for accessing nested data structures like JSON. At the same time, OPA does not support recursion today, however we've found you can get quite far without it.

I don't think that Golang introduces any unique challenges for implementing a logic system, just the usual suspects like garbage collection, lack of generics, etc.

Hope this helps.

There are a few ways of doing this.

1. You can include JSON data as input when you execute a policy query. In your example, you could include the management hierarchy or a user in a JWT that's provided as input to the policy query.

2. You can load JSON data into OPA out-of-band. OPA will cache this data in-memory and you can refer to it in your policies. There are two ways to do this. (a) use OPA's REST API to push data into the engine (e.g., PUT /v1/data/management/hierarchy <JSON body>) or (b) use OPA's Bundle feature to pull down bundles of policy and data from a remote endpoint.

3. If providing the data as input or out-of-band will not work, we have an experimental HTTP built-in function that you can call inside your policies to query the external data source on-the-fly when the policy is evaluated. This feature is still experimental but over time we intend to improve support for it (e.g., currently you can't mock out these built-in calls, but it's on the ROADMAP.)

Regarding limits, OPA keeps policies and data in-memory, so you're limited by RAM on a single host.

Thanks, this is helpful. We'll look at improving the opening paragraph for the wider audience.

Co-author of OPA here. I’m happy to answer any questions about the project!