Users, Roles and Permissions

Tetrate Service Bridge (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.

Following the steps mentioned in this doc will establish Role-Based Access Control (RBAC) in TSB, granting granular control over multiple users and teams based on their personas.

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.

Users, Service Accounts & Teams

In TSB, the configuration of teams and users involves defining entities such as User, ServiceAccount, and Team to facilitate access and operational control.

• Users refer to individuals who access and interact with the system.
• Service Accounts are used for automated tasks and applications, not individuals.
• Teams are collections of users and service accounts that inherit permissions from the roles assigned to them, streamlining the management of resource access based on organizational needs and security policies. Users and Service Accounts can belong to multiple teams, and teams can include multiple Teams, Users and Service Accounts.

Permissions can be assigned to teams and users through roles, allowing control over CRUD operations on TSB resources. Integration with LDAP or OIDC is supported to automatically populate user details and their team memberships.

TSB offers comprehensive user authentication capabilities through integration with various identity providers. TSB supports LDAP for user and group synchronization, allowing centralized authentication management and seamless integration with existing directory services. Additionally, it enables authentication via OpenID Connect (OIDC), which provides a secure and modern way to authenticate users using external identity providers. For environments without external identity services, TSB allows the creation of local users through Kubernetes secrets, securely managing credentials within the system.

Learn more about each authentication method at their respective documentation pages: LDAP user synchronization, OIDC configuration, and local user management.

Investigate Users, Service Account & Teams

You can get list of all users, teams and service accounts from TSB UI and tctl. Following command shows how you can use tctl to get these data.

# Set Environment Variables for the TSB Management Plane
export TSB_FQDN="<TSB_MANAGEMENT_PLANE_URL>"
export ADMIN_USERNAME="admin"
export ADMIN_PASSWORD="***"
export ORG="tetrate"

# Configure the tctl profile for the TSB Management Plane
tctl config clusters set $ORG --bridge-address $TSB_FQDN:443
tctl config users set $ORG --username $ADMIN_USERNAME --password $ADMIN_PASSWORD --org $ORG
tctl config profiles set $ORG --cluster $ORG --username $ORG
tctl config profiles set-current $ORG

# Review users
tctl get users
NAME        DISPLAY NAME                            DESCRIPTION
david       David Research Team Owner
owen        Owen Research Team Operator 
ajay        Ajay Research Backend Team
anoop       Anoop Research Backend App Team Member 

# Investigate david user, refer to sourceType.
tctl get users david -o yaml
apiVersion: api.tsb.tetrate.io/v2
kind: User
metadata:
  displayName: David Research Team Owner
  name: david
  organization: tetrate
  resourceVersion: '"6kOfkKRdz40="'
spec:
  displayName: David Research Team Owner
  etag: '"6kOfkKRdz40="'
  fqn: organizations/tetrate/users/david
  loginName: david
  sourceType: MANUAL

# Investigate service accounts
tctl get serviceaccount
NAME                                DISPLAY NAME                                           DESCRIPTION
auto-cluster-gke-us-central1-0      Cluster gke-us-central1-0 service account              This service account has ADMIN permissions to the organization
                                                                                                 It's intended to be used by the ControlPlane of this cluster.
auto-cluster-eks-us-east1-0         Cluster eks-us-east1-0 service account                 This service account has ADMIN permissions to the organization
                                                                                                 It's intended to be used by the ControlPlane of this cluster.

Investigate Teams & Associated Users

Lets examine one of the teams and its associated users.

tctl get teams
NAME                                DISPLAY NAME    DESCRIPTION
all-users                           All users       Contains all users from the organization
research-tenant-operators
research-backend-owners
research-backend-app-team
research-backend-security-owners
research-backend-security-team
research-backend-traffic-owners
research-backend-traffic-team

# `research-backend-app-team` is a user-created group that can be synchronized from an external Identity Provider (IdP). In the Tetrate ecosystem, these groups are equivalent to Teams.
tctl get teams research-backend-app-team -o yaml
apiVersion: api.tsb.tetrate.io/v2
kind: Team
metadata:
  name: research-backend-app-team
  organization: tetrate
  resourceVersion: '"lsm1qB7/Thw="'
spec:
  etag: '"lsm1qB7/Thw="'
  fqn: organizations/tetrate/teams/research-backend-app-team
  members:
  - organizations/tetrate/users/anoop
  - organizations/tetrate/users/roopa
  sourceType: LOCAL

Roles

TSB leverages roles to grant permissions to specific to users and teams. There are generic roles and persona specific roles that you can use directly. You can also create custom roles.

A Role is a named collection of permissions that can be assigned to any user or team in the system. The set of actions that can be performed by a user, such as the ability to create, delete, or update configuration will depend on the permissions associated with the user's role. Roles are global resources that are defined once. AccessBindings in each configuration group will bind a user to a specific role defined apriori.

Generic Roles

TSB comes with a few generic Roles with a set of permissions for the most common cases:

tctl get roles
NAME                 DISPLAY NAME         DESCRIPTION
admin                Admin                Admin (all) permissions across all resources
creator              Creator              Provides Read access to target resources and allows Creating child ones
writer               Writer               Read and Write permissions across all TSB Resources
editor               Editor               Edit permissions (Read, Write, Create) across all resources
reader               Reader               Read permissions across all TSB Resources
orgsync              OrgSync              Create and Write permissions on tenants, users and teams
registryreader       RegistryReader       Read permissions to registered services
registryadmin        RegistryAdmin        Create and Write permissions on registry services

• Admin and 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.
• 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.

Persona Specific Roles

TSB also comes with builtin persona specific roles tailored to common actors and their functions through out various stages of the service mesh workflow, including Platform Owners, Security Owners, App Owners and more.

tctl get roles
NAME                 DISPLAY NAME         DESCRIPTION
org-reader            OrgReader            Read permissions to the organization and organization settings
tenant-owner          TenantOwner          Platform owner for a specific tenant
tenant-reader         TenantReader         Read access to a tenant and its settings
tenant-operator       TenantOperator       Management permissions for a concrete tenant
workspace-owner       WorkspaceOwner       Owner for workspaces of a particular tenant
workspace-operator    WorkspaceOperator    Management permissions on a particular workspace
traffic-owner         TrafficOwner         API Platform/API Gateway owner to configure Tier1 and shared gateways, and the TrafficSettings around them
traffic-operator      TrafficOperator      Configure Ingress Gateway, Application, APIs and the TrafficSettings around them under a particular workspace
traffic-viewer        TrafficViewer        View Ingress Gateway, Application, APIs and the TrafficSettings around them under a particular workspace
security-owner        SecurityOwner        Organization-wide security settings owner
security-operator     SecurityOperator     Manage security policies for a particular workspace
security-viewer       SecurityViewer       View security policies for a ser of workspaces/tenants

Access Bindings

Access Binding is an assignment of roles to a set of users or teams to access resources. The user or team information is obtained from an user directory (such an LDAP server or an external OIDC server) that should have been configured as part of installation.

Who can create?

Access Binding can be created or modified only by users who have SET_POLICY permission on the target resource.

tctl get accessbindings organizations/tetrate/tenants/research/workspaces/research-backend-ws -o yaml

apiVersion: rbac.tsb.tetrate.io/v2
kind: AccessBindings
metadata:
  fqn: organizations/tetrate/tenants/research/workspaces/research-backend-ws
spec:
  allow:
  - role: rbac/trafficowner
    subjects:
    - team: organizations/tetrate/teams/research-backend-traffic-owners
  - role: rbac/workspaceoperator
    subjects:
    - team: organizations/tetrate/teams/research-backend-app-team
  - role: rbac/securityowner
    subjects:
    - team: organizations/tetrate/teams/research-backend-security-owners

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.

Working With TSB Persona Specific Roles and Permissions

In this section, you will learn about how persona specific TSB roles can simplify user onboarding and access management to TSB resources in mesh environment based on common teams like Platform Teams/App Teams/Security Teams/API Platform Team and more.

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.

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.

Use Case

Assume you have a multi-tenant system where each control-plane cluster is shared among multiple teams from different business units. Each team has multiple groups with varying levels of access to TSB resources based on roles such as Team Owner, App Owner, Security Owner, etc. Each team also wants to set up their onboarding workflow in a delegated fashion.

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 as shown below.

Setup User Access for Tenants

In TSB, Tenant represents a Business Unit or a Team. In a scenario where every Business Unit have a dedicated Platform Team or Team Owner who onboards other team members and configures their access, Tenant Owner and Tenant Operator Roles can be used to configure the user onboarding workflow.

Create AccessBinding to map Business Unit Head or Team Owner to TSB Tenant Owner role.

cat <<EOF | tctl apply -f -
---
apiVersion: rbac.tsb.tetrate.io/v2
kind: AccessBindings
metadata:
  fqn: organizations/tetrate
spec:
  allow:
  - role: rbac/tenant-owner
    subjects:
    - user: organizations/tetrate/users/david
    - team: organizations/tetrate/teams/research-platform-team
EOF

Verification

Delegate Tenant Management

Once the Tenant Owner is onboarded into TSB Platform, they can create Tenant resources and they automatically becomes the owner of it. Tenant Owner can then onboard set of users and teams under them to delegate the management of Tenant and other resources down below.

Create AccessBinding to map individual users or teams under research Tenant using Tenant Operator role to enable the team members to manage TSB resources under research Tenant.

cat <<EOF | tctl apply -f - 
apiVersion: rbac.tsb.tetrate.io/v2
kind: AccessBindings
metadata:
  fqn: organizations/tetrate/tenants/research
spec:
  allow:
  - role: rbac/tenant-operator
    subjects:
    - team: organizations/tetrate/teams/research-tenant-operators
EOF

Verification

Setup User Access for Workspace

A Workspace represents a logical grouping of clusters/namespaces owned and managed by an Application Owner. The Application Owner decides which cluster/namespace the application should be deployed to and creates the Workspace with the appropriate namespace selection. This Workspace can then be delegated to multiple users such as App developers under the role of Workspace Operator role, allowing them to manage TSB resources such as Groups and Settings within the Workspace.

Create AccessBinding to map Application Owner to TSB Workspace Owner role.

cat <<EOF | tctl apply -f -
apiVersion: rbac.tsb.tetrate.io/v2
kind: AccessBindings
metadata:
  fqn: organizations/tetrate/tenants/research
spec:
  allow:
  - role: rbac/tenant-operator
    subjects:
    - team: organizations/tetrate/teams/research-tenant-operators
  - role: rbac/workspace-owner
    subjects:
    - team: organizations/tetrate/teams/research-backend-owners
EOF

Verification

Delegate Workspace Management

Once the Workspace Owner is onboarded into TSB Platform, they can create Workspace resources with the required cluster/namespace selection. Workspace Owner can then onboard set of users and teams under them to delegate the management of Workspace and other resources down below.

Login as Workspace Owner and then create a new Workspace research-backend-ws under research Tenant.

tctl login
Organization: tetrate
Tenant: research
Username: ajay
Password: 

Login Successful!
  Configured user: tetrate-ajay
  User "tetrate-ajay" enabled in profile: tetrate

tctl whoami
LOGIN NAME    DISPLAY NAME                      ORGANIZATION             TYPE
ajay          Ajay research backend ws owner    organizations/tetrate    USER

Create Workspace

cat <<EOF | tctl apply -f -
apiVersion: api.tsb.tetrate.io/v2
kind: Workspace
metadata:
  organization: tetrate
  tenant: research
  name: research-backend-ws
spec:
  namespaceSelector:
    names:
      - "*/research-backend"
EOF

Delegate management of research-backend-ws Workspace to Workspace Operators by creating the access-binding to map application team users to TSB Workspace Operator role.

cat <<EOF | tctl apply -f -
apiVersion: rbac.tsb.tetrate.io/v2
kind: AccessBindings
metadata:
  fqn: organizations/tetrate/tenants/research/workspaces/research-backend-ws
spec:
  allow:
  - role: rbac/workspace-operator
    subjects:
    - team: organizations/tetrate/teams/research-backend-app-team
EOF

Verification

Setup User Access for Security Users

Management of Security related configurations under a workspace can be delegated to dedicated Security team by mapping the users to Security Owner or Security Operator

In this scenario, to create and manage TSB Security Groups under the workspace research-backend-ws that we created in the above step, a user who belong to the security team can be onboarded as Security Owner into TSB.

cat <<EOF | tctl apply -f -
apiVersion: rbac.tsb.tetrate.io/v2
kind: AccessBindings
metadata:
  fqn: organizations/tetrate/tenants/research/workspaces/research-backend-ws
spec:
  allow:
  - role: rbac/workspace-operator
    subjects:
    - team: organizations/tetrate/teams/research-backend-app-team
  - role: rbac/security-owner
    subjects:
    - team: organizations/tetrate/teams/research-backend-security-owners
EOF

Verification

Delegate Security Group Management

Once the Security Owner is onboarded into TSB Platform, they can create new Security Group resources under the Workspace & Tenant that they have assigned to. Once the Security Group is created, management of Security Group and the resources under Security Group like Security Setting and Service Security Setting can be delegated to Security Operator.

cat <<EOF | tctl apply -f -
apiVersion: rbac.tsb.tetrate.io/v2
kind: AccessBindings
metadata:
  fqn: organizations/tetrate/tenants/research/workspaces/research-backend-ws/securitygroups/research-backend-sg
spec:
  allow:
  - role: rbac/security-operator
    subjects:
    - team: organizations/tetrate/teams/research-backend-security-team
EOF

Verification

Setup User Access for Gateway/Traffic Users

Management of Gateway/Traffic related configurations under a workspace can be delegated to dedicated Traffic team by mapping the users to Traffic Owner or Traffic Operator

In this scenario, to create and manage TSB Traffic Groups under the workspace research-backend-ws that we created in the above step, a user who belong to the traffic team can be onboarded as Traffic Owner into TSB.

cat <<EOF | tctl apply -f -
apiVersion: rbac.tsb.tetrate.io/v2
kind: AccessBindings
metadata:
  fqn: organizations/tetrate/tenants/research/workspaces/research-backend-ws
spec:
  allow:
  - role: rbac/workspace-operator
    subjects:
    - team: organizations/tetrate/teams/research-backend-app-team
  - role: rbac/security-owner
    subjects:
    - team: organizations/tetrate/teams/research-backend-security-owners
  - role: rbac/traffic-owner
    subjects:
    - team: organizations/tetrate/teams/research-backend-traffic-owners
EOF

Verification

Delegate Traffic Group Management

Once the Traffic Owner is onboarded into TSB Platform, they can create new Traffic Group and Gateway resources under the Workspace & Tenant that they have assigned to. Once the Traffic Group & Gateway objects are created, management of Traffic Group and the resources under Traffic Group like Traffic Setting and Service Traffic Setting can be delegated to Traffic Operator.

cat <<EOF | tctl apply -f -
apiVersion: rbac.tsb.tetrate.io/v2
kind: AccessBindings
metadata:
  fqn: organizations/tetrate/tenants/research/workspaces/research-backend-ws/trafficgroups/research-backend-tg
spec:
  allow:
  - role: rbac/traffic-operator
    subjects:
    - team: organizations/tetrate/teams/research-backend-traffic-team
EOF

Verification