neupatr
Joined 5 years ago
Karma
37
Submissions
8
Member since
Apr 8
Recent submissions
Comment · 5 years ago
So the idea in the paper is that you store a version token (aka. zookie) next to every object version. When you ask Zanzibar if a user is allowed to modify it, the request contains the stored token. Then you get a new token with a successful response that you store with the new version. This guarantees that a user can only access 1. objects they have access to and 2. objects they don't have access to but only at versions they once had access to. The second case only occurs until an ACL update propagates around the globe and through all distributed caches. In our opinion that can be added later on (the proto definitions already account for that), although it is a breaking change of course.
One important point is that Keto can be operated locally as well, which means there are no database sync delays. This is the only mode it supports right now, and it does not need the zookies for that.
Comment · 5 years ago
Exactly, all of our products come without any UI whatsoever. There are example UIs that could be improved, but they can get you started easily. Something like stripe's hosted pages is on our list, just not had the time to implement it yet.
Comment · 5 years ago
We see it as a very universal service, so integration with k8s is definitely on our list, but there are no concrete plans yet. The ACLs are just so generic, you can describe anything with it.
Comment · 5 years ago
OPA takes a whole different approach. They basically have a specific language and a corresponding interpreter. The previous version of Keto was based off of OPA. We discovered that it is not suitable for our needs and what we want to offer because it can be very hard to meet certain performance goals (e.g. https://github.com/ory/keto/issues/104)
Taking this simple approach allows us to provide a global, low latency, and consistent authorization system.
Comment · 5 years ago
Keto only does authorization, independent of users, devices, bots, applications, ... Basically you store your ACLs there and then ask "is _subject_ allowed to do _relation_ on _object_". All the variables are whatever you define them to be.
Check out https://github.com/ory/kratos, our identity server. Or https://github.com/ory/hydra, our OAuth2 server. All of them together can be assembled to have something like Keycloak.
Comment · 5 years ago
Thank you ;)
Comment · 5 years ago
Hm good point. The project itself exists already for quite some time now, this is just a complete rewrite. It is named after an ancient Greek goddess: https://en.wikipedia.org/wiki/Ceto (all of our projects are named after Greek mythology).
Comment · 5 years ago
Hello! I am one of the maintainers of Ory Keto. We spent a lot of time and effort to read, learn, and analyse the Google Zanzibar paper (https://research.google/pubs/pub48190/) and the release brings that all together. There are still many things missing, but with a great community we hope to build the “Kubernetes” of permissions and access control! If you have any questions, I am here to help