[HN Gopher] Policy as Code vs. Policy as Graph Comparison
___________________________________________________________________
Policy as Code vs. Policy as Graph Comparison
Author : gemanor
Score : 35 points
Date : 2023-06-28 10:34 UTC (2 days ago)
(HTM) web link (www.permit.io)
(TXT) w3m dump (www.permit.io)
| hosh wrote:
| If authorizations can be described as a policy graph, what about
| logic programming languages such as Prolog or Datalog?
|
| Would Datalog be performant enough at scale?
|
| I think one neat thing about logic programming languages is that
| you can ask for the reasoning chain to get to the conclusion it
| did, or do reverse queries. (Such as, give me all the actions
| that a person is authorized for this time)
| jeffchao wrote:
| That's a great observation. There's prior art in authorization
| (and also in the Kubernetes domain) with folks using Open
| Policy Agent -- specifically, Rego [0], a derivative of
| Datalog.
|
| I've used it with success in authorization, but the developer
| experience could be better. I've found the experience to be
| better when paired with some constraint framework.
|
| The other trade-off as mentioned in another comment is that
| it's stateless. The pro is that it's stateless, but the con is
| that someone needs to figure out a way to get input and data
| into your evaluation runtime so that you can write meaningful
| policies.
|
| [0] https://www.openpolicyagent.org/docs/latest/policy-
| language/
| jzelinskie wrote:
| Many of the optimizations used when traversing the graph for
| SpiceDB are inspired by research in the various dialects of
| Datalog. At the end of the day, there are very few operations
| that authorization systems need and it makes more sense to
| optimized those for folks than give them direct access to
| Datalog or general purpose graph languages like Gremlin.
| hirundo wrote:
| Seems like the lisps are already both as written, and any
| language that can be rendered as an s-expression is either.
| tommiegannert wrote:
| SecPAL (~2007) was essentially Datalog for policy (the paper
| included a transform to Datalog.) I'd be interested to know if
| anyone implemented it.
|
| https://en.wikipedia.org/wiki/SecPAL
| rsstack wrote:
| That's what Oso do: https://docs.osohq.com/guides/policies.html
| cryptonector wrote:
| > If authorizations can be described as a policy graph, what
| about logic programming languages such as Prolog or Datalog?
|
| Or why not SQL?
|
| Which will be more optimized -or is easier to optimize- for the
| logic in question?
| refset wrote:
| Likely of interest: https://neilmadden.blog/2022/02/19/is-
| datalog-a-good-languag... (Feb 2022 discussion:
| https://news.ycombinator.com/item?id=30400886)
| kkajla wrote:
| I would describe this debate more as Policy-as-Data (Zanzibar) vs
| Policy-as-Code (OPA et al).
|
| In Zanzibar, all of the information required to make an
| authorization decision (namespaces, relationship tuples, etc.) is
| stored in Zanzibar, and the decision engine resolves access
| checks based on this data. This data can be scaled horizontally
| (and consistently) as needed for an application's needs. This
| makes Zanzibar a centralized, unified solution for all of an
| application's authorization needs. I've found this approach more
| purpose built / well suited for application authorization.
|
| With OPA and other policy engines, the data required for
| performing access checks lives somewhere else (maybe the
| application's database) and must be separately queried and
| included as part of the authorization check because OPA et al.
| are stateless decision engines. This makes it such that you need
| to piece together data from different sources in order to get
| your final decision, which IMO is something most developers don't
| want to deal with.
|
| On the flip side, Zanzibar's "namespaces" are a very simple
| policy layer not well suited to querying against data outside of
| Zanzibar's scope (e.g. geolocation, time, etc). For scenarios
| like this, a full fledged policy-as-code solution is great.
| However, it should be noted that some open source Zanzibar
| implementations like Warrant[1] and SpiceDB[2] (mentioned in the
| article) also offer a policy-as-code layer on top of Zanzibar's
| graph-based/ReBAC approach to tackle these scenarios.
|
| Disclaimer, I'm one of the founders of Warrant.
|
| [1] https://github.com/warrant-dev/warrant
|
| [2] https://github.com/authzed/spicedb
| convolvatron wrote:
| I don't see the dichotomy. in all the work I've done lately in
| this area there is a defined schema for a rule - so its really
| not that hard to be code and data, maybe even more so in a
| declarative world.
| kkajla wrote:
| That's fair and also why I believe a complete authz solution
| needs some elements of both.
| esafak wrote:
| Yet another authz provider. I can't keep up :|
|
| At least permit.io's differentiation is clear: they support
| multiple policy engines.
| gneray wrote:
| They do not
| jzelinskie wrote:
| Disclosure: I'm a cofounder of Authzed and one of the creators of
| SpiceDB, the primary strawman for graph-based authorization used
| in this article.
|
| I don't believe that any of the data being represented in this
| article is ubiquitously true, though it might be true for the
| users self-select into adopting Permit. There is no one sized
| fits all solution for authorization and we see folks self-
| selecting in the other direction, so I'd like to offer that take.
|
| >Despite their advantages, deploying a Zanzibar-based graph
| invariably introduces a sizable and complex system into your
| cloud environment, often necessitating reliance on a hosted
| service. This dependency can instigate latency concerns and
| further scaling challenges.
|
| There are plenty of happy SpiceDB open source users and on-
| premise Authzed customers that have no need for a hosted service.
|
| Using a hosted service doesn't mean adding additional latency.
| For example, Authzed's services deploy to the same cloud
| datacenters as your applications, so the latency is no different
| from your application connecting anything else not running on the
| same machine.
|
| We've helped folks migrate away from policy-based systems because
| having unbounded computation eventually leads to the inability to
| make guarantees about performance. It's easy for developers to
| over time add more and more logic to the sets of policies that
| are critical until they become too slow for some of the services
| that depend on them.
|
| Lest we also not forget the complexity and scaling challenges a
| system that has to keep data in policy engines synchronized.
|
| ---
|
| I'd also like to point out a few things from the comparison
| table:
|
| Nature of Access Control: As stated in this article, SpiceDB
| supports ABAC and can model more than just RBAC and ABAC.
|
| Reverse Indices: This is a big deal. What systems can you build
| without asking "Who are all the people with access to this?" and
| "What are all the things this person can access?".
|
| Latency & Performance: SpiceDB guarantees runtime performance no
| matter the scale and complexity and operates on a consistent view
| of data while policy engines typically end up working on stale
| data. Unfortunately, this is comparing apples to oranges because
| the two systems are generating two different qualities of
| decision.
|
| Deployment at Edge: SpiceDB and Zanzibar were designed to run at
| a global scale. You can run a SpiceDB cluster at each edge that
| share a global backing relationship store (Spanner or
| CockroachDB). I'm not familiar with any policy engines that were
| designed while considering where the data lives -- as such they
| require additional systems to best-effort synchronize data to
| those engines.
|
| Ease of Updates: Honestly, this is purely opinion. It's quite
| simple to exhaustively test SpiceDB schemas to assert correctness
| -- play.authzed.com even generates them for you. I think it's
| more difficult testing turing-complete policies.
|
| Ecosystem: "Emerging ecosystem" is sold in the article as an
| anti-feature when it is a feature depending on your own goals;
| for something to be emerging and gaining traction, it has to be
| seen as an improvement over existing systems. Despite calling
| ReBAC systems "emerging", the article does describe SpiceDB
| itself as mature, though.
| cryptonector wrote:
| > However, [policy as graph systems] do come with drawbacks.
| Compared to policy-as-code, graph-based systems exhibit lower
| performance and are practically unfeasible to run at the edge due
| to their size. They also come with higher latency, owing to their
| non-local nature, and are limited to simple ReBAC policies (even
| SpiceDB Caveats you end up with a limited form of ABAC, crippled
| even further with loading dynamic data).
|
| You can use a bit of code atop what TFA calls ReBAC to get ABAC.
|
| Suppose your ReBAC check primitive is `check(subject, verb,
| label)`, and you want to have subject attributes like "DID_2FA",
| "DID_MFA", "IS_INSIDE_PERIMETER", etc., and grant/label
| attributes like "REQUIRES_2FA", etc, you might implement
| `check_prime()` like: check_prime(s, v, l):
| if !check(s, v, l): return false if
| l.wants_2fa() and !s.did_2fa: return false
| ...
|
| Where grant/label attributes are singletons that imply one
| subject singleton attribute is required then this can be
| simplified and made more extensible.
|
| In other words: start with ReBAC and add the ABAC bits you want.
| I.e., cross the two schemes.
| jzelinskie wrote:
| >In other words: start with ReBAC and add the ABAC bits you
| want. I.e., cross the two schemes.
|
| This is the approach by SpiceDB as mentioned in the article:
| https://authzed.com/blog/caveats
| brutusborn wrote:
| It would be good to include some examples. No code or graphs in
| the entire post.
___________________________________________________________________
(page generated 2023-06-30 23:01 UTC)