ReadyOn has detailed a four-layer tenant isolation architecture for its Harmony workforce intelligence platform operating on Amazon Elastic Kubernetes Service (EKS).
This design combines several mechanisms: Kubernetes namespaces, dedicated Karpenter node pools, Amazon VPC security groups, and separate Aurora databases for each tenant. These elements work together to limit cross-tenant access across the Kubernetes, compute, network, and data layers.
Harmony manages payroll data, organizational hierarchies, and operational analytics for its enterprise clientele. The company maps its implemented controls against a 10-stage multi-tenant threat model, paying close attention to lateral movement originating from a compromised tenant workload. ReadyOn reports that adversarial exercises have not yet revealed a successful cross-tenant path.
Professor Mohammad Akbarpour of Stanford Graduate School of Business noted the broader difficulty in his LinkedIn post: "pushing AI capabilities forward while making the boundaries around inaccessible data and workflows difficult to cross." Similarly, William Antonio G, a principal AWS engineer at Sparq, highlighted the security model shift when multiple tenants share infrastructure, stating in a LinkedIn post: "For single-tenant clusters, hardening is a well-documented challenge. But when you add multi-tenancy, the threat model fundamentally changes."
The initial layer involves a dedicated Kubernetes namespace per tenant, enforced with RBAC, resource quotas, admission controls, and default deny network policies. ReadyOn utilizes Argo CD ApplicationSets to generate these resources from Git-based configuration, ensuring consistent baseline controls and automatically reconciling unauthorized alterations across tenants.
The second layer addresses compute isolation. Karpenter provisions distinct node pools for every tenant using a dual taint strategy. Pods must satisfy both a tenant-identifying taint and a workload-type taint to be scheduled. Furthermore, an admission controller validates that requested tolerations match the tenant associated with the namespace.
Enforcement extends below Kubernetes in the third layer. Per-tenant VPC security groups restrict database connections to the relevant tenant node pool, while Kubernetes network policies enforce a default deny posture between namespaces. Access to the EKS API endpoint is secured via VPN, OpenID Connect, and multi-factor authentication.
The fourth layer achieves data separation by employing dedicated Aurora clusters, foregoing reliance on row-level filtering within a shared database. ReadyOn also incorporates tenant-scoped AWS Secrets Manager paths, short-lived credentials via IAM Roles for Service Accounts, and specific observability backends.
AWS documentation advises that while Kubernetes namespaces, RBAC, quotas, and network policies offer logical isolation, they do not prevent workloads from sharing underlying nodes, suggesting node selectors, affinity rules, or taints and tolerations for stronger separation.
The layered approach has spurred discussion regarding verification, with engineer Juan Pablo Gaviria commenting on LinkedIn that "traces need to connect workload identity with database and network enforcement to expose gaps between controls. Isolation depth without observability depth is indistinguishable from false confidence."
This architecture maintains a shared EKS environment while expanding tenant boundaries into scheduling, AWS networking, and dedicated data infrastructure, treating controls as overlapping defenses rather than assuming any single layer ensures complete isolation.
