About multitenancy and namespace sameness

Understand the principles of multitenancy and namespace sameness in multicluster service meshes.

Multitenancy refers to the ability to safely run multiple teams, applications, or customer instances within shared infrastructure while maintaining appropriate isolation boundaries.

In multicluster environments, the principle of namespace sameness determines how services are identified and aggregated across clusters. While this approach provides significant operational benefits, it introduces critical limitations when namespace naming cannot be aligned across all clusters.

Review the following sections to understand how these principles are implemented in multicluster service mesh environments, considerations for implementation, and common multitenancy patterns.

Tenant boundaries and namespaces

In Kubernetes, the fundamental unit of tenancy is the namespace. Each tenant (such as a team, product, or customer instance) gets its own namespace, which serves as an isolation boundary for that tenant’s workloads and resources. This approach leverages built-in, namespace-scoped isolation features, like RBAC rules, to enforce isolation.

Istio aligns closely with this model, meaning that policies derive their primary scope from the namespace in which they’re placed. Consequently, namespaces are the default boundary for tenants in Istio-managed environments.

Namespace sameness in multicluster environments

Kubernetes lacks a native concept above namespaces to represent shared boundaries across clusters. To address this, the Kubernetes Multicluster SIG introduced the principle of namespace sameness, which determines that namespaces with the same name in different clusters are treated as the same logical namespace.

To illustrate this concept, consider two peered clusters, cluster-1 and cluster-2, each containing a payments namespace with a checkout service. When the service is configured for multicluster discovery, Istio treats these as a single logical service and aggregates their endpoints. Requests to the service are load balanced across endpoints in both clusters.

This assumption brings significant benefits:

• Simplified RBAC: Administrators can grant access to a namespace, and have that permission automatically apply to all clusters containing a namespace with that name.
• Easier telemetry: Data can be aggregated per tenant more easily with consistent namespaces everywhere.
• Consistent policy distribution: Policies defined for a namespace can be distributed and honored across clusters uniformly.

Multicluster functionality in Istio operates on the same namespace sameness assumption:

• An AuthorizationPolicy allowing traffic from a namespace implicitly allows traffic from a namespace of the same name in any peered cluster.
• Services with identical names in the same namespace across clusters, when marked global, are considered as a single logical service with aggregated endpoints.

This model works well when namespace sameness can be maintained across all clusters. However, many real-world scenarios violate this assumption, leading to conflicts that standard Istio features cannot resolve.

Additional multitenancy considerations

Beyond namespace sameness, multitenancy in service meshes requires addressing several other concerns.

Traffic isolation: A fundamental requirement for multitenancy is precisely controlling whether and how traffic flows between tenants. Istio provides the AuthorizationPolicy API to achieve traffic isolation, scoped at the namespace level and based on identity attributes like service accounts, namespaces, or trust domains.

Trust domains: Trust domains define the root of trust for service identities within a mesh. By default, Istio uses cluster.local as the trust domain. In multicluster setups, you can use a shared trust domain for simplified global mesh management, or assign each cluster a unique trust domain for stronger isolation boundaries and cluster-level authorization.

Configuration and service discovery: Other multitenancy concerns include configuration isolation and service discovery visibility. Segments address namespace sameness specifically but don’t solve these broader concerns, which are discussed in the limitations section.

Common multitenancy patterns

Organizations typically adopt one of several architectural patterns for implementing multitenancy, each with specific trade-offs around isolation, operational overhead, and complexity. These patterns work well when namespace sameness can be maintained across clusters.

Flip through the following tabs to review common multitenancy patterns.

One namespace per team is one of the most common multitenancy patterns in Kubernetes. Each team gets a dedicated namespace within a shared cluster, where they can deploy and operate multiple services. This model balances ease of management with reasonable isolation, and works well when platform teams manage shared infrastructure while delegating service ownership to individual teams.

Traffic isolation is achieved through AuthorizationPolicy resources that allow traffic only from the same namespace by default, with additional rules for cross-team access when needed.

In this model, multiple applications owned by different teams are deployed into a single shared namespace. This pattern typically emerges as a byproduct of limited Kubernetes expertise, early stage projects, or legacy setups rather than as a deliberate multitenancy strategy.

warning

Although this pattern offers simplicity, it introduces serious limitations around isolation, access control, and policy management. It is not recommended and is generally considered an anti-pattern for multitenancy.

Traffic isolation requires per-service AuthorizationPolicy resources with precise selectors, increasing operational overhead and risk of misconfiguration.

Each team gets its own dedicated Kubernetes cluster. This approach is often adopted in large enterprises operating in highly regulated industries, or with strong isolation requirements.

This pattern provides the strongest tenant boundaries, because the Kubernetes and Istio control planes for each team are isolated by default. However, it comes with increased operational overhead, and requires additional coordination for cross-cluster service communication. Traffic isolation is enforced at the cluster level using trust domains or cluster-specific identity selectors in AuthorizationPolicy resources.

In a cell-based architecture, the entire application stack (or significant parts) is deployed in self-contained, isolated units called cells. Cells are replicated across availability zones and regions for fault isolation.

A cell-based architecture is not an alternative to previous patterns, but rather a higher-level pattern that can be combined with them. Within each cell, you can still apply namespace-per-team, cluster-per-team, or other patterns. Isolation is enforced at the cell boundary, with additional patterns applied within each cell.

This pattern uses a dedicated cluster (or set of clusters) to host edge gateways that are responsible for routing ingress traffic between isolated segments of the environment. The routing layer provides centralized control for traffic entering the mesh, and makes routing decisions based on factors like geographic location, application health, or application-specific parameters.

Authorization policies allow traffic from Tier 1 gateways into Tier 2 clusters, with additional controls within Tier 2 namespaces.

These patterns work well when namespace sameness can be maintained across all clusters in your mesh. However, many real-world scenarios break this assumption, as shown in the next guide.

Next

Now that you understand the concepts of multitenancy and namespace sameness in multicluster service meshes, continue to review challenges with namespace sameness, and how segments address them.