When each customer has a Kubernetes namespace, how much isolation have you actually established? On a shared Amazon EKS cluster, preventing one customer from modifying another customer’s resources is only part of the question. You also need to explain why their data cannot be reached.

ReadyOn’s Four Walls case study, published on September 18, 2026, offers a useful design to examine. Its Harmony platform handles information including payroll data and builds tenant boundaries across several layers.

We can follow an attempted access path from a Pod in tenant A to resources in tenant B. That connects each control to the operation it stops—and to the assumptions operators must preserve.

Namespace RBAC does not determine where Pods run or connect

A namespace provides a management scope for tenant resources. RBAC can limit which Kubernetes API resources a user or ServiceAccount may operate on. Those permissions do not, by themselves, determine the Pod’s execution node or network destinations. The Kubernetes multi-tenancy documentation describes additional controls needed alongside namespaces.

ReadyOn builds on this scope with dedicated nodes, VPC traffic controls, and dedicated Aurora clusters. The useful question is where API operations, workload placement, connectivity, and data authorization are each evaluated.

For example, preventing A from reading B’s Secret through the Kubernetes API does not establish whether A can open a TCP connection to B’s database. First, consider where that Pod can run.

Dedicated placement requires taints and validation of tenant claims

ReadyOn’s Karpenter-managed nodes carry two taints: one for tenant identity and another for workload type. Pods need matching tolerations, and an admission controller checks their claims against the namespace’s tenant identity.

A simplified example is a node marked with tenant=A and workload=frontend. A toleration permits scheduling; it does not require the Pod to use that node. Confining Pods to dedicated nodes also requires constraints such as labels and required node affinity. The official taints and tolerations guide explains this distinction.

That distinction matters when adapting the design.

Karpenter’s NodePool documentation recommends mutually exclusive pools so a Pod does not match several of them. Review other pools as well as tenant pools, and verify that a Pod cannot claim another tenant’s tolerations successfully. The complete ReadyOn admission policies are not published, so copying two taints is not enough to reproduce its design.

Separate nodes still need separate Pod and database traffic controls

Different execution nodes can still communicate when network paths remain open. ReadyOn uses default-deny NetworkPolicies across namespaces and allows Aurora access from the security group associated with the corresponding tenant’s application nodes.

These controls operate at different points. NetworkPolicy requires a networking implementation that enforces it. Its permissions are additive: another broad policy can allow connections despite a default-deny policy. The NetworkPolicy specification makes this explicit. Test actual connectivity, including exceptions for DNS and shared services.

VPC security groups also use allow rules, and rules from multiple groups associated with a resource are combined. A restrictive tenant group cannot cancel a broad permission in another attached group. This follows from the security group rules documentation.

For Aurora, a cluster’s security group also applies to its DB instances. Trace the node’s source group and the database’s allowed sources together to understand the boundary. The Aurora access-control guide explains this cluster-level relationship.

Dedicated Aurora clusters and IRSA separate data placement from credential access

ReadyOn separates Aurora clusters and Secrets Manager secrets by tenant, using tenant-scoped IRSA roles for AWS API access. This combines separate data destinations with restrictions on obtaining another tenant’s credentials.

Database login and AWS API authentication are distinct. IRSA associates an IAM role with a Kubernetes ServiceAccount; enabling it does not automatically configure IAM database authentication for Aurora. The Aurora security documentation distinguishes management operations, network connectivity, and database login.

The IRSA documentation also explains that Pods with IMDS access can obtain the node role’s credentials. Review node permissions and metadata reachability alongside the workload role.

Dedicated resources add operational units to manage. ReadyOn also separates observability backends by tenant. Adopting this design therefore calls for estimating maintenance, recovery, and costs as database and monitoring resources grow with customers. This is a design implication, not a measured outcome: the case study provides no comparative cost or performance figures.

GitOps keeps boundaries consistent; access tests check that they hold

Tenant onboarding and later changes can introduce differences between otherwise consistent configurations. ReadyOn generates tenant resources with Argo CD ApplicationSet and reconciles them through GitOps. It also repeatedly tests attempts to cross tenant boundaries from tenant Pods.

To apply that approach, pair expected access with expected rejection. The following is a proposed test matrix, not a report of executed tests.

Path	Expected access within the tenant	Expected rejection across tenants
Pod placement	Starts on the designated dedicated nodes	A placement request claiming another tenant is rejected
Database connection	Required connections and queries succeed	Another tenant’s database cannot be reached
Secret retrieval	Retrieves the tenant’s own secrets	Cannot retrieve another tenant’s secrets
Observability	Reads the tenant’s own logs and metrics	Cannot read another tenant’s monitoring data

The four layers are not completely independent defenses. ReadyOn explicitly acknowledges shared management foundations in admission control, GitOps, the EKS control plane, and IAM. Permissions to change those foundations can affect several boundaries.

The answer to “how isolated are these tenants?” therefore requires more than a namespace inventory. It requires showing which identity can reach which resource through which path, then retesting allowed and denied access after changes. The practical value of Four Walls is a way to make that explanation and validation part of operations.

Source

• Title: ReadyOn’s Four Walls of tenant isolation on Amazon EKS
• URL: https://aws.amazon.com/blogs/architecture/readyons-four-walls-of-tenant-isolation-on-amazon-eks/