[HN Gopher] Open Policy Agent
___________________________________________________________________
Open Policy Agent
Author : julien040
Score : 47 points
Date : 2024-03-12 16:59 UTC (6 hours ago)
(HTM) web link (www.openpolicyagent.org)
(TXT) w3m dump (www.openpolicyagent.org)
| FLT8 wrote:
| My team is using OPA in a re-build of an application that we
| support. One of the main goals of the rebuild is to ensure we
| don't end up in a situation where every little rule change
| (including UAM changes) requires a full rebuild/deploy cycle of
| the app.
|
| OPA replaces a complex hard-coded, and largely inscrutable UAM
| model with a (still complex), but flexibly defined, independently
| testable, and easily inspectable single-responsibility model.
|
| I like that OPA has built in support for testing rulesets. The
| partial evaluation feature is amazing, ands makes it easy to
| apply UAM filters to endpoints that return large sets of data (we
| have consistent query APIs across the app, so could do this with
| a relatively simple OPA-aware proxy).
|
| It's not all sunshine and roses, and the result might seem overly
| complex for a lot of use cases, but in our case I think OPA has
| provided a nice clean abstraction and enabled us to disentangle
| our UAM from the rest of our code and move more quickly overall.
| alator21 wrote:
| OPA was one of the most cursed things I have ever worked with.
| mstade wrote:
| OPA, or rego? My experience working for Styra was that most
| people seemed to grok where OPA fit in fairly quickly, but
| struggled with rego. It's a very powerful language and well
| worth learning I think, but it's an investment for sure.
| tekla wrote:
| I agree, Rego was a hell of a thing to try and figure out.
| pushedx wrote:
| Used it during my last gig for policy enforcement on a multi-
| tenant platform for internal applications.
|
| I found it relatively easy to use and at a good level of
| abstraction to make the policies relatively reusable.
| mstade wrote:
| Nice to see OPA making the front page! I'm a bit biased though, I
| used to work at Styra :o)
| ipython wrote:
| Curious what folks think about this versus cedar
| (https://www.cedarpolicy.com/), the open source policy engine
| behind aws verified permissions.
| biggestlou wrote:
| OPA is much more wide ranging. You can use it for permissions,
| sure, but also just about anything else you can imagine. I
| think that makes it much more compelling as a technological
| investment.
| the_newest wrote:
| 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 audits.
|
| Cedar could not provide that level of detail (or so I was told
| by AWS representatives selling their hosted version).
| charlieegan3 wrote:
| I detailed a comparison of OPA and Cedar with verified
| permissions here: https://www.styra.com/knowledge-center/opa-
| vs-cedar-aws-veri...
| charlieegan3 wrote:
| If you're using OPA or learning Rego, you might be interested in
| checking out Regal - the Rego linter.
|
| https://docs.styra.com/regal
|
| Disclaimer: I work on this but it's free, & open source!
| ogazitt wrote:
| OPA is a great tool for implementing a policy-as-code system. But
| if you're trying to use it for application authorization (e.g.
| fine-grained authz for B2B SaaS or a set of internal
| applications), you may find that its policy story is strong, but
| it doesn't really have a "data plane": you either store data in a
| data.json file and rebuild the policy any time that data changes,
| or make an http.send call out of the policy to fetch dynamic
| data.
|
| Check out Topaz [0], which uses OPA as its decision engine, but
| adds a data plane that is based on the ReBAC ideas explored in
| the Google Zanzibar [1] paper.
|
| Disclaimer: I work on the team [2] that builds and maintains the
| Topaz project.
|
| [0] https://www.topaz.sh
|
| [1] https://research.google/pubs/zanzibar-googles-consistent-
| glo...
|
| [2] https://www.aserto.com
| andyroid wrote:
| Bundle servers provide a centralized "data plane" decoupled
| from the distributed component (OPA). You don't need to rebuild
| your policy any time data changes. Just push a new bundle with
| the data that changed, and OPA will fetch it as configured --
| either periodically or directly if long polling is configured.
|
| https://www.openpolicyagent.org/docs/latest/management-bundl...
___________________________________________________________________
(page generated 2024-03-12 23:01 UTC)