Authorization for write permission to SpiceDb

[anuragc-arista]

Hi,
I'm new to this and would like to understand how a non-human actor can manage selective relationships and permissions.
For example, let's say a Non-Human Identity (NHI) is monitoring stream updates from an SQL database and then writing relationships to the SpiceDb. In this scenario, would the application that owns the SQL database be able to handle authorization for its own API without needing to offload data to SpiceDb?

[tstirrat15]

I'm not sure I understand the question.

If you don't want to put authorization logic into SpiceDB, you don't have to. We believe that centralizing authorization decisions brings benefits, and the relevant one for this case is that all of the logic for determining authorization decisions lives in one place, which means there's less likelihood that you miss miss something important as a result of fragmentation.

If what you're proposing makes sense for your use case, there's no reason you can't do it, though.

[anuragc-arista]

Thanks for the response!.
I'm curious about how you manage permission rules in dynamic environments. For instance, in a CI/CD setup where you need to dynamically assign permissions to ephemeral job contexts, should these capabilities (permissions) be granted by a non-human identity (NHI)? If so, how do you control and restrict what permissions this NHI can assign?

[tstirrat15]

It'd be a part of my schema just like any other. The endpoints that govern writing relationships to SpiceDB are API endpoints like any other, which is to say that they can be protected by SpiceDB and have corresponding schema.

The decision of whether to model an NHI the same as a "user" (or whatever the standard terminal subject in your system is) or as its own kind of subject is going to depend on the specifics of your system.