Roles and Permissions
TSB offers a fine grained permissions management to control access to TSB resources. You can grant access permissions to resources such as Organizations, Tenants, Workspaces, etc. A collection of permissions can be put into Roles, which can be reused to assign permissions to the appropriate resources, for example users or groups. Once you have defined the Roles, Access Binding objects can be used to bind Roles to a set of users or teams.
Resource Model
In order to understand how to work with TSB permissions, you will need to first understand how resources are modeled in TSB.
In TSB resources are modeled as a hierarchical tree, with the Organization being the root for all resources. Organizations contain one or more Clusters, Tenants, Teams, and Users. Tenants contain one or more Workspaces. Finally, Workspaces may contain one or more Gateway Groups, Traffic Groups, and Security Groups.
In this document, we will use the term Config Groups to designate all of Gateway Groups, Traffic Groups, and Security Groups
Roles
A Role is a set of permissions against specific resource(s). For example, you may create a Role which allows Read/Write permissions to a Workspace, and only Read on its parent Tenant.
Below is a list of permissions that are available:
Permission (Action) | Description |
---|---|
Read | Allows reading the resource. |
Write | Allows updating the resource. |
Create | Allows creating child resources. (*1) |
Delete | Allows deleting the resource. |
SetPolicy | Allows delegating control of the resource to other users. |
(*1) When a user creates child resources, the user is granted ownership of the newly created resources, and thus has complete control over them.
TSB comes with a few builtin Roles with a set of permissions for the most common cases:
Role | Read | Write | Create | Delete | SetPolicy |
---|---|---|---|---|---|
Admin | ✓ | ✓ | ✓ | ✓ | ✓ |
Editor |