A ReadyOn detalhinou uma arquitetura de isolamento multi-tenant em quatro camadas para sua plataforma Harmony rodando no Amazon Elastic Kubernetes Service (EKS). O design combina namespaces Kubernetes, dedicated node pools do Karpenter, Amazon VPC security groups e bancos de dados Aurora por tenant para limitar acesso entre tenants nas camadas Kubernetes, computação, rede e dados.
A plataforma Harmony processa dados de payroll, hierarquias organizacionais e analytics operacional para clientes enterprise. ReadyOn mapeia seus controles para um modelo de ameaça multi-tenant de 10 estágios, com atenção particular ao movimento lateral a partir de uma workload de tenant comprometida. A empresa relata que exercícios adversariais não produziram um caminho cross-tenant bem-sucedido até a data do registro.
Primeira camada: isolamento no namespace Kubernetes
Cada tenant recebe um namespace Kubernetes dedicado configurado com RBAC, quotas de recursos, admission controls e network policies de deny-by-default. ReadyOn utiliza Argo CD ApplicationSets para gerar esses recursos a partir de configuração armazenada em Git, garantindo controles baseline consistentes entre tenants e reconciliando automaticamente mudanças não autorizadas.
Segunda camada: isolamento de computação
O Karpenter provisiona dedicated node pools para cada tenant usando estratégia de dual taint. Pods devem tolerar tanto um taint identificador do tenant quanto um taint de tipo de workload antes de serem escalonados. Um admission controller verifica que as tolerations solicitadas correspondem ao tenant associado ao namespace.
/filters:no_upscale()/news/2026/10/readyon-four-layer-isolation/en/resources/1readyon-1791076393945.jpeg)
Imagem: InfoQ. Os quatro pilares da ReadyOn: isolamento de namespace, computação, rede e dados, e caminhos cross-tenant bloqueados por cada camada
Terceira camada: isolamento de rede
VPC security groups por tenant restringem conexões de banco de dados para o node pool do tenant correspondente, enquanto Kubernetes network policies reforçam comportamento deny-by-default entre namespaces. O endpoint EKS API é privado e acessado através de VPN, OpenID Connect e autenticação multi-fator.
Quarta camada: isolamento de dados
Os dados de cada tenant são separados através de clusters Aurora dedicados em vez de depender de row-level filtering em banco de dados compartilhado. ReadyOn também implementa caminhos tenant-scoped no AWS Secrets Manager, credenciais de curta duração através de IAM Roles for Service Accounts, e backends de observabilidade dedicados.
Contexto da arquitetura
Mohammad Akbarpour, professor na Stanford Graduate School of Business, descreveu o desafio mais amplo como "empurrar capacidades de IA para frente enquanto torna as fronteiras ao redor de dados e workflows inacessíveis difíceis de cruzar". William Antonio G, Principal AWS Engineer na Sparq, enfatizou que "para clusters single-tenant, hardening é um desafio bem documentado. Mas quando você adiciona multi-tenancy, o threat model muda fundamentalmente".
A documentação AWS nota que namespaces Kubernetes, RBAC, quotas e network policies fornecem isolamento lógico mas não previnem que workloads compartilhem os nós subjacentes, recomendando node selectors, affinity rules ou taints e tolerations quando separação mais forte é necessária.
Observabilidade como validação
A arquitetura em camadas gerou discussão sobre se controles de isolamento podem ser verificados efetivamente sem observabilidade correspondente. Juan Pablo Gaviria argumentou que traces devem conectar workload identity com enforcement de banco de dados e rede para expor gaps entre controls, afirmando que "isolamento em profundidade sem observabilidade em profundidade é indistinguível de confiança falsa".
ReadyOn mantém um ambiente EKS compartilhado estendendo fronteiras de tenant além Kubernetes em scheduling, networking AWS e infraestrutura de dados dedicada, tratando os controles como defesas sobrepostas em vez de assumir que qualquer camada individual fornece isolamento completo.
