Multi-tenancy describes a software architecture in which a single instance of a platform serves multiple distinct customers or organisational units (tenants), where each tenant's data, configuration, and workloads are isolated from every other tenant. The platform itself is shared; the data and compute environments are not.
Why multi-tenancy matters for enterprise on-premise platforms
For Managed Service Providers (MSPs) deploying AravaliStack for multiple enterprise customers, multi-tenancy eliminates the need to operate a separate cluster per customer — which would be operationally untenable at scale. For large enterprises, multi-tenancy allows different business units, subsidiaries, or project teams to share platform infrastructure with full isolation and independent billing.
Layers of isolation in production multi-tenancy
Namespace isolation alone — Kubernetes namespaces separating tenant workloads — is insufficient for regulated environments. Production multi-tenancy requires isolation at seven layers:
Network isolation: Default-deny NetworkPolicies ensure that pods in one tenant namespace cannot send packets to pods in another — even if misconfigured. CNI plugins (Calico/Cilium) enforce this at the kernel level.
Compute isolation: Dedicated node pools with taints and tolerations ensure that high-security tenants run on hardware that is never shared with lower-trust workloads.
Storage isolation: Separate Persistent Volumes with tenant-specific encryption keys — meaning that a compromised storage admin cannot read another tenant's data.
Identity isolation: Each tenant has its own identity realm with its own user federation, SSO configuration, and role hierarchy.
Secrets isolation: A dedicated secrets namespace per tenant ensures that a tenant's application cannot read another tenant's credentials, even if the Kubernetes API is compromised.
Billing isolation: Per-namespace cost attribution with per-tenant invoicing — MSPs can invoice customers for their actual platform consumption.
Governance isolation: Role-based access control at three levels — platform operator, tenant administrator, tenant developer — with Git-managed permission definitions.