Security and Tetrate Service Bridge
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:
✓ Workspaces
✓ 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:
TSB’s workspaces
TSB creates a logical hierarchy for you to interact with that abstracts away from the physical infrastructure, it means that your security considerations and actions are not limited to a specific VM or Pod. Rather, any changes that you make within TSB’s management plane are made to collections of resources within your environment. TSB has done the hard work to abstract away from the physical infrastructure for the sake of ease of use and safety in service configuration, starting with a workspace.
A workspace is a strictly partitioned area where a team manages their exclusively-owned resources and associated mesh configurations. One below a workspace is the collection of logical services the team manages, which is broken down further into physical services, and eventually a single service instance.
By breaking down resources into easily viewable and manageable chunks, TSB gives you clarity on who owns what and gives you a comprehensive and easy to understand view of shared resources (for example, a Tier 1 load balancer). This means that you know where there are overlaps in resource ownership.
It also allows you to configure traffic and security access policies with as much or as little granular detail as you feel fit. TSB Workspaces have automatically applied default settings unless you create groups or configurations that override those default settings.
Tenancy
In TSB, a 'tenant' is a group of individuals or teams that share resources and operate within a specific workspace. Tenancy is designed to create boundaries for access to resources, and the ability to configure them safely. You can assign teams, such as security or app development groups, to multiple tenants within TSB.
Access control policies
Access control policies within TSB can be separated into two categories. User management and runtime access policies.
User management 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.
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.
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.
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 provides the power for the service identity functionality 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 adds that extra layer that enables users to write more granular access control policies to dictate which services can speak to others and which service cannot.
By limiting which services can speak to each other, it also reduces the potential surface area for attacks perpetrated against network-based systems that a service mesh would manage. You've limited the potential pivot. 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.
Additionally, by using the service identities in access control, TSB decouples security policies from the underlying network and infrastructure, making the policies portable across environments (cloud, kubernetes, on-prem, vm).