AWS Architecture Blog·September 18, 2026Multi-Tenant Isolation on Amazon EKS: The Four Walls Model
This article details ReadyOn's "Four Walls" model for achieving robust multi-tenant isolation on Amazon EKS, addressing the critical challenge of preventing cross-tenant data access in sensitive enterprise environments. It describes a layered security architecture combining Kubernetes namespaces, dedicated compute nodes, VPC network policies, and per-tenant databases, creating a compound defense against unauthorized access.
Read original on AWS Architecture BlogDesigning multi-tenant platforms, especially those handling sensitive data, presents significant security challenges. A common pitfall is relying solely on Kubernetes namespaces for isolation, which are not inherently designed as strong security boundaries. ReadyOn's "Four Walls" model on Amazon EKS offers a comprehensive, layered approach to tenant isolation, moving beyond a single point of failure to provide a compound defense.
The Four Walls: A Layered Security Architecture
The core of ReadyOn's strategy is to implement independent isolation mechanisms at different layers of the technology stack. This ensures that an attacker would need to overcome multiple, distinct barriers simultaneously to breach tenant data. The model treats some layers (like admission control and GitOps) as defense-in-depth within a control plane, rather than fully independent probabilities, highlighting a pragmatic approach to security.
- Wall 1 – Namespace Isolation: Leveraging dedicated Kubernetes namespaces with strict RBAC policies, resource quotas, and admission control. Consistency is enforced via Argo CD ApplicationSets for GitOps-driven provisioning, ensuring every tenant starts with an identical security posture.
- Wall 2 – Compute Isolation: Utilizing Karpenter to provision dedicated, auto-scaling node pools for each tenant. A dual-taint strategy (tenant-identifier and workload-type) prevents cross-tenant pod placement, complemented by admission controller validation and scoped node credentials.
- Wall 3 – Network Isolation: Implementing per-tenant Amazon VPC security groups to restrict database access exclusively to that tenant’s node pool. Kubernetes network policies enforce default-deny for inter-namespace traffic, and a multi-tier VPC architecture segregates components.
- Wall 4 – Data Isolation: Employing dedicated Amazon Aurora database clusters and tenant-scoped secrets via AWS Secrets Manager. This avoids the complexities and risks of row-level filtering in shared databases, ensuring data-at-rest encryption with unique AWS KMS keys per tenant and short-lived credentials through IAM Roles for Service Accounts (IRSA).
Key Principle: Defense in Depth
The strength of layered security lies in the requirement to bypass multiple, distinct controls. Designing isolation with mechanisms at the application, compute, network, and data layers significantly increases the difficulty for an attacker.
GitOps for Security Posture Consistency
A crucial aspect of Wall 1 is the use of GitOps. By managing tenant configurations through an Argo CD ApplicationSet, ReadyOn ensures that all required resources (namespaces, network policies, RBAC, quotas) are automatically generated and consistently applied. This eliminates manual configuration drift and guarantees that every new tenant adheres to the same security standards from inception. Any unauthorized manual changes are automatically reverted by the GitOps controller, maintaining a self-healing security posture.