Gloo Mesh 2.0 Workspaces – Multi-Tenant Application Networking APIs

Lin Sun | March 08, 2022

While working with many of our users, we learned that they have multiple services running on Kubernetes clusters and VMs that are owned by many teams. Some services are internal to the team, some services are consumers of other teams’ services, and some services are producers for other teams’ services. It is critical for each team to know what services are available for consumption, either from within the team or from other teams. User feedback speaks loud and clear that they need teams and multi-tenancy for their application networking APIs.

What is a workspace?

Workspace is a logical boundary for a team and provides the foundation for multi-tenancy for Gloo Mesh. For platform admins, workspaces make it straightforward to onboard teams so that they can build and deploy services themselves within the boundary of their own workspaces.

Benefits of using workspaces

Workspaces enable multiple teams to co-exist with proper configuration and security isolation between workspaces. Without workspaces, using Istio as an example, operators would have to configure proper Sidecar resource, exportTo and AuthorizationPolicy to ensure configurations are shared within a single workspace but isolated across workspaces unless there are dependencies required by applications running across workspaces.

Another benefit is that a workspace can grow dynamically as any application in the workspace expands to more clusters regardless if it is in the same or different zones and regions. There is no need for operators to manually deploy the Gloo Mesh or Istio resources to the expanded cluster because Gloo Mesh can detect the availability of the application in the additional clusters as part of the workspace expansion using our label selectors.

How to create a workspace?

Platform admins can create workspace resources in the gloo-mesh namespace in the management cluster based on specific cluster and namespace names, or dynamically selecting clusters by labels and multiple namespace names. The example below shows the foo workspace dynamically selects its workload clusters by the region: us-east label.

apiVersion: admin.gloo.solo.io/v2
kind: Workspace
metadata:
  name: foo
  namespace: gloo-mesh
  labels:
    team: foo
    gloo.solo.io/exportToGateway: tier1
spec:
  workloadClusters:
    - selector:
        region: us-east
      namespaces:
        - name: foo*

Where is the cluster label region: us-east defined? Platform admins define the cluster labels in each cluster’s KubernetesCluster resource, which are deployed in the gloo-mesh namespace in the management cluster:

apiVersion: admin.gloo.solo.io/v2
kind: KubernetesCluster
metadata:
  name: cluster-east2
  namespace: gloo-mesh
  labels:
    region: us-east
spec:
  clusterDomain: cluster.local

Workspace settings

Most workspaces won’t be totally isolated and will have some communication with other workspaces. We specifically designed the WorkspaceSettings resource (separate the from Workspace resource) to enable application owners to configure and overwrite what their workspaces are importing, what their workspaces are exporting to, along with configuration options such as service isolation or federation. All these can be self serviced by the application owners without involvement from the platform admins.

Global workspace settings

Platform admins can deploy the default workspace settings for all workspaces in the gloo-mesh namespace in the management cluster. The following workspace settings disables service isolation and federation globally, which helps developers and operators to easily transition their applications onto workspaces.

apiVersion: admin.gloo.solo.io/v2
kind: WorkspaceSettings
metadata:
  name: default
  namespace: gloo-mesh
spec:
  options:
    serviceIsolation:
      enabled: false
    federation:
      enabled: false
      hostSuffix: 'gminaction.io'

Workspace settings for your workspace

Once platform admins created the workspaces, application owners can overwrite global workspace settings as needed for their own workspaces. Application owners can configure the workspace’s settings based on application relationships with other workspaces through imports and exportTo. The example below configures the bar workspace to export to the n-s-gateway workspace and foo workspace which are selected by labels for these two workspaces, along with enabling the serviceIsolation for the workspace and federation for any services that have the simple-federation:wanted label within the workspace:

apiVersion: admin.gloo.solo.io/v2
kind: WorkspaceSettings
metadata:
  name: default
  namespace: bar-ns
spec:
  exportTo:
    - selector:
        team: n-s-gateway
    - selector:
        team: foo
options:
  serviceIsolation:
    enabled: true
  federation:
    enabled: true
    hostSuffix: 'gminaction.io'
    serviceSelector:
      - labels:
          simple-federation: wanted
    ports:
      - number: 9080

Root config namespace for your workspace

Root config namespace is where workspace-wide config should live. Root config namespace can reside in any workload cluster that belongs to the workspace or the management cluster. The root config namespace for the workspace is determined from the namespace where your WorkspaceSettings resource is deployed.

For any Gloo Mesh resource that operators deploy to the root config namespace, Gloo Mesh will automatically propagate the translated Istio resources to all applicable workload clusters. This is huge because operators no longer need to keep track of which application runs on which cluster where Istio resources must be available for the application, a key challenge Christian highlighted in his Configuration as Data, GitOps, and Controllers: it’s not simple for multi-cluster blog.
To export Gloo Mesh resources for other workspaces to consume, deploy the resources in the root config namespace, labeling them with workspace.solo.io/exported: "true".
For the resources that are not intended or ready to share with other workspaces, you can choose not to export them. To not export, simply do not add the workspace.solo.io/exported: "true" label, or create the resource in a namespace other than the root config namespace.

Root config namespace reinforces the declarative configuration for Gloo Mesh resources, where operators only need to deploy the Gloo Mesh resources as intentions to the root config namespace regardless of whether the workspace spans multiple clusters or not.

What do workspaces take care for you automatically?

To ensure the workspace boundary is enforced, whenever a workspace is created, Gloo Mesh configures the Istio Sidecar resources for your workspace automatically based on the imports and exportTo defined in your workspace settings. If service isolation is enabled for your workspace, Gloo Mesh enables mutual TLS for your workspace and configures Istio Authorization policy to only allow services from within the current workspace and any workspace(s) that import the current workspace. For example, the internal services in the bar workspace won’t be available for anyone outside of the bar workspace. When the foo workspace imports the bar workspace, the foo workspace will only be able to use the virtual destinations from the bar workspace, not any of the internal services.

When federation is enabled, the services from the bar workspace matching the service selector by label (e.g. bar service has the matching simple-federation: wanted label) will be automatically federated to other workspaces regardless if the foo service is on the same cluster or different cluster(s), because Gloo Mesh creates the VirtualDestination resources for operators automatically under the cover which handles the cross cluster routing and ejects unhealthy local bar service as needed.

Wrapping Up

Through workspaces, Gloo Mesh 2.0 simplifies service mesh adoption for applications across multiple teams with proper config isolation and access control among teams, without developers or operators building the lower-level Istio resources manually. I am super excited about the Gloo Mesh 2.0 workspaces to further help our users simplify their service mesh adoption, and seamlessly transition from single to multiple clusters across different zones/regions/clouds. To learn more about Gloo Mesh 2.0, check out our Gloo Mesh 2.0 sessions from SoloCon – join us!

What’s new in Gloo Mesh 2.0 & Future Roadmap with Neeraj Poddar, Chris Gaun
New Gloo Mesh 2.0 API & Multi-Tenancy with Scott Weiss, Lin Sun
Hands on with Multi-tenant Istio Service Mesh with Gloo Mesh with Denis Jannot, Alex Ly

If you’d like to try Gloo Mesh 2.0, sign up for a demo here. We look forward to helping you and your team on your cloud native journey!

About the Author

Lin Sun

Lin is the Director of Open-Source at Solo.io. She has been a maintainer of Istio service mesh since 2017 and serves on the Istio Technical Oversight Committee. Previously, she served on the Istio Steering Committee for four years and was a Senior Technical Staff Member and Master Inventor at IBM for 15+ years. She is the author of the "Istio Explained" and "Istio Ambient Explained" books and has more than 200 patents to her name.