Management API #58
Management API #58
Conversation
|
@jnschaeffer in the PR defining the terminology we had agreed to use "Role assignments", what do you think about renaming I'm also open to renaming the concept to be a membership, but then lets rename that throughout the repo and docs. |
|
@jnschaeffer can you be a little more explicit about the user flows that this is covering? Mostly I'm struggling to understand how this would look for an admin in terms of effectively creating and assigning a role. Do they also have to explicitly create a relationship? Or is that process meant to be automated elsewhere? |
We should stick with the terms we already defined; I'll update the PR accordingly.
Sure thing. Would you prefer that in the README or some other documentation in the repo? |
jnschaeffer
force-pushed
the
management-api
branch
2 times, most recently
from
fea3f64
to
7d687c8
Compare
This commit introduces the start of a management API for permissions-api based on the following resource types: * Role: A collection of actions scoped to a resource * Relationship: A named link between two resources * Membership: A link between a role and a subject Currently only POST is implemented for these resources. Future commits will implement other methods (GET, PATCH, DELETE) as needed. Signed-off-by: John Schaeffer <[email protected]>
SpiceDB's (and Zanzibar's) notion of resource and subject are the inverse of what one would typically think of, especially when looking at schema definitions. This commit updates the relationships API to allow for the definition of relationships for multiple subjects on a single resource, which matches schemas and resources as defined more closely. Signed-off-by: John Schaeffer <[email protected]>
Signed-off-by: John Schaeffer <[email protected]>
Assignments is the term we use elsewhere when describing the relationship between a subject and a role. This commit replaces usage of the word "membership" with "assignment" accordingly. Signed-off-by: John Schaeffer <[email protected]>
Signed-off-by: John Schaeffer <[email protected]>
Signed-off-by: John Schaeffer <[email protected]>
Signed-off-by: John Schaeffer <[email protected]>
Signed-off-by: John Schaeffer <[email protected]>
Signed-off-by: John Schaeffer <[email protected]>
Signed-off-by: John Schaeffer <[email protected]>
Signed-off-by: John Schaeffer <[email protected]>
Signed-off-by: John Schaeffer <[email protected]>
Signed-off-by: John Schaeffer <[email protected]>
Signed-off-by: John Schaeffer <[email protected]>
jnschaeffer
force-pushed
the
management-api
branch
from
e70af36
to
b457620
Compare
|
@jnschaeffer thanks for addressing the comments, let me know when it's ready for review |
Signed-off-by: John Schaeffer <[email protected]>
Signed-off-by: John Schaeffer <[email protected]>
Signed-off-by: John Schaeffer <[email protected]>
Signed-off-by: John Schaeffer <[email protected]>
For testing purposes, it's easier if schema updates don't delete everything in SpiceDB. This commit sets the flag necessary to do append-only schema updates in SpiceDB. Signed-off-by: John Schaeffer <[email protected]>
Signed-off-by: John Schaeffer <[email protected]>
|
|
||
| ``` | ||
| $ curl --oauth2-bearer "$AUTH_TOKEN" \ | ||
| -d '{"actions": ["loadbalancer_create"]}' \ |
There was a problem hiding this comment.
They should, but SpiceDB doesn't have a notion of a resource that we can give names, create/update times, etc to. That will have to come as part of a subsequent set of PRs that add a separate set of tables for tracking that information.
| } | ||
|
|
||
| resp := createAssignmentResponse{ | ||
| Success: true, |
There was a problem hiding this comment.
is it useful to return the assignment id here?
There was a problem hiding this comment.
There's no assignment ID as such. Assignments are relationships, and the entire (resource, relation, subject) tuple effectively is the identifier for a relationship, where SpiceDB only really supports querying for sets of relationships by certain criteria.
In other words, rather than saying "delete assignment $UUID", you say "delete all relationships with a resource of x, a relation of y, and (maybe) a subject resource of z".
This PR introduces the start of a management API for permissions-api based on the following resource types:
POST and GET are implemented for these resources. Future PRs will implement other methods (PATCH, DELETE) as needed.