App Owner Permissions

Platform Team assigns Permissions to App Owners

This content is a reference for the Platform Team, who will onboard App Owners to the Tetrate Platform and assign them appropriate permissions

Application Owners require certain permissions in the Tetrate Platform in order to troubleshoot effectively. This doc outlines the basic permissions required to give read-only access to resources in a Workspace.

Tetrate Platform Workspaces

Workspaces are the core RBAC resource used by the Tetrate Platform.

A Workspace is a configuration container for a set of Kubernetes namespaces across one or more Kubernetes clusters. Typically, an application and the components that it exclusively needs (i.e., that are not shared) would be deployed in the namespaces in a Workspace, and the following default settings would be applied:

• An Application Owner role would be given read-only or read-write access to the Tetrate configuration for resources in that Workspace
• An Application Owner role would be given access to the observability data (metrics, traces, etc) for resources in that Workspace
• The Tetrate mesh would be configured to allow traffic between services in that Workspace, but not allow traffic to services from outside that Workspace
• An Application (or Tier2) Gateway would be deployed within that workspace, and would be used to manage ingress traffic to services within the Workspace

Tetrate Platform Users

The Tetrate Platform supports a range of user types:

• Local user accounts are stored in the Tetrate Management Plane; the global admin user is stored here
• Synchronized user accounts are acquired from an external LDAP or similar IdP, using the Tetrate teamsync process (LDAP, AzureAD, PingAM) or OIDC integration
• Service Accounts are used for internal purposes, such as managing configuration provided via GitOps

Typically, human users are assigned to Teams, and Teams are granted permissions to resources by way of AccessBindings.

In the following instructions, we will:

• Begin with a organization tetrate and tenant default
• Provision two built-in users (owen and jack). This process could be modified if you use synchronized user accounts
• Assign these users to a bookinfo-app-owners team. This process could be inferred from the LDAP group membership if you use synchronized user accounts
• Grant the team access to a minimal set of Tetrate resources, anchored at the bookinfo-ws workspace. This process is common for all user types

Workflow

1. Provision Local Users

   For full details, refer to the Tetrate Platform Documentation.

   Alternatively, you can use user accounts synchronized from an IdP

   This process is provided for reference, and may be used in a development environment. A production Tetrate deployment will likely use an external IdP.

   Create the Users

   Provision Users 'owen' and 'jack'

   ORG=tetrate
   
   cat <<EOF | tctl apply -f -
   apiVersion: api.tsb.tetrate.io/v2
   kind: User
   metadata:
     organization: ${ORG}
     name: owen
   spec:
     displayName: Owen
     loginName: owen
     sourceType: MANUAL
   ---
   apiVersion: api.tsb.tetrate.io/v2
   kind: User
   metadata:
     organization: ${ORG}
     name: jack
   spec:
     displayName: Jack
     loginName: jack
     sourceType: MANUAL
   EOF

   Assign Passwords

   First-time user assignment

   user=owen
   pass=password
   sha1=$(echo -n $pass | shasum -a 256 | awk '{print $1}')
   kubectl -n tsb create secret generic local-user-credentials --from-literal=$user=$sha1 --dry-run=client -o yaml
   
   # apply the change by omitting the --dry-run option
   kubectl -n tsb create secret generic local-user-credentials --from-literal=$user=$sha1 --dry-run=client -o yaml

   Additional user/password pairs need to patch the local-user-credentials resource:

   Additional user assignments

   user=jack
   pass=letmein
   sha1=$(echo -n $pass | shasum -a 256 | awk '{print $1}')
   kubectl -n tsb patch secret local-user-credentials -p="{\"stringData\":{\"$user\": \"$sha1\"}}"

2. Create the bookinfo-app-owner team

   Create Team

   ORG=tetrate
   
   cat <<EOF | tctl apply -f -
   apiVersion: api.tsb.tetrate.io/v2
   kind: Team
   metadata:
     name: bookinfo-app-team
     organization: ${ORG}
   spec:
     members:
     - organizations/tetrate/users/owen
     - organizations/tetrate/users/jack
     sourceType: LOCAL
   EOF

3. Assign Required Permissions

   The bookinfo-app-team requires the following minimal permissions:

   • Tenant Reader allows them to view resources within the default tenant, once these resources are further unlocked
   • Workspace Operator allows them to view and manage resources within the named Workspace, bookinfo-ws
   • Registry Reader allows them to view service details in the registry, subject to the Workspace visibility constraints (i.e. just services in their workspace)

   Permissions are assigned as follows, using AccessBindings:

   Assign Permissions

   ORG=tetrate
   TEN=default
   
   cat <<EOF | tctl apply -f -
   # needed to see anything
   apiVersion: rbac.tsb.tetrate.io/v2
   kind: AccessBindings
   metadata:
     fqn: organizations/${ORG}/tenants/${TEN}
   spec:
     allow:
     - role: rbac/tenant-reader
       subjects: 
       - team: organizations/${ORG}/teams/bookinfo-app-team
   ---
   # needed to see workspace
   apiVersion: rbac.tsb.tetrate.io/v2
   kind: AccessBindings
   metadata:
     fqn: organizations/${ORG}/tenants/${TEN}/workspaces/bookinfo-ws
   spec:
     allow:
     - role: rbac/workspace-operator
       subjects: 
       - team: organizations/${ORG}/teams/bookinfo-app-team
   ---
   # needed to vew services in the registry
   apiVersion: rbac.tsb.tetrate.io/v2
   kind: AccessBindings
   metadata:
     fqn: organizations/${ORG}
   spec:
     allow:
     - role: rbac/registryreader
       subjects: 
       - team: organizations/${ORG}/teams/bookinfo-app-team
   EOF