Gloo introduces a new concept for Kubernetes-based multitenancy, the Workspace custom resource. A workspace consists of one or more Kubernetes namespaces that are in one or more clusters. Think of a workspace as the boundary of your team’s resources. To get started, you can create a workspace for each of your teams. Your teams might start with their apps in a couple Kubernetes namespaces in a single cluster. As your teams scale across namespaces and clusters, their workspaces scale with them.

Before diving in to Gloo workspace configuration, take a minute to step back and consider the question of why multitenancy matters.

Multitenancy and microservices

Flip through the following overview of how workspaces organize your services across Kubernetes clusters and namespaces.

Gloo Workspace solves multitenancy concerns

Gloo workspaces provide boundaries for how Gloo, Istio, and Kubernetes resources access each other across other workspaces. These boundaries help you manage services, sharing, and security settings across all the teams, or “tenants” in your organization.

Workspaces help you solve the following multitenancy concerns.

  • Service discovery: Gloo automatically discovers the services within the Kubernetes namespace and cluster that a workspace includes. By default, services within the same workspace can access other services within the same workspace, but not services in other workspaces. This way, your teams can focus on managing their own services without disrupting other teams.
  • Routing: Workspaces are a logical boundary for which services can route to one another. To route to services in other workspaces, your teams must actively agree to import and export select resources across their workspaces.
  • Policy enforcement: Workspaces define the scope at which a policy can impact your environment. This helps reduce the blast radius of a misconfigured policy and ensure more predictable traffic behavior.
  • Security: Workspaces set a virtual boundary to protect services from traffic outside of the workspace. You must explicitly choose to allow access from other workspaces. For example, you might restrict the ingress gateway to its own workspace. Then, you might set up your other workspaces so that only the frontend exports to and imports from the gateway. The rest of your backend apps are secured by default.
  • Consistent configuration: Gloo configuration applies only within the workspace. You can further centralize Gloo configuration to a single namespace in a management cluster. This way, you know exactly where your Gloo configuration is.

More resources for workspaces

For more information about using workspaces, check out the blog about how Gloo Mesh workspaces help multitenant teams manage their apps, by Lin Sun.