https://authzed.com logo
Join Discord
Powered by
Our API is a Developer Platform, where
# spicedb
s
Our API is a Developer Platform, where we are trying to create opinionated ways to manage our internal infrastructure. So I'm the consumer of spicedb, and am trying to give users using the platform the ability to create permissions*. I figured I'd try just doing a simple schema around CRUD'ing DNS Records and Zones.
y
yup, that makes sense.
per your previous question, i wouldn't expose SpiceDB or a wrapping API directly to users
it'd be calls to SpiceDB inside of the API that's doing the business logic
like you'd have 
/accounts/<id>/users POST
for example
and that API is going to do some authentication, check to make sure the user is allowed to do that thing, add the associated data to your application datastore, and then tell SpiceDB "hey, this user is associated with this account"
s
So my API will have to allow the account owner to give user "tom" access to edit dns_record webapi.example.com
Or add him to a "group" that has edit to dns_record webapi.example.com
y
sure
s
That state is stored in SpiceDB right?
y
it depends - some data can be primarily stored in SpiceDB, other data i wouldn't recommend it
the big thing is that SpiceDB is very well optimized for asking authorization questions and is pretty poor at normal CRUDish operations (like getting a sorted, filtered list of groups)
at my previous company, we had a normal CRUD service backed by a Postgres database that held the lists of user role assignments, because our product people wanted to be able to have a paginated, tabular view of role assignments that a user had
we previously tried to store it all in SpiceDB but the performance was bad (because we had to do manual graph walks) and we couldn't do sorting or filtering or pagination very easily (partially because of those aforementioned graph walks)
but if the data in question is just the relationships between entities, SpiceDB can do that pretty well
s
So storing policy should be kept external, and only relationships kept in spicedb. Did you do ABAC, use a certain RBAC language to expose to users. Trying to wonder if I should go down the path of using IAM style rules or some kind of syntax that can be parsed. Don't have much experience here
In the past I'd usually just shove a bunch of groups into a jwt token. $account:$subject:$role so...... temablue:dns_records:writer and parse that from the token and handle it in an authorize endpoint
but I'm trying to learn about these newer authz systems....
So if my account owner user created a group within our API and that is stored in psql outside of spicedb, and he put a few users in there.... I'd have to also create the appropriate relationships of those memberships in spicedb also or how would spice db have the information to make the appropriate approve /deny ?
The issue that you're warning me about is that querying spicedb for who is a member of what group constantly is expensive, and not very performant
So 2 phase commits, and keeping them in sync seems like a fun time
y
yeah, that's one of the biggest issues with using an external service for authorization
s
y
yep
s
We use temporal to manage our workflows, so keeping them in sync with sagas shouldnt be the end of the world
y
not necessarily - my example may have been a bit misleading. it was more about how storing and managing representations of auth-related stuff might make sense to do outside of spicedb.
that makes sense on the face of it
yes, you'd need to sync those
this is also an "it depends" - it depends on the schema and it depends on how you're querying it
and as for the authorization model, spicedb is ReBAC + ABAC, and you can model other systems in it (such as RBAC)
s
ok, this seems doable, I'm still a little unsure of how to expose the application of permissions to the user
most are familiar with AWS IAM, so parsing that json and taking the appropiate actions doesn't seem like a bad idea, unless you have some suggestions?
y
yeah... in our case it got hairy because 1. the "roles" that we wanted to show to the user were actually the materialization of three different unrelated relations that you needed to walk between and 2. there were potentially lots and lots of roles associated with a given organization
if you don't have those constraints it might be nicer
i'd start with getting a sense of what your schema might look like
> parsing that json and taking the appropiate actions what do you mean by that?
s
well, within the API / UI users will be able to define what policy they want.
y
and re: iam, the model we used at my old company was pretty similar to this one: https://authzed.com/blog/google-cloud-iam-modeling
which might be a good starting point for you
ah, gotcha
yeah, you could definitely do that
s
or do you think just having them write the permissions via the spicedb schema syntax?
y
so you wouldn't be exposing schema to your users
s
I dont know the anme of it in the UI where you define the input data with #'s etc
lol
y
ohhh
gotcha
uhhh yeah i don't know that we have an official name for it either
"tuple" syntax, maybe?
s
"resource:someresource#write@user:anotherguy"
y
yaeh
and yeah, i think that'd be a design/product question
s
like should they just write a list of assertions and store them in an array to be applied
fun fun fun
y
i think that's possible but i'm not sure i'd recommend it
s
Yea, seems a bit rich
11 Views
PreviousNext
Powered by