Open robinbraemer opened 4 years ago
Yes, this makes absolute sense. We have good a relationship with the OPA maintainers and I am sure that they would appreciate and potentially even support such an effort!
Nice, this actually goes hand in hand with my considerations in #319
It also makes sense because we could simply publish a tutorial for running OPA with the current Ory Keto policies, which would allow people to do a "soft" migration of current Ory Keto to another system that still works as they're used to.
Yes :heart_eyes: I had headaches because of migration paths for current users already.
Hello contributors!
I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue
Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.
Unfortunately, burnout has become a topic of concern amongst open-source projects.
It can lead to severe personal and health issues as well as opening catastrophic attack vectors.
The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.
If this issue was marked as stale erroneously you can exempt it by adding the backlog
label, assigning someone, or setting a milestone for it.
Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!
Thank you 🙏✌️
Note-taking comment:
Topaz is basically doing what I described in this issue, provide Rego functions to call a Zanzibar system as part of the evaluation step: https://www.topaz.sh/docs/intro#zanzibar--rebac
Authorization policies can combine ABAC-style rules with ReBAC-style graph queries via a set of Rego built-ins.
Also related to this issue: https://news.ycombinator.com/item?id=33319515
Hello contributors!
I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue
Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.
Unfortunately, burnout has become a topic of concern amongst open-source projects.
It can lead to severe personal and health issues as well as opening catastrophic attack vectors.
The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.
If this issue was marked as stale erroneously you can exempt it by adding the backlog
label, assigning someone, or setting a milestone for it.
Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!
Thank you 🙏✌️
As Keto defines itself as:
a policy decision point. It uses a set of access control policies, similar to AWS IAM Policies, in order to determine whether a subject (user, application, service, car, ...) is authorized to perform a certain action on a resource.
It would be interesting that, if the ecosystem opens to other Policy based Access Control, to consider Cedar as an extension to it as its opensource birth came for year of maintaining, operating, and evolving AWS IAM.
Did the project ever decide on dealing with this inside Keto (OPA integration), or is this left as an excersize to the reader still? We are going to be using both in a project, just wondering if I can get them to talk to together or what.
Maybe it is already obvious to some, or maybe I can present some new viewpoints, but I wanted to write it down and formalize my thought experiment to everyone.
Looking ahead, as part of Next Gen Keto's efforts to empower wider ecosystems to configure policy and access control, specifically Access Control Lists and other authorization models, in a more scalable and distributed way, Next Gen Keto will not only be able to be used as a single service for access control and be the base authorization system other services depend and built on, but also should support integration with Open Policy Agent using OPA's extension functionality in that Keto's ACL system can be used to setup more various policies with OPA while leveraging Keto's powerful ACL system to fetch checks efficiently.
Keto ACL is not designed to be a complex policy engine, but allows efficient ACL checks at scale, that OPA cannot do (as built-in). ACL check requests in Next Gen Keto are still limited to it's small and simple set of parameters in which more complex policies cannot be defined like in OPA.
This makes the comparison of Next Gen Keto vs. OPA an oranges and apples comparison. Both systems are better in solving different aspects in the world of access control.
Businesses need a platform to define complex policies, extend and unit test their policy, which OPA is perfect for!
Adding Next Gen Keto into construct it can, as well, be put as an additional tool to extend Open Policy Agent functionality for providing scalable "object,relation,subject" ACLs.
This effectively means, OPA is like the platform that Keto can integrate with too. Much like Kubernetes is the operating system for Istio, while Istio could also be setup in a non-k8s environment.
Therefore we should provide OPA rego functions that users can use in OPA to perform checks via their Keto deployment as part of their policy setup.