Multitenancy no EKS: teste a travessia entre clientes, não apenas o namespace

A ReadyOn apresentou uma arquitetura de isolamento para a plataforma Harmony com quatro camadas: namespaces Kubernetes, pools de nós dedicados, regras de rede na VPC e bancos Aurora separados por cliente.[13] O objetivo relatado é limitar movimento lateral após o comprometimento de uma carga sem abandonar completamente um EKS compartilhado.[13] A proposta explicita que isolamento não deve depender de uma única barreira.

O que muda para quem desenvolve

A implantação combina RBAC, quotas, políticas de rede e controles de agendamento.[13] O Karpenter usa taints por cliente e tipo de carga, enquanto um controlador verifica se as tolerâncias solicitadas correspondem ao namespace.[13] No lado AWS, grupos de segurança restringem conexões ao banco apropriado, com credenciais e segredos delimitados por cliente.[13]

A leitura arquitetural é analisar caminhos, não apenas componentes. Uma configuração de namespace diz onde o recurso foi organizado. A revisão precisa demonstrar também onde a carga pode executar, quais destinos consegue alcançar e com que identidade acessa os dados.

O relato distingue isolamento lógico por namespace de separação física dos nós.[13] Isso não significa que todo produto deva comprar a arquitetura mais segregada possível. Significa que o contrato com o cliente precisa descrever o nível escolhido, sem vender um mecanismo como se cobrisse todas as fronteiras.

Como aplicar

Desenhe uma matriz com dois clientes sintéticos e quatro dimensões: API Kubernetes, agendamento, rede e banco. Para cada dimensão, defina o acesso permitido e uma tentativa que deveria falhar. Use identidades e dados de teste independentes.

No agendamento, tente solicitar uma tolerância incompatível com o cliente. Na rede, tente alcançar o banco do outro cliente. No banco, utilize credenciais do primeiro para consultar o segundo. Registre onde cada operação foi negada e qual evidência demonstra a negativa. Realize esses exercícios somente em um ambiente autorizado e preparado para isso.

Inclua também os acessos legítimos, porque isolamento que bloqueia tudo não atende ao produto. Verifique se logs e métricas permitem relacionar identidade da carga, destino e resultado sem expor dados sensíveis. O exercício deve ser repetível depois de uma mudança de configuração, não depender da lembrança de quem montou o cluster.

Cuidados e limites

A ReadyOn relata não ter encontrado caminhos entre clientes em seus exercícios, mas isso não constitui prova geral de segurança.[13] Preserve essa diferença ao usar o caso como referência.

Nós e bancos dedicados trocam parte da economia do compartilhamento por barreiras adicionais.[13] Avalie custo, capacidade ociosa e esforço de operação antes de adotar o conjunto completo. O desenho adequado é aquele cujo isolamento pode ser explicado e verificado dentro do risco assumido, não o que acumula mais caixas no diagrama.

Fonte

[13] Fonte: InfoQ