https://authzed.com logo
Join Discord
Powered by
Modeling Google Cloud IAM in SpiceDB | A...
# spicedb
s
👋 I'm prototyping a multitenant permission system where the tenant is an organization. The permission system should allow custom roles and role bindings. I have a couple of questions: 1. is it correct to set the type of the relations of the role to be 
organization#member
? IUUC, the [Google Cloud IAM in SpiceDB blog post](https://authzed.com/blog/google-cloud-iam-modeling) makes those relationships 
user:*
because the system is not multitenant, so any role created should be available to be associated to any user in the system. In my case, the roles belong to a specific organization. 2. What's the notation that should be used in the "Test relantionships UI" for the type of 
organization#member
? in the Type field I tried 
organization
, 
organization#member
, 
account
, and in the ID field I tried 
organization:123
, 
organization:123#member
, 
organization:123#member:*
, but none of them worked.
Here's part of the schema:
Copy code
definition organization {
  relation member: account
  // Role Bindings granted on org-level
  relation role_binding: role_binding

  // Cluster
  permission cluster_create = role_binding->cluster_create
  permission cluster_read = role_binding->cluster_read
  permission cluster_update = role_binding->cluster_update
  permission cluster_delete = role_binding->cluster_delete
  permission cluster_list = role_binding->cluster_list
}

definition account {
}

definition role {
  relation organization: organization
  // Cluster
  relation cluster_create: organization#member
  relation cluster_read: organization#member
  relation cluster_update: organization#member
  relation cluster_delete: organization#member
  relation cluster_list: organization#member
}

// A role assignment binds one role to one account
definition role_binding {
  relation organization: organization
  // A role binding is bound on one side to one role
  relation role: role
  // A role binding is bound on the other side to one account
  relation account: account

  // Cluster
  permission cluster_create = account & role->cluster_create
  permission cluster_read = account & role->cluster_read
  permission cluster_update = account & role->cluster_update
  permission cluster_delete = account & role->cluster_delete
  permission cluster_list = account & role->cluster_list
}

definition cluster {
  relation organization: organization

  permission create = organization->cluster_create
  permission read = organization->cluster_read
  permission update = organization->cluster_update
  permission delete = organization->cluster_delete
  permission list = organization->cluster_list
}
j
1. yes, that is a good alternative
2. type: organization, ID: the org ID, member in the third column
s
About (2), I still don't understand how to write the Type and the ID for the role in my example
j
third column of the subject
6th column overall
aka in "Subject Relation"
s
ohh, got it! thanks
PreviousNext
Powered by