ReadyOn’s Four Walls model provides defense-in-depth tenant isolation on Amazon EKS by combining Kubernetes namespaces, Karpenter node pools, Amazon VPC security groups, and per-tenant Amazon Aurora databases. Each layer operates independently to prevent cross-tenant data access, even if one layer is compromised. This approach supports highly sensitive enterprise workloads requiring zero-trust security without relying on a single point of protection.
First Wall: Kubernetes Namespaces for Logical Separation
ReadyOn uses Kubernetes namespaces as the first layer of isolation, assigning each tenant a dedicated namespace to prevent direct resource access between tenants. This ensures that pods, services, and configurations are scoped to individual tenants, reducing the risk of accidental or malicious cross-namespace interactions. Network policies further restrict communication between namespaces, enforcing least-privilege access at the Kubernetes level.
Namespaces provide a foundational boundary that is easy to audit and manage, allowing ReadyOn to apply tenant-specific RBAC policies and resource quotas. By isolating workloads at the namespace level, they limit the blast radius of any potential compromise within the cluster. This layer is critical for meeting compliance requirements that mandate logical separation of tenant data.
While namespaces alone are insufficient for high-security workloads, they form the essential first wall in ReadyOn’s defense-in-depth strategy. They enable clear ownership and visibility into tenant resource usage, simplifying monitoring and cost allocation. This layer works in concert with the others to ensure no single point of failure can lead to tenant data exposure.
Second Wall: Karpenter Node Pools for Compute Isolation
The second layer uses Karpenter to provision dedicated node pools per tenant, ensuring that workloads from different tenants never share the same underlying EC2 instances. Karpenter automatically scales nodes based on tenant workload demands while maintaining strict isolation between node pools. This prevents side-channel attacks and resource contention that could arise from shared compute infrastructure.
By decoupling tenant workloads at the node level, ReadyOn eliminates risks associated with multi-tenant container escapes or kernel-level vulnerabilities. Each node pool is configured with tenant-specific security settings, including IAM roles and instance types, further hardening the boundary. This layer also enables fine-grained cost attribution and performance tuning per tenant.
Karpenter’s dynamic provisioning ensures that isolation does not come at the cost of operational overhead or over-provisioning. Nodes are launched only when needed and terminated when idle, optimizing resource efficiency without compromising security. This compute-level separation strengthens the overall zero-trust posture by assuming breach at the pod level and limiting lateral movement.
Third and Fourth Walls: VPC Security Groups and Per-Tenant Aurora Databases
The third layer employs Amazon VPC security groups to enforce network-level isolation between tenant workloads and their associated resources. Each tenant’s node pool and database are assigned unique security groups that restrict ingress and egress traffic to only approved sources and destinations. This prevents unauthorized network traversal even if an attacker gains access to a tenant’s compute resources.
The fourth and final layer isolates tenant data at the storage level using per-tenant Amazon Aurora databases. Each tenant receives a dedicated Aurora cluster, ensuring that data is physically and logically separated from other tenants. This eliminates risks of data leakage through shared database instances, misconfigured queries, or backup cross-contamination.
Together, these four layers—namespaces, Karpenter node pools, VPC security groups, and isolated Aurora databases—create a zero-trust architecture where trust is never assumed and verification is enforced at every level. ReadyOn’s model demonstrates how native AWS and Kubernetes tools can be combined to achieve robust tenant isolation for sensitive enterprise workloads on EKS.
What to do next
For teams building multi-tenant platforms on EKS, ReadyOn’s Four Walls model offers a practical blueprint for achieving defense-in-depth isolation using AWS-native services. Start by mapping your tenant boundaries to Kubernetes namespaces, then layer in dedicated compute via Karpenter, network policies via VPC security groups, and finally, isolated data stores. Validate each layer independently and test failure scenarios to ensure no single point of compromise can lead to cross-tenant data exposure.
Source: ReadyOn’s Four Walls of tenant isolation on Amazon EKS (AWS).
