4 ms·

Forget about 8B people in this context. If you have 1000 microservices in the company and each has 100 rps, you are looking at ca. 100k rps to a Zanzibar-style

Forget about 8B people in this context. If you have 1000 microservices in the company and each has 100 rps, you are looking at ca. 100k rps to a Zanzibar-style system to authorize every request (not to authenticate a user).

comboy 3y ago
Thanks.
dietr1ch 3y ago
Why does it need to be checked on a per-request level? I'd expect you to be able to give short-lived capability tokens to clients that each machine can verify down the stack without making new rpcs. This would avoid the fan-out of all the internal services. Is it just to prevent abuse?
- AlphaSite 3y ago
  Does the token identify every resource you have access to? I think is for multi tenant applications with fine grained access control.
- paulddraper 3y ago
  "Oh, you just [insert complex solution here]" You need one capability token per principal and resource and perhaps access right.
- akajla 3y ago
  You can encode capabilities/permissions as scopes in distributed tokens (e.g. OAuth) but this can start to break down if you have very granular, fine-grained permissions (e.g. user:1 has 'editor' access to 1000s of documents/objects). This is similar to the problem that Carta ran into while building out their permissions[1]. In addition, yes - validating permissions on each request makes it so that you can revoke privilege(s) with immediate effect without needing a token to be invalidated. [1] https://medium.com/building-carta/authz-cartas-highly-scalable-permissions-system-782a7f2c840f https://medium.com/building-carta/authz-cartas-highly-scalab...
  - deleted 3y ago
    [deleted]
- smarx007 3y ago
  I think it's best to refer to the Zanzibar paper: https://www.usenix.org/system/files/atc19-pang.pdf https://www.usenix.org/system/files/atc19-pang.pdf
  - zcw100 3y ago
    ... or the annotated one from the Authzed folks https://authzed.com/zanzibar https://authzed.com/zanzibar
    - smarx007 3y ago
      Wow, I am also impressed by the tech behind! https://github.com/authzed/zanzibar-annotated https://github.com/authzed/zanzibar-annotated
    - dietr1ch 3y ago
      That's neat! All papers should allow this discussion on them. BTW, didn't Google released something like it too early?
mort96 3y ago
This isn't meant to invalidate what you're saying, but this whole thread reads like a parody to me. 1000 services all making requests to Zanzibar, and this oreo keto thing. Makes me think of this: https://m.youtube.com/watch?v=y8OnoxKotPQ https://m.youtube.com/watch?v=y8OnoxKotPQ
- smarx007 3y ago
  Pure gold.
- sporkland 3y ago
  You could apply to S3, RDS, BigTable, Spanner, Firestore, etc. I feel like engineer orthodoxy (monoliths vs microservices, every monolith I've seen accesses a remotely DB and every microservice tends to access a DB which are themselves monoliths), no "god" services tend to break down for a lot of these important high scale stateful facilities.

comboy 3y ago

Thanks.

dietr1ch 3y ago

Why does it need to be checked on a per-request level? I'd expect you to be able to give short-lived capability tokens to clients that each machine can verify down the stack without making new rpcs. This would avoid the fan-out of all the internal services. Is it just to prevent abuse?

AlphaSite 3y ago
Does the token identify every resource you have access to? I think is for multi tenant applications with fine grained access control.
paulddraper 3y ago
"Oh, you just [insert complex solution here]" You need one capability token per principal and resource and perhaps access right.
akajla 3y ago
You can encode capabilities/permissions as scopes in distributed tokens (e.g. OAuth) but this can start to break down if you have very granular, fine-grained permissions (e.g. user:1 has 'editor' access to 1000s of documents/objects). This is similar to the problem that Carta ran into while building out their permissions[1]. In addition, yes - validating permissions on each request makes it so that you can revoke privilege(s) with immediate effect without needing a token to be invalidated. [1] https://medium.com/building-carta/authz-cartas-highly-scalable-permissions-system-782a7f2c840f https://medium.com/building-carta/authz-cartas-highly-scalab...
- deleted 3y ago
  [deleted]
smarx007 3y ago
I think it's best to refer to the Zanzibar paper: https://www.usenix.org/system/files/atc19-pang.pdf https://www.usenix.org/system/files/atc19-pang.pdf
- zcw100 3y ago
  ... or the annotated one from the Authzed folks https://authzed.com/zanzibar https://authzed.com/zanzibar
  - smarx007 3y ago
    Wow, I am also impressed by the tech behind! https://github.com/authzed/zanzibar-annotated https://github.com/authzed/zanzibar-annotated
  - dietr1ch 3y ago
    That's neat! All papers should allow this discussion on them. BTW, didn't Google released something like it too early?

mort96 3y ago

This isn't meant to invalidate what you're saying, but this whole thread reads like a parody to me. 1000 services all making requests to Zanzibar, and this oreo keto thing. Makes me think of this: https://m.youtube.com/watch?v=y8OnoxKotPQ https://m.youtube.com/watch?v=y8OnoxKotPQ

smarx007 3y ago
Pure gold.
sporkland 3y ago
You could apply to S3, RDS, BigTable, Spanner, Firestore, etc. I feel like engineer orthodoxy (monoliths vs microservices, every monolith I've seen accesses a remotely DB and every microservice tends to access a DB which are themselves monoliths), no "god" services tend to break down for a lot of these important high scale stateful facilities.