Isolamento com contêiner ou microVM: 4 níveis comparados, do subprocesso à VM completa

“Roda isso numa sandbox” parece uma instrução só. Na prática, há quatro fronteiras comuns a que as pessoas se referem com isso, e elas barram coisas muito diferentes. Escolher a errada deixa você exposto ou torna cada execução mais lenta e cara do que precisa.

Esta comparação parte do princípio de que o código é realmente não confiável: escrito por um modelo de linguagem, enviado por um usuário ou chegando num pull request de alguém que você não conhece. Código que você mesmo escreveu tem outras necessidades.

O que pode dar errado

Antes de comparar fronteiras, ajuda nomear para que elas servem. Código não confiável pode:

1. Ler o que não deve: variáveis de ambiente, chaves SSH, arquivos no seu diretório pessoal, endpoints de metadados da nuvem.
2. Esgotar recursos: entrar em loop infinito, fazer fork até travar a máquina, encher o disco.
3. Abusar da rede: varrer outros hosts, mandar spam, minerar criptomoeda, chamar seus serviços internos.
4. Persistir: instalar uma tarefa cron ou um serviço que sobreviva à tarefa.
5. Escapar: usar um bug na camada de baixo para rodar código no próprio host.

Cada nível abaixo lida com parte disso, não com tudo.

Nível 1: um processo

A sandbox mais simples é um processo filho: subprocess.run com tempo limite, talvez com um usuário próprio, limites de recursos e um filtro seccomp se você for caprichoso.

Barra: execução sem fim (o tempo limite), parte do esgotamento de recursos (limites), algumas chamadas de sistema perigosas (seccomp). Não barra: a leitura de tudo o que esse usuário pode ler, o acesso à rede, a persistência por qualquer lugar onde o usuário possa escrever e qualquer bug de kernel. Falha típica: o código lê um arquivo que você esqueceu que era legível, ou um interpretador “restrito” acaba tendo uma brecha. A história está cheia de sandboxes dentro de linguagens que não aguentaram.

A inicialização é praticamente zero. Serve para o seu próprio código; não é fronteira para o código dos outros.

Nível 2: um contêiner

Os namespaces dão ao código a própria visão de arquivos, processos e rede; os cgroups limitam CPU e memória; capabilities removidas e seccomp estreitam o que ele pode pedir ao kernel.

Barra: a leitura de arquivos do host (a menos que montados), ver outros processos, uso ilimitado de recursos e boa parte do problema de persistência se o contêiner for descartado. Não barra: um bug no kernel compartilhado do host. Todos os contêineres da máquina conversam com o mesmo kernel, então uma vulnerabilidade de kernel alcançável é uma saída. Falha típica: configuração, não exploits exóticos. Um contêiner privilegiado, o socket do runtime de contêineres montado lá dentro, a rede do host ligada “só para depurar”. Cada um remove a fronteira em silêncio.

A inicialização leva milissegundos. Existem variantes reforçadas, incluindo kernels em espaço de usuário que interceptam chamadas de sistema antes que cheguem ao host, ao custo de velocidade e compatibilidade. Para código de pessoas em quem você confia, um contêiner bem configurado é um padrão sensato.

Nível 3: uma microVM

Uma microVM roda o próprio kernel sob um hipervisor, como uma VM completa, mas quase sem hardware emulado. O exemplo mais conhecido é o Firecracker.

Barra: tudo o que um contêiner barra, mais o problema do kernel compartilhado. Para chegar ao host, o código precisa quebrar o hipervisor ou um de um punhado de dispositivos virtuais, uma superfície muito menor que a interface de chamadas de sistema de um kernel. Não barra: o mau uso daquilo que você entrega a ela. Tráfego de saída aberto ainda pode ser abusado; segredos injetados ainda podem vazar. Falha típica: política, não isolamento. Alguém passa um token de produção “para os testes funcionarem” ou deixa o tráfego de saída sem restrição onde ele não é necessário.

A inicialização vai de uma fração de segundo a cerca de um segundo, com alguns megabytes de sobrecarga. É rápido o bastante para criar uma por tarefa e excluí-la depois, o que de quebra resolve a persistência: não sobra nada para onde voltar.

Nível 4: uma máquina virtual completa

Uma VM comum, ou um VPS, tem o mesmo tipo de fronteira de uma microVM: virtualização por hardware e um hipervisor. A diferença está em todo o resto: um modelo de dispositivos completo, um sistema operacional inteiro, um IP público se você quiser e um ciclo de vida medido em dias ou meses.

Barra: as mesmas classes de problemas que uma microVM, com uma superfície de ataque um pouco maior porque mais hardware é emulado. Não barra: o abuso da própria identidade de rede. Uma VM com IP público rodando código abusivo faz o IP dela parar em listas de bloqueio, o que importa se esse mesmo IP envia seus e-mails. (Se isso já aconteceu, veja o que fazer quando seu IP está numa lista de bloqueio.) Falha típica: ela vive tempo demais. Uma VM criada para um experimento acumula credenciais e estado e, aos poucos, vira a máquina confiável que deveria proteger.

A inicialização leva de dezenas de segundos a minutos, e a cobrança costuma ser mensal. É o formato certo para um serviço duradouro que precisa de portas de entrada, e o errado para rodar código por 20 segundos.

A comparação

Como escolher

• Código escrito por você ou pelo seu time: um processo ou contêiner resolve.
• CI para os seus próprios branches: um contêiner no seu runner.
• Código de agentes, envios de usuários, pull requests externos: uma microVM por tarefa, excluída depois.
• Um serviço não confiável que precisa aceitar conexões ou rodar por semanas: uma VM separada com IP próprio, longe de tudo o que guarda suas credenciais ou envia seus e-mails.

Seja qual for a escolha, duas regras valem por cima: não coloque lá dentro nada que você não entregaria ao autor do código, e decida de propósito o que a rede pode fazer.

Onde nossos produtos se encaixam

Para o nível 3, oferecemos sandboxes de código: microVMs Firecracker que iniciam em cerca de um segundo, com internet de saída, sem portas de entrada e cobrança por segundo. Elas miram exatamente o terceiro item acima; a página de proteções do MCP explica como limitar o que um agente pode fazer com elas. Para o nível 4, um VPS como o plano AI agent dá a você uma máquina inteira por mês. Os exemplos detalhados em sandbox para agentes de IA mostram o padrão com microVM de ponta a ponta, e o que agentes de IA realmente precisam da infraestrutura trata o isolamento como um de vários requisitos.