---
title: "ReadyOn’s Four Walls of tenant isolation on Amazon EKS"
description: "ReadyOn describes a four-layer tenant-isolation architecture for Harmony, its multi-tenant workforce-intelligence platform on Amazon EKS, which handles payroll data, organizational hierarchies, and operational analytics. The design combines dedicated Kubernetes namespaces, Karpenter-managed tenant node pools, per-tenant Amazon VPC security groups, and dedicated Amazon Aurora databases, with RBAC, admission control, default-deny network policies, IAM Roles for Service Accounts, and tenant-scoped secrets. GitOps through Argo CD ApplicationSets provisions identical controls and continuously reverts drift, while dual taints and admission validation prevent cross-tenant scheduling. ReadyOn says adversarial exercises have blocked all six tested cross-tenant paths to date, and reports defenses across 10 threat-model stages, though shared control-plane dependencies make the layers defense in depth rather than fully independent probabilities."
---

# ReadyOn’s Four Walls of tenant isolation on Amazon EKS

[AWS](https://yomu.fyi/company/aws) · Roshan Daneshvaran · Sep 18, 2026

**Type:** Explainer

## Summary

ReadyOn describes a four-layer tenant-isolation architecture for Harmony, its multi-tenant workforce-intelligence platform on Amazon EKS, which handles payroll data, organizational hierarchies, and operational analytics. The design combines dedicated Kubernetes namespaces, Karpenter-managed tenant node pools, per-tenant Amazon VPC security groups, and dedicated Amazon Aurora databases, with RBAC, admission control, default-deny network policies, IAM Roles for Service Accounts, and tenant-scoped secrets. GitOps through Argo CD ApplicationSets provisions identical controls and continuously reverts drift, while dual taints and admission validation prevent cross-tenant scheduling. ReadyOn says adversarial exercises have blocked all six tested cross-tenant paths to date, and reports defenses across 10 threat-model stages, though shared control-plane dependencies make the layers defense in depth rather than fully independent probabilities.

## Context

Harmony is a multi-tenant workforce-intelligence platform on Amazon EKS that processes payroll data, organizational hierarchies, and operational analytics for enterprise customers. The architecture addresses the risk that one tenant could access another tenant’s data, treating Kubernetes namespaces as a logical foundation but not as a sufficient security boundary.

## Approach / What changed

ReadyOn layers four controls: namespace isolation with RBAC, quotas, admission control, and default-deny network policies; Karpenter-managed dedicated node pools protected by dual taints and admission validation; per-tenant VPC security groups and private API access; and dedicated Aurora databases with tenant-scoped Secrets Manager paths and short-lived IRSA credentials. Argo CD ApplicationSets provision the controls consistently, while GitOps reconciliation corrects drift.

## Takeaways

- Each tenant receives a dedicated namespace, and Argo CD ApplicationSets generate its RBAC bindings, network policies, quotas, and secret configuration from Git.
- Karpenter uses both tenant and workload-type taints, while admission control verifies tolerations against namespace identity to prevent cross-tenant pod placement.
- ReadyOn reports that adversarial exercises have blocked all six tested cross-tenant paths to date, while shared control-plane dependencies mean the walls are defense in depth rather than fully independent controls.

## FAQ

### How does the architecture prevent a tenant workload from running on another tenant’s nodes?

Karpenter provisions tenant-specific nodes with both a tenant-identifying taint and a workload-type taint. Pods must tolerate both, and an admission controller checks that the tolerations match the namespace’s tenant identity.

### How is access to another tenant’s database restricted?

Each tenant’s Aurora cluster has a security group that permits inbound connections only from that tenant’s application-node security group. This restriction is enforced at the Amazon VPC layer rather than solely through Kubernetes controls.

### What happens if someone changes production cluster state manually?

The GitOps controller continuously compares the cluster with the declared state in Git. Manual changes caused by misconfiguration or unauthorized access are automatically reverted within seconds.

**Tags:** [Amazon EKS](https://yomu.fyi/topic/amazon-eks), [AWS](https://yomu.fyi/topic/aws), [IAM](https://yomu.fyi/topic/iam), [Kubernetes](https://yomu.fyi/topic/kubernetes), [Security](https://yomu.fyi/topic/security)

- Source: [AWS](https://aws.amazon.com/blogs/architecture/readyons-four-walls-of-tenant-isolation-on-amazon-eks)
- Source URL: https://aws.amazon.com/blogs/architecture/readyons-four-walls-of-tenant-isolation-on-amazon-eks
- Ingested by Yomu: 2026-09-19T00:00:12.571Z

[Read original post](https://aws.amazon.com/blogs/architecture/readyons-four-walls-of-tenant-isolation-on-amazon-eks)