The typical architecture is to have microservices all share one schema so that permission checks can be done for resources that a given microservice might not own themselves. You could have each service completely isolated, but you'd like end up having to duplicate relationships (e.g. user data) as you pointed out. The folks at Airbnb and Google recommend centralizing into one schema as much as possible and having fewer, ubiquitously shared definitions.

All of the GCP services implement this same API so that each service doesn't have to invent its own policy API. For example, https://github.com/googleapis/googleapis/blob/d76f26f335b2b570b7e19d938f35f9894236e565/google/genomics/v1/datasets.proto#L112 or https://github.com/googleapis/googleapis/blob/d76f26f335b2b570b7e19d938f35f9894236e565/google/spanner/admin/database/v1/spanner_database_admin.proto#L133. Anyone developing a platform with multiple gRPC services would likely need to solve this same problem.

That matches my understanding at least. I was hoping for something like hierarchical schemas or includes or something so that microservices could "deploy" updates to their service-specific definitions.

We do have a GitHub Action and CLI tools for validating schemas that you can build into your workflow for updating partial schemas on a per-service basis. I think @vroldanbet has explored a bit about breaking up their schema into pieces for different teams to manage.

If I'm understanding this correctly, this would only be if you were building an IAM service that sat in front of SpiceDB and all the applications called into that service and not SpiceDB directly, right?

Reading https://docs.authzed.com/guides/schema may I suggest that: > In Authzed, such a question is answered via use of a CheckPermission call, which takes in two objects (the resource and the subject), as well as a possible permission (or relation) between them (the permission), and returns whether the subject is reachable from the resource. should probably read: > "[...] and returns whether the resource is reachable from the subject."

I still wonder how to build scheme for something like below: I have permissions for different microservices which defined using role resource scope: ResourceA, ResourceB, ResourceC Each resource has scopes: ResourceA => ScopeA1, ScopeA2, ScopeA3 ResourceB => ScopeB1, ScopeB2 ResourceC => ScopeC1, ScopeC2 Each user has role/group and each role has access to resource-scope pairs which defined for that microservice. For example: UserA has RoleA RoleA can Access ResourceA with ScopeA1 So I can check that permission is UserA can access to ResourceA with ScopeA1 (which is true because user has role RoleA)

I think this is written to be "technically correct" as the graph traversal starts at the resource and attempts to follow relations/permissions until it finds the subject, but I'm not sure that matters from a high-level overview.

ah, "reachable" in the context of the graph. ok. But in the context of permissions, it sounds like "the resource has access to (can reach) the subject".

gRPC IAM

@emre.savci what have you tried so far?

@emre.savci maybe something like:

definition user {}

definition resource {
    relation has: scope
    permission access = has->access
}

definition role {
    relation is_in: user
    permission access = is_in
}

definition scope {
    relation has: role
    permission access = has->access
}

@emre.savci relationships:

role:role_a#is_in@user:user_a
role:role_b#is_in@user:user_b
scope:scope_a1#has@role:role_a
scope:scope_b1#has@role:role_b
resource:resource_a#has@scope:scope_a1

@emre.savci assertions:

assertTrue:
    - "resource:resource_a#access@user:user_a"
assertFalse:
    - "resource:resource_a#access@user:user_b"

Hello! Could I get some clarity on what the

--datastore-readonly

flag actually do with Postgres? What is it supposed to be used for?

Hi @williamdclt: if set, it adds an interceptor that prevents any writes to the underlying datastore

its mostly used for testing

https://github.com/authzed/spicedb/blob/94c69634c5d552fab34a9402e19973d7f68904da/internal/datastore/proxy/readonly.go#L20 if you're curious

Thank you!

can also be used if, say, you need to do a migration of your service and want all SpiceDB write ops disabled during that time

you could redeploy the cluster with that flag swt

set*

Makes sense

Hi All. I'm just starting out with SpiceDB, and have a schema that I am happy with, and can authorize my users. I want to build a simple GUI for managing users and groups. Is there a simple way of using the API to fetch the list of a given resource? Eg the list of all groups in the system, or all users. I can call

ReadRelationships

with a relationship filter that is simply the

resourceType

and then iterate over all the results to retrieve the distinct set of resources of a given type, but this seems inefficient - ie I will get one result for every 'user' even if I am only looking for the three 'group's that exist. Is there a better way that I am missing?

Now that I have written this out, I think I am doing it wrong 😊 . In my case all Groups are in the context of an owning company, so I can just add in that relationship and just query for all the groups owned by a given company (which could be effectively global). Rubber duck problem solving FTW!

> Rubber duck problem solving FTW! > 👍

are the protobuf here safe to use: https://github.com/authzed/api/tree/main/authzed/api/v1 I noticed your clients are older than the commits to the definitions

i need to generate a client in rust

yep they are safe to use

awesome, thanks!