“All problems in computer science can be solved by another level of indirection.” – David Wheeler

Service mesh is an architectural construct designed to ease software development and delivery in a microservices environment. Making service mesh work at scale requires some new thinking and the introduction of a few new abstractions.

Here at Tetrate, we have been working on service mesh – its opportunities and its challenges – as long as anyone around. This work is based on our founders’ and key employees’ existing and ongoing roles as founders and maintainers of the open source projects that are most widely used in service mesh implementations: the Envoy proxy, Istio service mesh software, and the Skywalking observability project.

To complement the open source projects, and to create a complete solution, we created Tetrate Service Bridge (TSB). TSB adds a highly functional management plane to service mesh implementations, collaborating with Istio as the control plane and Envoy as the data proxy.

Why Workspaces?

As part of creating Tetrate Service Bridge, we’ve only needed to add one major new abstraction to make service mesh work the way that we believe it should. That abstraction is workspaces.

A workspace is a configurable group of resources that can be managed together – that is, in a single workspace. By designating resources as a workspace, you can manage them without further concern as to the physical infrastructure they run on, which you might want to modify or replace over time.

Developers and operators can both work at the workspace level; platform owners can modify the physical implementation as needed, with no impact on developers and minor impact on operators.

While workspaces are not a new concept in computer software, they’re new to service mesh. We’ve worked hard to make the implementation of workspaces in service mesh as similar as possible to their implementation in other domains, to make them easier to use and manage here.

This blog post describes workspaces in more depth and shows you how to use workspaces in Tetrate Service Bridge to make your service mesh implementation much easier and more efficient to manage.

What Workspaces Do

Workspaces are abstractions in TSB that you can map to the abstractions you already use to manage your organization, such as departments and work teams. As an example of how workspaces function within a working service mesh, you can map tenants – groups within your company – onto Istio clusters. The clusters used within a workspace may be in a single location per tenant, or distributed.

You can connect TSB to an LDAP or OIDC server to create a live link to up-to-date employee directory information, including named groups such as departments and subsidiaries, that employees belong to.

You can also use workspaces to assign consistent security policies, and other policies, to groups of applications. You can also move and subdivide computing resources among hosts, including multiple public cloud providers and on-premises resources. This makes it fast and easy to respond to exigencies such as bursts in demand, downtime in a cloud availability zone, available capacity in existing resources, or opportunities for improved price/performance.

With workspaces, the security team can manage security policy; operations can respond to changes in computing supply and demand; and neither developers, application owners, or end users need to even be aware of this back-end work. In this blog post, we will describe the benefits of workspaces and show how Tetrate Service Bridge helps platform architects and operators work more effectively.

For the purposes of this blog post, we’re going to assume that you understand the general workings of a service mesh in general and the roles of Istio, Envoy, and Tetrate Service Bridge. If you want to know more about these concepts and software offerings, and you are facing some of the computing problems described in this blog post, please contact Tetrate for more information.

What is a Workspace?

A workspace is a group of namespaces in one or more clusters. Workspaces are complementary to namespaces. They are a higher level of abstraction that works across clusters – even if those clusters are in very different places.

You map workspaces to tenants, or to one or more applications owned by a tenant. For instance, you can create dev, test, and prod workspaces for developers. The workspaces are isolated from one another.

Workspaces operate at a higher level of abstraction than namespaces. If you have a simple enough implementation, or a simple enough organization, you can simply use namespaces directly. However, if you want to be able to use multiple and disparate namespaces as a group, and want to be able to mix and match the namespaces used without disrupting operators and developers, use workspaces instead. (And if you are going to use workspaces eventually, it’s simpler and less disruptive to use them from the beginning.)

You create and manage workspaces in Tetrate Service Bridge (TSB), and you use workspaces in TSB to apply configuration across namespaces. You can make different groups in your organization, such as developers, security, and the operations team, responsible for different types of configuration. The workspace itself is invisible to Istio, Envoy, Kubernetes, and other software; however, the configuration changes you make using workspaces affect the way these other software platforms operate, in a way that’s easy to understand and also auditable.

Workspaces, tenants, and physical resources in Tetrate Service Bridge
Figure 1: Tenants, workspaces, and physical resources in Tetrate Service Bridge

Why Do You Need Workspaces?

Workspaces have three major benefits:

  • Replication of identity. Identity is preserved across all the clusters in the workspace, even when these clusters are in different namespaces and different infrastructure.
  • Configuration portability. As with identity, you use the same configuration on multiple namespaces and disparate infrastructure.
  • Flexibility. With workspaces, since multiple namespaces and multiple infrastructure locations are treated as one place, you can swap out namespaces and infrastructure without disruption to the application.

These features deliver many benefits. You only need to set up or revise security policies once, and the impact extends seamlessly to all the resources your application needs. And you can keep your application available by adding or swapping out resources as needed, without downtime. You can even arbitrage costs, moving to cheaper resources when the opportunity presents itself.

Workspaces are also strongly separated from each other, yielding more benefits. Each team that has its own workspace – whether it’s users in the business, end customers, developers, the security team, or operations – can speak their own language. The abstractions used by the organization are supported by TSB.

