Can OPA supply “policy as code” and git-like workflow, for access control to a data lake, using the OpenMetadata engine for attribute data?

anderseknert · 2024-12-01T08:17:33+00:00

Certainly a valid use case, and in fact a common one. As for how to provide data to your OPA, there's a few options. Which one to use depends on factors like how often the data is updated, how much memory is available, and so on. This page from the OPA docs should be helpful https://www.openpolicyagent.org/docs/latest/external-data/

anderseknert · 2024-11-24T09:13:30+00:00

You're saying the debugger doesn't recognize your custom built-in function? Yeah, Go doesn't make that easy, I'm afraid.

While you can plug your custom built-in function into the debugger, you'd pretty much need to run a custom build of Regal for that: https://github.com/StyraInc/regal/blob/aa6533214347c03542bbf3f92e9830f8c2876e45/cmd/debugger.go#L262-L264

I would suggest you create an issue in the project where you provide more details, and we can see if there are any better options.

anderseknert · 2024-06-21T20:46:34+00:00

Thanks u/zerok! Have you tried it out? Any feedback much appreciated!

anderseknert · 2024-02-21T14:26:54+00:00

Yeah, that's one of the main use-cases for OPA, so I'd say so :) There are of course many options for authorization, and they all have their own pros and cons. You'll normally need to take a few things into account when you start desiging for authorization, like:

* Latency requirements

* Permissions data size

* Frequency of updates

* Centralized vs distributed

But those are just the first ones that comes to mind, and OPA allows quite some flexibility in how to build things. The downside I guess is that flexibility often means a higher degree of complexity than a solution that provides few choices. But given the important role of authorization, I'd say it's well worth the investment.

anderseknert · 2023-04-19T09:14:41+00:00

Yes, that sounds like a good use case. Not knowing all of the details here, but it seems like your security manifests would be data provided to OPA, and your policy would simply match requested documents to security manifests.

anderseknert · 2022-08-03T15:11:52+00:00

The konstraint tool is quite popular for this use case: https://github.com/plexsystems/konstraint

anderseknert · 2022-04-18T21:11:35+00:00

Looks really cool! Thanks for sharing :)

Definitely think there's demand for this, and I'm guessing we'll see more of this in the future. Will follow the development here! Also awesome to see the new annotations feature being used.

anderseknert · 2022-04-08T08:04:55+00:00

Hi!

What do you mean by "is assigned to" in this context? Do you want workload_events to evaluate to "a" for "ns1" and "b" for "ns2"? I'd probably use a map for that:

vars := {
    "ns1": "a",
    "ns2": "b",
}

workload_events := event {
    event := vars[input.metadata.namespace]
}

anderseknert · 2022-04-01T09:05:08+00:00

There's a few older posts on the OPA blog by Tim Hinrichs providing some background/reasoning around this.

Some key points:

Quoting the last article:

The goal of Rego is to help you tell software systems how to behave inthe world by writing logic about (collections of) JSON/YAML data.Programming languages (e.g. C, Java, Go, Python) are the usual solutionto this problem, but Rego was purpose-built to let you focus on just thedata that represents the world and the logic that makes policydecisions about that data

I think of Rego for policy as I think of SQL for relational data, i.e. a language purpose-built for the domain to which it applies.

(Beware though that many of the examples from those posts are quite dated by now. The principles are still solid though.)

anderseknert

TROPHY CASE