31–40 of 99 posts
I'm curious what's driving the resurgence in interest authorization infrastructure, particularly the Zanzibar paper. As founder of Oso ( https://www.osohq.com/ ), I have my own opinions, and I think this is a good thing. But would love to hear others' points of view here.
The rise of the zero trust paradigm in corporate networks probably.
Is that a Metal Gear Solid[1] reference? [1]: https://metalgear.fandom.com/wiki/Zanzibar_Land_Disturbance
https://en.wikipedia.org/wiki/Stand_on_Zanzibar
It's not the kind of literary allusion I'd want to make, if I were a global multinational like Google/Alphabet, but there it is.
I'm curious what's driving the resurgence in interest authorization infrastructure, particularly the Zanzibar paper. As founder of Oso ( https://www.osohq.com/ ), I have my own opinions, and I think this is a good thing. But would love to hear others' points of view here.
Earlier quoted context omitted.
It might be. Notice that it's only been in use for about 3 years. The difference is you don't tend to upset users due to underlying infrastructure changes.
Zanzibar has been in use for way more than 3 years. I used to work in the SRE team supporting it 7 years ago, and it already had significant users back then.
This was talked about 2 years ago on here[0]. This service was also brought up in the discussion[1] of Ory Keto, as it's based on Zanzibar. [0] https://news.ycombinator.com/item?id=20132520 [1] https://news.ycombinator.com/item?id=26738344
Airbnb Himeji also: https://medium.com/airbnb-engineering/himeji-a-scalable-cent...
Maybe a dumb question on standalone authorization services: does the authorization service end up having a representation for every single object in all of the rest of your datastores? (e.g. every document, every blob of storage, every user in every org). If so, does that become a chokepoint in a distributed microservice architecture? Or can that be avoided with an in-process or sidecar architecture in which a given…
As with everything, it depends on your requirements. Say your goal is to externalize just your authorization policies from your code. A simple implementation might look like an OPA sidecar to your services, with the policy itself being sourced from a separate control plane - this might be something as simple as a centrally-managed S3 bucket. The service implementation provides the attributes to OPA to allow it to eva…
Evaluated scenario was: a company employs a director and IT staff, the director contracts a consultant, the IT staff subscribes to external services. Find out what the company pays for directly and indirectly.
The new Keto 0.6 works very nice.
I'm just wondering if there's a one size fits all solution for authz. I spent a few days on a use case : - users have one or several roles ( these are hierarchical ) - there are some objects in the system ( hierarchical too, eg files and folders ) - there are different features available according to a user's subscription. I ended up with a 30 lines program which given a set of rules calculates who can access what in…
You are not wrong. And this pattern shows up everywhere. e.g. do you need a SaaS for "feature flags", since they're just an if statement? In the case of authz, the argument for separating it as a concern is that many applications can share the same scheme, and you can have specialized tools for provisioning, auditing, etc.
There are definitely good arguments for it, services like feature-flagging I mean, and such things are generally relatively low-cost; it's more the risk of adding a 'disappearable' dependency for anything and everything that'd put me off.
(^And if you don't know about this, OMG how can you not have heard about lucky 10k?! Just kidding. [1])
[0] - http://left-pad.io/
[1] - https://xkcd.com/1053/
I'm curious what's driving the resurgence in interest authorization infrastructure, particularly the Zanzibar paper. As founder of Oso ( https://www.osohq.com/ ), I have my own opinions, and I think this is a good thing. But would love to hear others' points of view here.
I'm just wondering if there's a one size fits all solution for authz. I spent a few days on a use case : - users have one or several roles ( these are hierarchical ) - there are some objects in the system ( hierarchical too, eg files and folders ) - there are different features available according to a user's subscription. I ended up with a 30 lines program which given a set of rules calculates who can access what in…
You are not wrong. And this pattern shows up everywhere. e.g. do you need a SaaS for "feature flags", since they're just an if statement? In the case of authz, the argument for separating it as a concern is that many applications can share the same scheme, and you can have specialized tools for provisioning, auditing, etc.
If you want the ability to remotely enable/disable a feature, then yes.
Maybe a dumb question on standalone authorization services: does the authorization service end up having a representation for every single object in all of the rest of your datastores? (e.g. every document, every blob of storage, every user in every org). If so, does that become a chokepoint in a distributed microservice architecture? Or can that be avoided with an in-process or sidecar architecture in which a given…
Each service has its own store of objects. Each store also has a directory of Metadata describing the objects contained in each service.
When you send an Auth request to a service; the service you are sending the request to looks up which service is the authority for the given object and then routes the request to that service for auth.
You can do away with the Metadata store if you offload responsibility for remembering which store to use to the user. You provide them with a cookie that tells any of your Auth servers which store contains this users data.