Readyon has outlined a four-layer tenant isolation design for its Harmony workforce intelligence platform on Amazon Elastic Kubernetes Service (EKS), aiming to reduce the chances of cross-tenant access in a shared cloud environment. The architecture combines Kubernetes namespaces, dedicated Karpenter node pools, Amazon VPC security groups, and per-tenant Amazon Aurora databases to separate tenants across the Kubernetes, compute, network, and data layers.
Why Readyon designed for deeper tenant isolation
Harmony handles payroll data, organizational hierarchies, and operational analytics for enterprise customers, which makes tenant separation a core security requirement rather than a nice-to-have. According to the report, Readyon mapped its controls to a 10-stage multi-tenant threat model, with special attention to lateral movement from a compromised tenant workload.
The company says it has run adversarial exercises against the architecture and, so far, has not found a successful path that would allow one tenant to reach another. That claim matters because multi-tenant systems often appear isolated at the application layer while still sharing infrastructure beneath the surface.
The design has also drawn attention from security and cloud practitioners discussing what stronger isolation means in practice. Mohammad Akbarpour, professor at Stanford Graduate School of Business, described the broader challenge in a LinkedIn post as “pushing AI capabilities forward while making the boundaries around inaccessible data and workflows difficult to cross.” William Antonio G, principal AWS engineer at Sparq, said in a separate LinkedIn post that while single-tenant hardening is already difficult, “when you add multi-tenancy, the threat model fundamentally changes.”
The four layers of Readyon’s EKS isolation model
Rather than depending on one control to do all the work, Readyon’s approach stacks protections so each layer limits a different class of failure. The company treats the controls as overlapping defenses, not as a single guarantee of safety.
1. Namespace-level isolation inside Kubernetes
The first layer uses a dedicated Kubernetes namespace for each tenant. Within that namespace, Readyon applies RBAC, resource quotas, admission controls, and default-deny network policies to limit what workloads can do and what they can reach.
To keep those controls consistent, the company uses Argo CD ApplicationSets to generate the tenant resources from Git-based configuration. That setup gives each tenant the same baseline policy and allows the platform to automatically reconcile unauthorized changes back to the intended state.
2. Compute isolation with dedicated node pools
The second layer separates compute using Karpenter-managed node pools that are dedicated to individual tenants. Readyon uses a dual taint strategy, meaning pods need to tolerate both a tenant-identifying taint and a workload-type taint before they can land on a node.
An admission controller adds another check by confirming that the tolerations requested by a pod match the tenant associated with the namespace. The goal is to prevent a workload from being scheduled onto compute that belongs to another tenant, even if it otherwise appears eligible at the Kubernetes level.
3. Network controls below Kubernetes
The third layer pushes enforcement beneath Kubernetes itself. Readyon uses per-tenant Amazon VPC security groups to restrict database connections so only the correct tenant node pool can reach the corresponding database resources.
At the Kubernetes layer, network policies still enforce default-deny behavior between namespaces. The EKS API endpoint is private as well, and access goes through VPN, OpenID Connect, and multi-factor authentication. That combination reduces the chance that an exposed API endpoint or weakly controlled management path could become a shared entry point across tenants.
4. Dedicated data separation
The final layer is data isolation. Instead of relying on row-level filtering in a shared database, Readyon uses dedicated Aurora clusters for each tenant. That choice removes one of the most common risks in multi-tenant SaaS architectures: a logic bug in application code that accidentally returns another tenant’s data.
Readyon also uses tenant-scoped AWS Secrets Manager paths, short-lived credentials through IAM Roles for Service Accounts, and dedicated observability backends. Together, these controls reduce the chance that a credential, secret, or monitoring pipeline intended for one tenant can be reused or inspected by another.
How the design maps to a multi-tenant threat model
The architecture is notable not because it uses unusual tools, but because it applies them in layers that align with distinct failure domains. A namespace might stop a basic Kubernetes-level mix-up, but it does not prevent node sharing. A node pool can isolate compute, but it still relies on networking and data boundaries. A database split lowers the risk of data leakage, but only if access control and credentials are equally tenant-aware.
That layered thinking reflects the threat model Readyon says it used: 10 stages of multi-tenant risk analysis, with particular focus on lateral movement after a workload compromise. In practice, this means the company is trying to block a chain of attack paths rather than betting on one control to prevent every form of abuse.
AWS documentation supports that general approach. The company’s guidance notes that Kubernetes namespaces, RBAC, quotas, and network policies provide logical isolation, but they do not stop workloads from sharing the same physical nodes. AWS recommends node selectors, affinity rules, or taints and tolerations when stronger workload separation is needed. Readyon’s model extends that guidance by combining Kubernetes controls with AWS networking and dedicated database infrastructure.
Why observability matters as much as isolation
The layered model has also raised an important question: can isolation controls be verified in a meaningful way without equally strong observability? Security teams often talk about segmentation, but proving that segmentation works is harder than configuring it.
Juan Pablo Gaviria, an engineer who commented on the architecture on LinkedIn, argued that traces need to connect workload identity with database and network enforcement to reveal any gap between the policy and the actual traffic. He summed up the concern bluntly: “Isolation depth without observability depth is indistinguishable from false confidence.”
That observation gets to the heart of modern cloud security. In a multi-tenant environment, the risk is not just whether a control exists, but whether it can be monitored, audited, and tested under real conditions. Without that visibility, teams may assume tenant boundaries are working when they are only partially enforced.
What Readyon’s approach signals for multi-tenant EKS
Readyon’s implementation suggests that multi-tenant Amazon EKS can be hardened beyond the baseline assumptions many teams make about namespaces and RBAC. By extending tenant boundaries into scheduling, VPC networking, and dedicated data infrastructure, the company is treating shared infrastructure as acceptable only when each layer independently narrows the attack surface.
That does not make the environment trivial to operate. More isolation usually means more configuration, more policy enforcement, and more moving parts to keep aligned. But for services handling sensitive enterprise data, the tradeoff may be worthwhile if the alternative is a single shared boundary that can fail silently.
In that sense, the Readyon architecture is less about one “best” security tool and more about how to combine familiar tools in a way that reflects the realities of multi-tenant risk. It is a reminder that cloud isolation is rarely achieved by one control alone. It is built by making sure that if one layer slips, another is still there to stop the breach from spreading.
Source: Original report
Was this helpful?
Explore more: DevOps Services More Cloud & DevOps Tech News
Last Modified: October 26, 2026 at 10:33 pm
1 views
