Security

Security is integrated into every part of TSB, and zero trust is the basis for all security within your mesh-managed environment. TSB offers unique security advantages derived from smart user controls, and hardened access policies that you map to your organization's structure. TSB helps to protect your applications, support compliance efforts, by making it easier to manage resources, and prevent outages.

In this section, you'll learn about:
✓ Tenancy
✓ Access control policies in TSB
✓ Auditability
✓ Service identities

TSB provides a logic-based approach that takes the policies that your organization needs and maps them to your infrastructure in such a way that it aligns to your organizational setup.

Here's how:

Tenancy

TSB creates a logical hierarchy of resources for you to interact with that abstracts away your physical infrastructure. That means that your security considerations and actions are not limited to an individual VM or Pod.

Instead, any changes that you make within TSB's management plane apply to collections of resources within your environment. TSB does the hard work of abstracting your physical infrastructure to make service configuration safer, and easier to use.

By grouping your infrastructure into easily viewable and manageable chunks, TSB gives you clarity in to who owns what, and gives you a comprehensive and easy to understand view of shared resources. Shared ownership creates the potential for more problems, like shared-fate outages or noisy neighbors, and in our experience are the points where complex systems fail most often. TSB makes it simple to understand where shared ownership exists in your system, and helps you manage it safely.

Resource Hierarchy

The root of TSB's hierarchy is the organization.

Organizations

There's only a single organization in each TSB install, and your organization is where TSB-wide settings are stored. That organization is also where teams, users, and clusters are onboarded. The resources onboarded into an organization are divided across the organization's tenants.

Tenants

In TSB, a tenant is a group of individuals or teams that share resources and operate within a set of workspaces. Tenancy in TSB is designed to create boundaries for access to resources, and the ability to configure them safely. You can assign teams, such as security team or app development teams, to multiple tenants within TSB. The resources a tenant owns are further divided into workspaces, which are usually assigned to individual teams. The permissions you assign to teams on a tenant will be inherited down so they can make changes to all workspaces in that tenant too.

Workspaces

A workspace is a strictly partitioned area where a team manages their exclusively-owned resources and associated mesh configurations. Below a workspace is the collection of logical services the team manages - groups in our hierarchy - which is broken down further into physical services, and eventually a single service instance.

Workspaces also allows you to configure traffic and security access policies with as much granularity as you need. TSB allows you to set default configuration for entire workspaces that are automatically applied to all services in that workspace, unless you create groups or configurations that override those default settings.

Access Control Policies

Access control policies within TSB can be separated into two categories: runtime access policies and user management.

Runtime Access Policies

TSB logical model allows flexible configuration of runtime security policies like encryption in transit (mTLS) and end-user authentication (such as JWT based authentication). Runtime access policies can also leverage the runtime service identities that constitute one of the main building blocks of the Zero Trust Architecture (ZTA) provided by TSB.

The user management access policies mentioned above can be used to configure the different personas that are allowed to configure these settings, providing an understandable and fine-grained access to the features.

User Access Policies

Every resource within TSB has an access policy that describes who can access it and under what conditions. TSB aligns with your business structure by importing the information (users, groups) from your corporate identity provider (e.g. LDAP), and uses Next Generation Access Control (NGAC) to internally map the different users and groups to the access control policies that you define. The outcome is access control policies that isolate organizational boundaries for compliance purposes and/or prevent users from affecting resources from other teams. You can manage these access policies with TSB's simple and easy RBAC APIs.

Users and Teams are resources in TSB, and you can interact with them via TSB's Teams and Users APIs. Fortunately, most of the time you won't need to use these APIs: TSB automatically syncs with common identity providers like LDAP and OIDC to import this data and keep it up to date with changes you make to the source of truth. See the installation reference docs for information on supported identity providers today.

User Access and the Resource Hierarchy

You can use TSB's RBAC APIs to grant Users and Teams permissions to resources in TSB's resource hierarchy. The permissions you grant are inherited down that hierarchy. Combined with TSB's powerful IAM system, which supports fine-grained permissions and custom roles, you have an incredible amount of control over who can do what to infrastructure being managed by TSB.

For example, many TSB users today work in highly regulated industries and use the service mesh for runtime controls - and especially encryption in transit. For them it's very important that encryption in transit is enabled across the entire infrastructure, and a benefit of the mesh is that they can manage it centrally without involving every application team. So we see enterprises grant a central security team the ability to see all resources, access audit records, and the ability to configure encryption in transit on the Organization. They then remove the ability to change encryption in transit settings (a specific permission in TSB) from everyone else, with TSB's custom role API — which also allows you to edit the predefined roles TSB comes with out of the box. Finally, central security will often delegate down the ability to change security controls to line-of-business security teams closer to the application developers by assigning them security permissions on their line-of-business's Tenants in TSB.

This means that the central security team can audit the entire infrastructure, view traffic in transit, and implement encryption in transit transparently to application teams. The line-of-business security teams can do the same for their part of the infrastructure, while also having the ability to tailor controls for their application developers to the unique requirements of their part of the business. Application teams can't overwrite those security settings, but also don't have to even think about encryption in their application because the platform does it for them out out of the box.

TSB's powerful IAM system combined with its resource hierarchy let you have your cake and eat it too: you can maintain safety and control without sacrificing agility and time-to-market.

Auditability

TSB keeps track of all the changes that have been done to the resources it controls, providing unique auditability features. Every resource within TSB can be audited, and detailed. Fine-grained information such as who changed what, when, and the exact changes made to any resource can be easily obtained using the TSB audit logs APIs.

The TSB audit log APIs are also integrated with the permission system: queries to the audit log API will only return audit logs for those resources the user has permissions on.

Service identities at runtime

TSB uses service identities as opposed to an IP or network location to provide even greater control over your network security using access policies. Istio powers service identity within TSB and provides every workload with a verifiable identity for authentication and authorization at runtime. The SPIFFE identities issued by Istio and rotated at runtime form the basis for the identities for authentication between workloads and encryption in transit.

TSB then enables application developers and security teams to write more granular access control policies to dictate which services can speak to others — and how — and which services cannot. By limiting which services can speak to each other, you can limit the surface area for a potential pivot, and thus can reduce the potential surface area for attacks perpetrated against network-based systems that a service mesh manages.

A bad actor can only pivot through a specific set of services because the rest are blocked, keeping the rest of your applications and services unimpacted. And because Istio rotates certificates aggressively (as frequently as hourly), we also bound attacks in time — an attacker has to persist an attack or re-steal credentials frequently, greatly increasing difficultly and discoverability.

Finally — and maybe most important of all — by using service identities for access control policies, TSB decouples those policies from the underlying network and infrastructure, making the policies portable across environments (cloud, Kubernetes, on-prem, vm).