These benefits are available to newer applications using a microservices architecture, Kubernetes, Istio, and Envoy. However, you can also use the strangler pattern to add service mesh as a kind of interface to existing applications. In this way, service mesh can give your legacy applications many of the same security, availability, and efficiency benefits that greenfield microservices applications have from the beginning.

Tip. Even if you are just starting out with service mesh, use workspaces from the beginning. You will grow into the full range of benefits offered by workspaces sooner than you think.

Where Workspaces Live in TSB

TSB supports several abstractions to make it easier to manage cluster configuration and operation. Workspaces belong to tenants, which are at the same level as clusters. However, each cluster can be assigned to a workspace. Policies are assigned to a gateway group, a traffic group, or a security group.

Note: To better understand how tenants and workspaces interoperate in TSB, see the documentation on tenancy.

Tetrate Service Bridge resource hierarchy
Figure 2: Tetrate Service Bridge resource hierarchy

Three Steps to Assigning Security Policies to a Workspace

To create a workspace and assign security policies to it, follow these three steps:

  • Create a workspace
  • Set security policies for the workspace
  • Change the resources available to an application

Creating a Workspace

As we have seen before, workspaces allow you to map abstractions to the underlying infrastructure. One of the common abstractions is Applications. They are usually composed of multiple services. They can run on different namespaces, and even on different clusters or regions (for high availability, for example).

Without the Workspace abstraction, this makes configuration challenging – especially when you want to treat the entire application as a whole, and abstract the application teams from the complexity of the underlying infrastructure.

In this example, we will see how we can use workspaces to easily configure two applications, “CustomerService” and “Payments.” Each of the applications is running in two clusters, each in a cloud provider region: one in “us-central”, the other in “us-west”.

Figure 3 below shows the example topology:

Example topology
Figure 3: example topology

By default, the mesh allows connectivity between the namespaces and also between the clusters. Let’s see how we can create workspaces so we can individually configure each application, no matter where it’s running.

First we can create the following workspaces, one for each application:

apiVersion: api.tsb.tetrate.io/v2
kind: Workspace
metadata:
  name: customer-service-app
  tenant: services
  organization: tetrate
spec:
  namespaceSelector:
    names:
    - "cluster0-us-central/custsvc"
    - "cluster0-us-west/custsvc"
—
apiVersion: api.tsb.tetrate.io/v2
kind: Workspace
metadata:
  name: payments-app
  tenant: services
  organization: tetrate
spec:
  namespaceSelector:
    names:
    - "cluster0-us-central/payments"
    - "cluster0-us-west/payments"

We can see that the first workspace is selecting the “custsvc” namespace in the cluster0-us-central and the cluster0-us-west clusters. This means that all configuration and policies attached to that workspace by the corresponding application teams will apply to those namespaces.

Similarly, the workspace for the Payments application will configure policy and configuration for the “payments” namespace in the two clusters.

Workspaces mapped to clusters
Figure 4: workspaces mapped to clusters

Setting Security Policies for a Workspace

Once we have defined the workspaces, we can configure settings such as traffic and security policies. The following example shows how the workspace settings can be used to enforce that all traffic within the workspace – to be precise, all traffic between the services that are part of the namespaces captured by the workspace selectors – is encrypted and uses Mutual TLS.

Additionally, we will configure a policy that allows only traffic within the workspace, rejecting traffic coming directly from the outside and not via an ingress. This way we prevent direct access to the workspace services from services outside the workspace:

apiVersion: api.tsb.tetrate.io/v2
kind: WorkspaceSetting
metadata:
  name: customer-service-app-settings
  workspace: customer-service-app
  tenant: services
  organization: tetrate
spec:
  defaultSecuritySetting:
    authenticationSettings:
      trafficMode: REQUIRED
    authorization:
      Mode: WORKSPACE

With these settings, the workspace for the customer service will enforce mTLS encryption in all service-to-service communications and lock down the workspace from direct access from external services.

Similar settings can be applied to the Payments workspace.

Workspace-specific security policy enforcement
Figure 5: workspace-specific security policy enforcement

Moving Applications to Different Resources

A nice property of workspaces is that they abstract application teams from the underlying infrastructure. If we take a hypothetical case where the application uses another namespace, or is scaled out to another cluster or even another region, having the policies cover that new piece of infrastructure is trivial: one just needs to edit the workspace, adding the new namespace or clusters to the list of namespaces the workspace manages:

apiVersion: api.tsb.tetrate.io/v2
kind: Workspace
metadata:
  name: customer-service-app
  tenant: services
  organization: tetrate
spec:
  namespaceSelector:
    names:
    - "cluster0-us-central/custsvc"
    - "cluster0-us-west/custsvc"
    - "new-cluster/custsvc-ext"

By editing the workspace and adding the new clusters/namespaces, configuration and policies for the workspace will automatically apply, without the need for any change on the application side or to the existing policies. The granularity of policies and configuration is decoupled from the infrastructure, allowing you to write portable policies once, and configure their scope based on the needs of each abstraction the workspace is mapped to.

Policy decoupled from infrastructure
Figure 6: policy decoupled from infrastructure

Conclusion

Workspaces are a powerful abstraction that allows Tetrate Service Bridge to manage settings and functionality for Istio clusters in a way that maps directly to your organization. We’ve shown some examples of the power of workspaces in Tetrate Service Bridge. For details, see the Tetrate Service Bridge documentation or contact Tetrate.

Author(s)