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.
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.
:::note In this document, the term Config Groups is used to designate all of Gateway Groups, Traffic Groups, and Security Groups. :::
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:
||Allows reading the resource.|
||Allows updating the resource.|
||Allows creating child resources. (*1)|
||Allows deleting the resource.|
||Allows delegating control of the resource to other users.|
TSB comes with a few builtin Roles with a set of permissions for the most common cases:
Editor roles are intended to give ownership (full control) of a resource tree. But while the
Admin role is intended for system administrators, the
Editor role is intended for users or teams who own the resource tree alone.
Creator role is intended for users that can create their own resources and see other resources. For example, a user with a
Creator role may read all resources within a Workspace including resources that were created by others, but has complete ownership of resources that they have created within that Workspace.
By contrast the
Writer role only allows users to read and modify existing resources, but does not allow creation of new resources.
Reader role allows users to only read existing resources. They will not be able to do anything else with it.
In TSB, Access Binding objects define the binding between a set of roles to a set of users or teams for a specific TSB resource. Example of
AccessBinding is shown below. You need to use FQN when specifying target resource, role, users and teams.
apiVersion: rbac.tsb.tetrate.io/v2 kind: AccessBindings metadata: fqn: organizations/myorg/tenants/mytenant/workspaces/w1 spec: allow: - role: rbac/admin subjects: - user: organizations/myorg/users/alice - team: organizations/myorg/teams/platform-team - serviceAccount: organizations/myorg/serviceaccounts/sa
The Roles define the set of permissions against resource(s), and the Access Bindings define the Roles that are associated with a set of users/teams for a particular resource. As team members may be changed dynamically much more easily, in general it is recommended that you assign permissions to teams rather than users, so that you have greater flexibility.
:::warning TSB will automatically create an Access Binding object for any of the above resources when a new resource is created. This Access Binding will set whoever user that created the resource as admin.
For example, if you create a Tenant, TSB will create a
AccessBindings that sets you as the admin for the tenant.
Do NOT create new Access Binding if you want to grant permissions to your team because you will overwrite automatically created one. To make sure that you do not accidentally overwrite automatically created Access Bindings, first fetch the target Access Binding
tctl get, edit the necessary portions, then apply using
Fully Qualified Names
In order to unambiguously define a resource, each resource has a fully qualified names (FQN) that that describes their location in the resource hierarchy. These are used in the object definitions that you will be using in the examples.
The following shows the naming patterns used for each of the resources.
|Istio Internal Group||
Working With Roles and Permissions
When you first install TSB, you will be using the platform administrator account which has super admin privileges. You do not want to let other members of your organization use TSB with this account for obvious reasons. You should either create new users and teams or use the ones imported from your IdP (Identity Provider) e.g LDAP, Azure AD or others.
In this section you will learn about a common scenario assigning roles and permissions to your teams. For demonstration purposes the examples will be executed through the command line using
tctl, but you can configure TSB through the Web UI just the same.
For this example, please assume that you would like to configure TSB with the following teams and respective settings:
|Platform Team||Members act as Organization administrators. They can create Tenants, Workspaces, Config Groups, and grant access to these resources to specific teams|
|App Team||Members are able to configure their applications that run in specific namespaces. Specifically, they own a specific Traffic Group in the Workspace that they work on.|
|Security Team||Members are able to read everything under a Tenant, and configure Security Group settings in the Workspaces.|
The example will walk you through how to configure the permissions in iterative steps. You will need to go through all of the steps below to achieve the desired state.
Please assume that the Tenants, Workspaces, Config Groups, Users and Teams that are mentioned in this example have already been created. Also, please note that this is not the only way to achieve the same effect. Certain combinations of roles, permissions, and bindings that satisfy the above will probably exist.
Notes on Working with Access Bindings
In the examples below, make sure to use existing access binding objects instead of creating new ones. There exists exactly one access binding for each resource. If you create new binding objects, you will effectively be overwriting the existing one, and in most cases you should avoid doing this.
Instead, when you are instructed to edit an access biding in the following examples, make sure to
tctl get the binding first, make the edit, and then apply it using
For example if you are working with organization
AccessBindings, get the existing bindings first:
tctl get accessbindings organizations/myorg -o yaml > bindings.yaml
Then after you make the edits, apply the bindings:
tctl apply -f bindings -o yaml > bindings.yaml
AccessBindings for a tenant, you would use
tctl get accessbindings organizations/myorg/tenants/tenant1 -o yaml. For other resources down in the hierarchy, you will need to provide correct FQN.
Configuring the Platform Team
As the super admin user you will have to create the Platform team before doing anything. Grant the Platform team with the Admin role on the necessary resources.
In this example the Platform team is given Admin role on the a specific organization
myorg. Retrieve the organization
AccessBindings and add the platform team (
apiVersion: rbac.tsb.tetrate.io/v2 kind: AccessBindings metadata: fqn: organizations/myorg spec: allow: - role: rbac/admin subjects: - team: organizations/myorg/teams/platform ...
Apply the above using
tctl apply -f.
The rest of the examples assume that the above Platform team has prepared all of the necessary resources for the configuration to proceed.
Configuring for App Team and Workspaces
The app team should be able to view the resources in the
Tenant, as well be able to create Config Groups within a Workspace, but nothing more. In this and the rest of examples the tenant name is assumed to be
To grant the team read access to the Tenant, retrieve
AccessBindings object for the intended tenant, and add the app team as a reader:
apiVersion: rbac.tsb.tetrate.io/v2 kind: AccessBindings metadata: fqn: organizations/myorg/tenants/tenant1 spec: allow: - role: rbac/reader subjects: - team: organizations/myorg/teams/app ...
To grant the team create access to the Workspace, retrieve the
AccessBindings object for the intended workspace, and add the app team as a creator:
apiVersion: rbac.tsb.tetrate.io/v2 kind: AccessBindings metadata: fqn: organizations/myorg/tenants/tenant1/workspaces/w1 spec: allow: - role: rbac/creator subjects: - team: organizations/myorg/teams/app
Then apply these configurations using
tctl apply -f.
Configuring for Security Team and Config Groups
In previous sections it was stated that the App team should only have access to specific Traffic Groups. However, since the previous workspace
AccessBindings definition granted the Creator role to the App team, they will be able to create new Config Groups as they please.
In next scenario the Platform team wants to restrict the App team to own a specific Traffic group that the Platform team has created for them.
Furthermore, the Security team should have similar permissions on a specific Security Group that the Platform team has created.
To achieve this, retrieve the
AccessBindings for the intended tenant again, and add the security team as a reader so that they can read the tenant information. Make sure to leave the app team in there as well.
apiVersion: rbac.tsb.tetrate.io/v2 kind: AccessBindings metadata: fqn: organizations/myorg/tenants/tenant1 spec: allow: - role: rbac/reader subjects: - team: organizations/myorg/teams/security ...
AccessBindings for the intended workspace again. This time remove the app team from the creator role, and add the app team and the security team as readers of the Workspace.
apiVersion: rbac.tsb.tetrate.io/v2 kind: AccessBindings metadata: fqn: organizations/myorg/tenants/tenant1/workspaces/w1 spec: allow: - role: rbac/reader subjects: - team: organizations/myorg/teams/app - team: organizations/myorg/teams/security ...
AccessBindings for the intended
TrafficGroup, and add the app team as a creator. The
TrafficGroup is assumed to have been created by the platform team.
apiVersion: rbac.tsb.tetrate.io/v2 kind: AccessBindings metadata: fqn: organizations/myorg/tenants/tenant1/workspaces/w1/trafficgroups/t1 spec: allow: - role: rbac/creator subjects: - team: organizations/myorg/teams/app ...
Similarly retrieve and edit
AccessBindings for the intended
SecurityGroup, and add the security team as a creator. The
SecurityGroup is assumed to have been created by the platform team.
apiVersion: rbac.tsb.tetrate.io/v2 kind: AccessBindings metadata: fqn: organizations/myorg/tenants/tenant1/workspaces/w1/securitygroups/s1 spec: allow: - role: rbac/creator subjects: - team: organizations/myorg/teams/security ...
Apply these objects using
tctl apply -f.
Once everything is successfully applied, you should have TSB in the desired configuration.