Readyon baut vierstufige Tenant-Isolation auf Amazon EKS

Harmony processes payroll data, organizational hierarchies, and operational analytics for enterprise customers. ReadyOn maps its controls to a 10-stage multi-tenant threat model, with particular attention to lateral movement from a compromised tenant workload. The company says adversarial exercises have not produced a successful cross-tenant path to date.

Mohammad Akbarpour, Professor at Stanford Graduate School of Business, discussing ReadyOn’s security architecture in a LinkedIn post, described the broader challenge 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, similarly emphasized the change in the security model when multiple tenants share infrastructure. In a LinkedIn post discussing the architecture, he wrote,

For single-tenant clusters, hardening is a well-documented challenge. But when you add multi-tenancy, the threat model fundamentally changes.

The first layer uses a dedicated Kubernetes namespace for each tenant, with RBAC, resource quotas, admission controls, and default deny network policies. ReadyOn uses Argo CD ApplicationSets to generate these resources from Git based configuration, providing the same baseline controls across tenants and automatically reconciling unauthorized changes.

The second layer isolates compute. Karpenter provisions dedicated node pools for each tenant using a dual taint strategy. Pods must tolerate both a tenant-identifying taint and a workload-type taint before they can be scheduled. An admission controller also verifies that requested tolerations correspond to the tenant associated with the namespace.

ReadyOn’s Four Walls: namespace, compute, network, and data isolation and the cross-tenant paths blocked by each layer (Source: AWS Blog Post )

The third layer moves enforcement below Kubernetes. Per-tenant VPC security groups restrict database connections to the corresponding tenant node pool, while Kubernetes network policies enforce default deny behavior between namespaces. The EKS API endpoint is private and accessed through VPN, OpenID Connect, and multi-factor authentication.

The fourth layer separates tenant data through dedicated Aurora clusters rather than relying on row-level filtering in a shared database. ReadyOn also uses tenant-scoped AWS Secrets Manager paths, short-lived credentials through IAM Roles for Service Accounts, and dedicated observability backends.

AWS documentation notes that Kubernetes namespaces, RBAC, quotas, and network policies provide logical isolation but do not prevent workloads from sharing underlying nodes. It recommends node selectors, affinity rules, or taints and tolerations when stronger workload separation is required.

The layered model has also prompted discussion about whether isolation controls can be verified effectively without corresponding observability.

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 expose gaps between controls.

Isolation depth without observability depth is indistinguishable from false confidence.

ReadyOn therefore retains a shared EKS environment while extending tenant boundaries beyond Kubernetes into scheduling, AWS networking, and dedicated data infrastructure. The architecture treats the controls as overlapping defenses rather than assuming any individual layer provides complete isolation.

Presented by: Martin Reynolds - Field CTO at Harness, and Barani Mohandoss - Director, Cloud Governance, FinOps & E-Tools at Trimble