Como isolamos tenants no nível do kernel

O problema das fronteiras frouxas

Contêineres comuns sobre um kernel compartilhado são um formato de empacotamento, não uma fronteira de segurança. Por padrão, todos os contêineres de um host compartilham a mesma superfície de ataque do kernel, o mesmo escalonador e as mesmas filas de IO. Se um tenant encontrar uma vulnerabilidade no kernel — ou simplesmente rodar uma fork bomb — o raio de impacto é a máquina inteira, incluindo todos os outros clientes nela.

Vizinhos barulhentos são a versão cotidiana da mesma falha. Sem limites impostos, o job em lote de um tenant pode roubar ciclos de CPU, saturar o IO de disco e expulsar da memória as páginas de outro tenant. Multi-tenancy hostil exige fronteiras que o kernel faça valer, e não convenções que só um workload bem-comportado respeita.

Namespaces, cgroups e seccomp

Na Anested Cloud, cada workload de tenant recebe seus próprios namespaces de PID, rede e montagem. Processos de um tenant literalmente não conseguem ver, sinalizar nem rastrear processos de outro; cada workload enxerga sua própria visão privada do sistema de arquivos e sua própria pilha de rede. Isso é imposto pelo kernel Linux em cada syscall, e não por um motor de políticas que pode ser mal configurado.

Sobre os namespaces, adicionamos o controle de recursos do cgroup v2 e a filtragem de syscalls do seccomp. Cotas limitam tempo de CPU, memória e IO de bloco por tenant, de modo que um processo descontrolado estrangula a si mesmo, e não o host. Perfis seccomp rejeitam syscalls que um workload não tem por que fazer — eliminando classes inteiras de exploits de kernel antes que alcancem código vulnerável.

• Namespace de rede dedicado, com interface virtual e regras de firewall próprias
• Cotas de cgroup v2 para CPU, memória e IO de bloco
• Perfis seccomp que liberam apenas as syscalls de que o workload precisa
• Sistemas de arquivos raiz somente leitura, com montagens graváveis explícitas

Isolamento de rede por tenant

Cada tenant vive em sua própria rede virtual privada. As regras de firewall são geradas por tenant e negam tudo por padrão: não existe rota entre os workloads de um tenant e os de outro, então o tráfego leste-oeste entre tenants é impossível por construção. Escanear as portas do vizinho de dentro de um VPS Anested não retorna nem portas fechadas — os pacotes nunca saem do seu namespace de rede.

O tráfego público entra pelo proxy de borda e por nenhum outro lugar. O TLS termina na borda, as requisições são roteadas para a rede de exatamente um tenant, e os serviços internos nunca aceitam conexões vindas de fora do próprio segmento. O resultado é uma topologia em que a única superfície alcançável é aquela que você expôs deliberadamente.

O que isso significa para bancos de dados

Os mesmos muros valem para cada banco de dados gerenciado PostgreSQL, MongoDB e MySQL que operamos. Cada instância fica confinada em seus próprios namespaces, limites de cgroup v2 e perfil seccomp, então a query lenta ou a construção de índice descontrolada de um tenant não consegue privar o banco de outro de CPU, memória ou IO. Sua latência p99 é função do seu workload, não do workload do vizinho.

As strings de conexão têm escopo por banco de dados e só resolvem dentro da rede do tenant proprietário. Mesmo uma credencial vazada é inútil a partir do segmento de outro tenant, porque os pacotes simplesmente não chegam lá. Isolamento nas camadas de kernel e de rede significa que o controle de acesso do banco não é sua última linha de defesa — é uma entre várias.

Defesa em profundidade, por padrão

Nenhuma camada é considerada perfeita. Os hosts recebem patches em cronograma contínuo, com migração ao vivo quando possível; os kernels são mantidos atualizados contra CVEs conhecidas; e cada camada é monitorada em busca de anomalias — de negações inesperadas de syscalls a tráfego entre namespaces que jamais deveria existir. Cada componente interno roda com o mínimo de privilégios necessário, para que o comprometimento de um serviço não se propague.

Nada disso é um adicional enterprise. Isolamento no nível do kernel, rede por tenant e cotas de recursos se aplicam a todo workload na Anested Cloud — inclusive no plano gratuito. Segurança que depende do seu plano de cobrança não é segurança; é uma página de preços.