I know this has been discussed few times, but I was wondering if there is any referencial setup for SpiceDB in Istio-enabled service mesh. What we have is: 1. our service that has business logic related to permission 2. this service will be using SpiceDB for permission calculations 3. SpiceDB can be accessible only to our service, in essence other service in service mesh don't really need to know about SpiceDB (from their perspective it's an implementation detail) We are struggling a bit here with how to make this work, as we do not want to lose on the multi-pod SpiceDB deployment benefits (distributed calcuations and cache), but at the same time we need to make sure it is able to work within our cluster without issues

Hey 👋 Yeah we haven't experimented with service meshes ourselves. It kinda messes up with SpiceDB's dispatching, which does its own service discovery using the Kubernetes Endpoint API and gRPC client-side load-balancing using a custom hash-ring. So that overlaps with a bunch of what the service mesh gives you. I could see a world where this is delegated somehow to istio, but that's not going to happen without engineering. You may make it work with istio so long it does not do any load balancing / service discovery, but what does it buy you at that point? Our recommendation is to use istio between your client application and SpiceDB API, but have istio disabled for the Dispatch API.

Istio is basically a requirement, but we are trying to figure out what could be done to go around it. Eg question whether a problem is due just to TLS and istio with mTLS not working properly (we could then disable SpiceDB TLS since on communication between pod we can just rely on mTLS), or is it something deeper with discovery that will get messy. The load balancing side we can probably work around, as I know one team had custom load balancing built with istio for cache stickiness

if you are doing only mTLS, that's probably fine. I'm skeptical about load balancing being possible at the dispatch layer, it's application specific and you'd be implementing parts of SpiceDB in the istio load-balancer layer. If client-side load-balancing logic in SpiceDB changes, your implementation in istio drifts.

@vroldanbet , one more question: do I understand correctly that Dispatch API has separate port to gRPC and HTTP, so we can just disable istio on it, while leaving the rest as is? That I assume should solve the problem with inter-pod communication

that's correct. It defaults to

50053

, but you can change it with

--dispatch-cluster-addr

Additional question: Is dispatching communication encrypted by default?

not automatically in the sense that you need to specify the certs via flags:

--dispatch-cluster-tls-cert-path string                   local path to the TLS certificate used to serve dispatch
      --dispatch-cluster-tls-key-path string                    local path to the TLS key used to serve dispatch