Allow Read-Only API in production usage.

[winstaan74]

Problem Statement

We have a use case where a single service writes relationships to SpiceDB, but other services will be calling SpiceDB to checkPermissions.

The serve-testing mode provides a read-only API on a different port.

I'd like to propose an option to enable the read-only API in the production serve mode.

If this was available then network policies, etc could be used to ensure that services that should only be checking permissions could never accidentally write to SpiceDB.

Solution Brainstorm

No response

[vroldanbet]

@winstaan74 spicedb serve offers --datastore-readonly. Does that not work for you?

[winstaan74]

Hey @vroldanbet !. I don't think --datstore-readonly is what I need - because as far as I understand it makes the entire datastore readonly.

I'd still like to have single privileged service writing relationships - but would like to ensure other services can't accidently trample the relationships.

[vroldanbet]

@winstaan74 got it. As a workaround for now, you could have 2 clusters using the same datastore. One handles writes, and the other one has --datastore-readonly enabled.

So if I understand correctly, you'd like to see the API exposed in two different ports, one that has write access, and another that is readonly, correct?

[winstaan74]

Ohh 2 clusters - ok. interesting tip. thanks.

Yep - two different ports was what I was thinking - inspired by the serve-testing setup. but maybe separate clusters solves the problem already.

[josephschorr]

Separate clusters also allows for different preshared keys to be used, so you can have a "read only" key

[josephschorr]

@winstaan74 Also, AuthZed's paid offering provides support for https://authzed.com/docs/spicedb-dedicated/fgam, which allows for very specific permissions on the tokens calling into SpiceDB Enterprise

[winstaan74]

Thanks for the pointers to alternatives - I'll close this ticket.

[josephschorr]

@winstaan74 Let us know if the separate clusters doesn't work for some reason; if not, we can investigate exposing the readonly endpoint at its own endpoint via serve, perhaps with its own configured preshared key(s)

[epbensimpson]

@winstaan74 Let us know if the separate clusters doesn't work for some reason; if not, we can investigate exposing the readonly endpoint at its own endpoint via serve, perhaps with its own configured preshared key(s)

+1 to the idea of allowing readonly endpoint/key(s) with a single cluster. We have a similar setup to OP and I suspect this will be a fairly common pattern for others self-hosting SpiceDB. While the multiple cluster setup would work it does add complexity/cost.