Customizing Ory Keto with global-scale data sharing requirements
summary
Deep code dive of an implemented stack: Ory Keto + Oathkeeper fronted by a Google LB and emissary ingress, Hydra/Kratos for auth, gRPC-web translating to gRPC, GKE + Argo + Terraform Cloud for infra. An internal authorizer performs Zanzibar-style expansion to keep tuples out of Keto, adding interceptors that cost ~0.02 ms each and an authorization check that runs ~25–55 ms validation per query. Client latency targets hit page loads of ~250–350 ms; proto-serialized requests ~67 ms and HTTP/3 gives ~27–28% gain over HTTP/2. Server streams are fragile (100-connection limits), so unary RPCs are preferred.
AI-written summary · about
chapters (9)
- 0:00Infrastructure and tooling
- 1:53Architecture design choices
- 3:36gRPC implementation details
- 5:03Authorization and security
- 8:23Zanzibar and rule management
- 10:30Implementation of specifications
- 12:52Performance and future goals
- 17:25Advice for gRPC adoption
- 19:32Scaling with terraform
related talks
25m Introducing the Ory Network
16mHow to move your RBAC into Ory 
18mMake Auth great again with Ory
18mRunning Ory on a 30M users platform
19mHow TIER IV Replaced Identity Server with Ory
34mCustomizing OPA for a "Perfect Fit" Authorization Sidecar
30mScaling the Grail – Cloud-Native Computing on Encrypted Data using Carbyne Stack
24mSecuring the digital world