7 ms·

Policy as Code vs. Policy as Graph Comparison

39 points by gemanor 3y ago

hosh 3y ago
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)
- refset 3y ago
  Likely of interest: https://neilmadden.blog/2022/02/19/is-datalog-a-good-language-for-authorization/ https://neilmadden.blog/2022/02/19/is-datalog-a-good-languag... (Feb 2022 discussion: https://news.ycombinator.com/item?id=30400886 https://news.ycombinator.com/item?id=30400886)
- tommiegannert 3y ago
  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 https://en.wikipedia.org/wiki/SecPAL
- cryptonector 3y ago
  > 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?
- hirundo 3y ago
  Seems like the lisps are already both as written, and any language that can be rendered as an s-expression is either.
- rsstack 3y ago
  That's what Oso do: https://docs.osohq.com/guides/policies.html https://docs.osohq.com/guides/policies.html
- jzelinskie 3y ago
  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.
- jeffchao 3y ago
  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/ https://www.openpolicyagent.org/docs/latest/policy-language/
- orweis 3y ago
  That's exactly what OPA does (Datalog), and what OSO do (Prolog)
kkajla 3y ago
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 https://github.com/warrant-dev/warrant [2] https://github.com/authzed/spicedb https://github.com/authzed/spicedb
- convolvatron 3y ago
  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 3y ago
    That's fair and also why I believe a complete authz solution needs some elements of both.
- throwawy234 3y ago
  Why does the Ruby SDK not use a constructible client like other SDKs? It does not look re-entrant.
esafak 3y ago
Yet another authz provider. I can't keep up :| At least permit.io's differentiation is clear: they support multiple policy engines.
- gneray 3y ago
  They do not
  - orweis 3y ago
    Or from Permit.io here :) - we support OPA, Cedar, as well as Amazon Verified Permissions, and we'll be coming out with more soon. Both in Permit.io and in OPAL 1 Graham from OSO (gneray) - just didn't see the recent news, I guess we'd need to speed up OSO support as well ;-) 1 - https://docs.opal.ac/tutorials/cedar https://docs.opal.ac/tutorials/cedar
- orweis 3y ago
  BTW another differentiator we offer- is our low-code policy editor that write Rego or Cedar directly into Git for you (And your non-technical team members) Supports RBAC, ABAC - and next month ReBAC https://docs.permit.io/features/policy-editor/editor-overview https://docs.permit.io/features/policy-editor/editor-overvie...
brutusborn 3y ago
It would be good to include some examples. No code or graphs in the entire post.
jzelinskie 3y ago
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 3y ago
> 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 3y ago
  >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 https://authzed.com/blog/caveats

39 points by gemanor 3y ago

hosh 3y ago

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)

refset 3y ago
Likely of interest: https://neilmadden.blog/2022/02/19/is-datalog-a-good-language-for-authorization/ https://neilmadden.blog/2022/02/19/is-datalog-a-good-languag... (Feb 2022 discussion: https://news.ycombinator.com/item?id=30400886 https://news.ycombinator.com/item?id=30400886)
tommiegannert 3y ago
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 https://en.wikipedia.org/wiki/SecPAL
cryptonector 3y ago
> 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?
hirundo 3y ago
Seems like the lisps are already both as written, and any language that can be rendered as an s-expression is either.
rsstack 3y ago
That's what Oso do: https://docs.osohq.com/guides/policies.html https://docs.osohq.com/guides/policies.html
jzelinskie 3y ago
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.
jeffchao 3y ago
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/ https://www.openpolicyagent.org/docs/latest/policy-language/
orweis 3y ago
That's exactly what OPA does (Datalog), and what OSO do (Prolog)

kkajla 3y ago

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 https://github.com/warrant-dev/warrant [2] https://github.com/authzed/spicedb https://github.com/authzed/spicedb

convolvatron 3y ago
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 3y ago
  That's fair and also why I believe a complete authz solution needs some elements of both.
throwawy234 3y ago
Why does the Ruby SDK not use a constructible client like other SDKs? It does not look re-entrant.

esafak 3y ago

Yet another authz provider. I can't keep up :| At least permit.io's differentiation is clear: they support multiple policy engines.

gneray 3y ago
They do not
- orweis 3y ago
  Or from Permit.io here :) - we support OPA, Cedar, as well as Amazon Verified Permissions, and we'll be coming out with more soon. Both in Permit.io and in OPAL 1 Graham from OSO (gneray) - just didn't see the recent news, I guess we'd need to speed up OSO support as well ;-) 1 - https://docs.opal.ac/tutorials/cedar https://docs.opal.ac/tutorials/cedar
orweis 3y ago
BTW another differentiator we offer- is our low-code policy editor that write Rego or Cedar directly into Git for you (And your non-technical team members) Supports RBAC, ABAC - and next month ReBAC https://docs.permit.io/features/policy-editor/editor-overview https://docs.permit.io/features/policy-editor/editor-overvie...

brutusborn 3y ago

It would be good to include some examples. No code or graphs in the entire post.

jzelinskie 3y ago

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 3y ago

> 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 3y ago
>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 https://authzed.com/blog/caveats