Skip to content

Sandbox de segurança

Todo app no Coffeece roda dentro de um sandbox de segurança — uma camada extra entre o seu código e o kernel do host. Isso significa que mesmo se uma dependência for comprometida, ou se um agente de IA gerar código malicioso por engano, o estrago fica contido.

Como a gente faz isso

Hoje usamos gVisor, um runtime de container do Google que intercepta as chamadas de sistema do app e as executa num kernel em userspace. O kernel real do host fica fora de alcance — syscalls perigosas (mount, ptrace, etc.) são bloqueadas ou virtualizadas.

Estamos avaliando suporte a Kata Containers como uma alternativa pra cargas que precisam de isolamento ainda mais forte (VM leve em vez de sandbox userspace). O plano large ou superior pode optar por Kata no futuro — sem mudar a sua aplicação.

O que isso quer dizer pro seu app

  • Pode usar dependências de terceiros sem auditar cada uma
  • Pode rodar código que um agente de IA escreveu sem revisão linha a linha
  • Cargas multi-tenant (clientes separados, ambientes isolados) ficam de fato isoladas
  • Não é compatível com algumas operações de baixo nível (eBPF, módulos de kernel) — se você precisa disso, fala com a gente

Performance

gVisor adiciona overhead em I/O e syscalls intensivas (~5–15% em workloads típicos de webapp). Pra 99% dos apps Tsuru — Go, Node, Python, Ruby — o overhead é imperceptível. Se for crítico, o BYON deixa você desabilitar o sandbox: você é dono do compute, você escolhe o trade-off.

Como ativar/desativar

Na infra compartilhada da Coffeece, o sandbox é obrigatório — é o que viabiliza multi-tenancy seguro com vizinhos desconhecidos.

No seu próprio servidor (BYON), o sandbox é padrão mas opcional. Se você controla o hardware e quer máxima performance, pode escolher um plano sem sandbox na hora de criar a app — os planos disponíveis aparecem no painel, junto do servidor.

Escopo do isolamento

Em ordem decrescente de força:

  1. Kata Containers (futuro, opcional) — VM leve por container. Kernel próprio. Custo de boot maior, isolamento praticamente equivalente a uma VM completa.
  2. gVisor (padrão atual) — kernel userspace. Cobre ~95% das classes de ataque que escapam de containers tradicionais. Sem custo de boot.
  3. Container nu (Docker/runc, sem sandbox) — apenas namespaces e cgroups Linux. Vulnerável a escapes de kernel já documentados; não usado no Coffeece pra cargas multi-tenant.