Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Open Policy Agent

openpolicyagent.org

Post reply on HN
Print view View original

41–46 of 46 posts

Re: Open Policy Agent

#41

Post by ogazitt »

shriek wrote: post #34
ffk wrote: post #30

Earlier quoted context omitted.

On the first point, OPA is much older than OpenFGA. To really illustrate the point, OPA became a graduated project about a year before OpenFGA had their first code drop in the public GitHub repo. The OpenFGA people are aware of OPA and I'm sure they learned from the tradeoffs OPA made. To the main point, what you described reflects the current trends of authorization. Define a data model, define data that adheres to…

Yeah, that's what I've noticed too. Conceptually, they're more or less same giving an option of RBAC, ABAC or ReBAC and each offer their own DSLs (e.g. Oso, Ory Keto etc) and deployment strategies. It's been a bit harder to pick one honestly but I guess I'll just have to just use them to find which one fits for me.

If you want to try Topaz (which supports all three), check it out here [0]. We'd love to help you solve your authorization scenario :)

[0] https://github.com/aserto-dev/topaz

Re: Open Policy Agent

#42

Post by the_newest »

grinich wrote: post #25
the_newest wrote: post #10

Earlier quoted context omitted.

I work in a highly regulated environment and evaluated using Cedar or OPA. The biggest advantage to OPA was the flexibility. This enabled not just an authorization decision, but the why behind it. No more questions of why did this person/system gain (or was denied) access, combing through dozens of rules to find the matching statements. Just pull up the log and read the results… This is incredibly useful during audit…

Is that issue with Cedar related to their design or just the current way it's exposed by AWS?

It's a cedar related issue. I like to know every check that was run for a policy and the result. Cedar will only provide the name of the policy that granted/denied.

Re: Open Policy Agent

#43

Post by max2 »

jasonjayr wrote: post #21
AgentOrange1234 wrote: post #15

Earlier quoted context omitted.

Seems pretty damning. Why would someone choose Cedar? Is there some upside that isn’t captured here?

AWS uses it and the policy language is similar, and if you are all in on AWS, then it makes sense to keep it for consistency?

There is actually pretty vibrant and diverse Cedar community. Check out their slack.

Re: Open Policy Agent

#44

Post by max2 »

the_newest wrote: post #42
grinich wrote: post #25

Earlier quoted context omitted.

Is that issue with Cedar related to their design or just the current way it's exposed by AWS?

It's a cedar related issue. I like to know every check that was run for a policy and the result. Cedar will only provide the name of the policy that granted/denied.

So you want list of all policies that have been considered, not just those that have been satisfied?

Re: Open Policy Agent

#45

Post by alex-olivier »

OPA and its derivative projects really brought the idea of decoupled authorization as a viable option. It is a very powerful tool which can be applied to many layers of the architecture - from Kubernetes Admission Controllers being based on it through to network level authorization and up the full stack.

One area that is a constrained and narrow use case is around the actual application level permissions - eg what a user can do inside of your service. Having hand-rolled this in various companies - and the inevitable rebuilds that were required as requirements change such as adding a new, product packaging updates etc - you do end up with a complex web of logic - ether in your codebase or as Rego.

For these application level permissions - where the requirements really come from the product/business rather than engineering - I always felt there could be a simpler way of defining this rules. Policies needed to be in a format a business user could understand, and enforcing them needs to be extremely responsive as checks are in the blocking path of every request - and this needs to work at large scale - all whilst making every decision auditable to tick all the regulatory and compliance needs around access controls.

To this effect we begun working on Cerbos[0] a few years ago which initially targets that one specific use case - models policy in simple YAML [1] (love it or hate it!) and takes a stateless approach meaning it is infinitely scalable with none of the headache of synchronizing information about your users or resources to the authZ layer, also critically generates that single audit log of decisions.

Disclaimer: I work on the team that builds and maintains Cerbos[2].

[0] https://github.com/cerbos/cerbos

[1] https://play.cerbos.dev/p/XhkOi82fFKk3YW60e2c806Yvm0trKEje

[2] https://cerbos.dev

Re: Open Policy Agent

#46

Post by yencabulator »

gsarjeant wrote: post #38

For application authorization, Oso is a compelling solution. (Disclaimer: I work for Oso). It provides a DSL and a prescriptive, but flexible data model that are capable of modeling RBAC, ReBAC, ABAC, or whatever else you'd like to model. Obviously I'm biased, but I think it strikes a great balance between opinion and flexibility. One significant complication that all centralized authorization solutions share is that…

Oso is abandoned by its authors: https://www.osohq.com/docs/oss/getting-started/deprecation.h...
Post reply on HN