ReadyOn's 4-Wall EKS Isolation: Beyond Namespaces

Layered Defense for Multi-Tenant EKS

ReadyOn's 'Four Walls' approach to multi-tenant isolation on Amazon EKS is a highly commendable and practical architectural pattern for dealing with sensitive enterprise data. The core innovation lies in its deliberate layering of independent security mechanisms across different abstraction levels: Kubernetes namespaces, compute nodes (via Karpenter and taints), AWS VPC security groups, and dedicated data stores (Aurora). This strategy effectively addresses the inherent limitations of relying solely on Kubernetes namespaces, which were never designed as a primary security boundary. The article clearly articulates how each 'wall' serves a distinct purpose and how their combination creates a formidable, defense-in-depth posture. The emphasis on GitOps for consistent deployment and self-healing drift correction further bolsters the operational security and manageability of the platform. The detailed mapping to a threat model and MITRE ATT&CK techniques demonstrates a mature understanding of the security landscape.

However, while the architecture is robust, it's important to acknowledge the inherent complexity and operational overhead associated with such a layered approach. Managing dedicated node pools per tenant, per-tenant security groups, and separate Aurora clusters, while offering superior isolation, significantly increases the management burden and cost compared to shared resource models. The article mentions this complexity implicitly by detailing the various components, but a deeper dive into the operational challenges and how ReadyOn mitigates them (e.g., automation for provisioning/decommissioning, monitoring of these disparate resources) would be beneficial. Furthermore, the 'defense in depth' aspect, where some layers share a control plane, implies a probabilistic security model. While this is realistic, understanding the specific failure modes and the cascading impact of a compromised shared control plane component would add another layer of insight. The reliance on specific AWS services like Karpenter and Aurora means this solution is tightly coupled to the AWS ecosystem, which is expected given the source, but it limits its direct applicability in hybrid or multi-cloud environments without significant re-architecture.

Key Points

• ReadyOn implements a "Four Walls" multi-tenant isolation strategy on Amazon EKS.
• Each "wall" operates at a different abstraction layer: Kubernetes namespaces, compute nodes, VPC security groups, and data stores.
• Wall 1: Namespace isolation with strict RBAC, resource quotas, and admission control managed via GitOps (Argo CD ApplicationSet).
• Wall 2: Compute isolation using Karpenter-managed dedicated node pools with a dual-taint strategy to prevent cross-tenant pod placement.
• Wall 3: Network isolation enforced by per-tenant VPC security groups for database access and default-deny Kubernetes network policies.
• Wall 4: Data isolation through dedicated Amazon Aurora database clusters per tenant and tenant-scoped secrets in AWS Secrets Manager.
• The architecture emphasizes defense-in-depth, requiring an attacker to overcome all four layers simultaneously.
• GitOps is used as the security control plane for consistent deployment and self-healing drift correction.
• Workloads use short-lived credentials via IAM Roles for Service Accounts (IRSA).
• Per-tenant observability ensures data privacy even for operational metrics.

---

📖 Source: ReadyOn’s Four Walls of tenant isolation on Amazon EKS