
ReadyOn's Four Walls: The EKS Tenant Isolation Architecture That Blocks All 6 Attack Paths
Cloud Platform EngineeringMulti-tenant Kubernetes has a specific security problem: namespace isolation is necessary but not sufficient. Namespaces create logical boundaries and RBAC gives access control, but a determined attacker with a foothold in one tenant’s namespace has multiple paths to lateral movement — through shared compute, network adjacency, or shared data infrastructure. ReadyOn’s Four Walls architecture addresses this by layering four independent isolation mechanisms, each of which must be simultaneously bypassed for a cross-tenant breach.
The result: all six documented cross-tenant attack paths blocked, with no successful breaches in adversarial exercises. The architecture is documented on the AWS Architecture Blog because it represents a replicable pattern, not a proprietary ReadyOn approach.
The Four Walls
Wall 1 — Namespace Isolation (Logical Boundary)
Standard Kubernetes namespaces, but enforced with strict RBAC policies, resource quotas, and admission controls that prevent namespace escape. An Argo CD ApplicationSet ensures every tenant receives identical security configuration automatically — no manual provisioning that creates configuration drift between tenants.
Pod Security Standards set to “restricted” level applies across all tenant workloads, blocking privileged containers, host network access, and host path mounts at admission time.
Wall 2 — Compute Isolation (Node-Level Boundary)
Karpenter provisions dedicated node pools per tenant using a dual-taint strategy: each node carries both a tenant-specific taint and a workload-type taint. A pod must tolerate both taints to be scheduled on those nodes. This prevents cross-tenant pod co-location at the infrastructure level — even if namespace isolation fails, a pod cannot execute on another tenant’s nodes.
The dual-taint requirement is the key design decision. A single taint creates a weaker barrier; requiring toleration of both the tenant identifier and the workload type means any bypass attempt requires compromising two independent scheduling constraints.
Wall 3 — Network Isolation (Traffic Boundary)
Per-tenant VPC security groups restrict database access to specific node pools — a tenant’s database layer only accepts connections from that tenant’s compute nodes. Kubernetes NetworkPolicies enforce default-deny between namespaces, so cross-namespace network communication requires explicit policy.
The cluster API server remains private and accessible only via VPN, with OIDC and MFA required. This prevents the common attack vector of API server access from within a compromised container.
Wall 4 — Data Isolation (Storage Boundary)
Each tenant gets a dedicated Amazon Aurora database cluster with a unique KMS encryption key. Applications authenticate using short-lived IAM credentials via IAM Roles for Service Accounts (IRSA), eliminating long-lived keys that could be stolen and reused across tenant boundaries.
The per-tenant KMS key means that even if an attacker gained access to another tenant’s encrypted data at rest, they cannot decrypt it without the specific key scoped to that tenant’s account.
Why This Architecture
ReadyOn handles sensitive payroll data and organizational hierarchies — the class of data where a cross-tenant breach has immediate compliance and legal consequences beyond technical impact. Kubernetes namespaces alone proved insufficient as the sole isolation mechanism for this threat model.
The Four Walls model accepts additional operational complexity (dedicated node pools, per-tenant Aurora clusters, more infrastructure per tenant) in exchange for defense-in-depth that survives partial compromise. Any single wall failing doesn’t yield a breach — an attacker must penetrate all four simultaneously.
Observable results: All six cross-tenant attack paths blocked at the lateral movement stage. OpenTelemetry provides per-tenant observability for detecting anomalous behavior before it escalates.
The So What
For platform teams building multi-tenant SaaS on EKS — especially in payroll, healthcare, finance, or any vertical where data isolation has regulatory weight — the Four Walls model is a concrete architecture worth studying. The components (Karpenter, Argo CD ApplicationSet, IRSA, per-tenant Aurora) are all standard AWS primitives; the design insight is the layering strategy and the dual-taint scheduling constraint.
The architectural cost is real: per-tenant infrastructure increases EKS operational complexity. The security benefit is quantifiable: six attack paths blocked, adversarial exercises passed. Whether that tradeoff is appropriate depends on the sensitivity of your tenant data.
Source: AWS Architecture Blog
Content created with AI assistance and reviewed for accuracy.
Join the conversation
Stack Insiders is our free community for readers who want to go deeper — share resources, ask questions, and connect with others across every vertical we cover.
Join Stack Insiders →