Se o kernel quebra, o container quebra junto. A gente construiu a BrasaCloud assumindo isso.

No post anterior a gente abriu as quatro camadas de isolamento de um container Linux e mostrou onde cada uma para de funcionar. O kernel tem entre 40 e 60 CVEs por ano. Todas as camadas padrão adicionam fricção, mas nenhuma segura se o kernel ceder.

Esse post mostra o que a gente empilhou por cima — e o preço que pagamos em cada decisão.

Camada 5: syscalls que nunca chegam no kernel

Quando seu app roda na BrasaCloud, as syscalls dele são interceptadas por um sandbox que reimplementa a interface do kernel Linux em userspace, isolado e exclusivo pro container.

O container não vê o kernel real do host. Se uma CVE explorar um bug numa syscall do Linux, o exploit roda contra o sandbox, não contra a máquina.

Onde isso dói: nem toda syscall é suportada. tcpdump não funciona. Sidecars que usam raw socket quebram. Ferramentas de profiling que dependem de perf_event_open não rodam. Na prática, a grande maioria dos apps web (Node, Python, Go, Java, Rust, PHP) não percebe diferença — mas se seu workload precisa de acesso direto ao kernel, a plataforma não é pra ele.

Overhead também existe. Syscalls passam por uma camada extra. Em benchmarks sintéticos, o throughput cai. Em apps reais com I/O de rede, o gargalo está na rede, não na syscall — a diferença é imperceptível.

Camada 6: cada organização em sua própria rede

Cada organização na BrasaCloud opera em rede isolada. Seus serviços se enxergam entre si, mas são invisíveis para qualquer outra organização na plataforma.

O que seus containers acessam:

Outros containers da mesma organização
Internet pública

O que seus containers não acessam:

Containers de outra organização
Serviços internos da plataforma
Rede dos hosts físicos
APIs de orquestração da infraestrutura

Como a gente valida isso

Uma test suite automatizada roda contra a infraestrutura real, verificando cada vetor de acesso — por DNS e por IP direto. Se um teste passa por DNS mas falha por IP, o isolamento tem falha. Os dois caminhos precisam estar fechados.

Camada 7: se você consegue resolver, já sabe demais

Antes de um pacote ser bloqueado, ele precisa saber pra onde ir. Quase sempre, isso começa com DNS.

Na BrasaCloud, cada organização só resolve seus próprios serviços e endpoints externos. Serviços de outras organizações e da plataforma não existem no DNS da sua organização. Não retorna erro — não há registro. Você não descobre o que existe ao lado porque, do ponto de vista do seu DNS, não existe nada.

Se um serviço é resolvível, ele é descobrível. A gente trata resolução como informação privilegiada.

Onde isso quebra: um resolver com regras por organização é mais complexo de operar. Se errarmos uma regra, uma organização pode perder resolução legítima. Por isso as regras são cobertas pela mesma test suite automatizada.

Camada 8: criptografia por volume

Cada volume persistente de cada organização é criptografado com chave própria. Acesso físico ao disco ou um exploit que chega no filesystem do host não expõe dados — sem a chave, os bytes são ilegíveis.

As chaves ficam separadas da infraestrutura de compute, acessíveis só pela orquestração da plataforma. Você usa o volume normalmente. A criptografia é transparente.

O preço: overhead de I/O. Escrita sequencial fica mais lenta. Pra bancos de dados com write-heavy, isso é mensurável. Pra aplicações web com leitura majoritária, imperceptível.

Risco operacional: se o serviço de chaves ficar indisponível, os volumes não montam. A gente mitiga com HA e backups, mas o risco existe.

Camada 9: credenciais que morrem com o processo

Secrets (banco de dados, API keys) são injetados como arquivo em memória no boot do container. Um agente efêmero autentica, busca os valores, escreve num volume em memória, e encerra. Depois do boot, o agente não existe mais.

Por que não usar env vars? Porque env vars vazam. Aparecem em crash dumps, stack traces, logs acidentais, ferramentas de APM, /proc/[pid]/environ. Um console.log(process.env) expõe tudo. Com arquivo em volume efêmero, a credencial existe enquanto o processo existe — e só no path especificado. Matou o container, matou o secret.

A fricção: o app precisa ler de arquivo em vez de process.env. A maioria dos frameworks suporta isso nativamente (dotenv com path customizado, Spring Boot external config). Mas é uma mudança real pro dev acostumado com heroku config:set.

Juntando tudo

┌────────────────────────────┐
│       Seu processo         │
├────────────────────────────┤
│  Namespaces (visibilidade) │ ← camada 1: o que ele vê
│  Cgroups (recursos)        │ ← camada 2: o que ele consome
│  Capabilities (permissões) │ ← camada 3: o que ele pode
│  Seccomp (syscalls)        │ ← camada 4: como ele fala
├────────────────────────────┤
│  Sandbox de kernel         │ ← camada 5: kernel isolado
├────────────────────────────┤
│  Rede isolada por org      │ ← camada 6: com quem ele fala
│  DNS firewall por org      │ ← camada 7: o que ele descobre
│  Criptografia por volume   │ ← camada 8: dados at rest
│  Secrets efêmeros          │ ← camada 9: credenciais em memória
├────────────────────────────┤
│    Kernel Linux (host)     │
└────────────────────────────┘

Camadas 1-4 são o padrão de qualquer container Linux. Camadas 5-9 são o que a gente adicionou.

Nenhuma delas é invulnerável sozinha. Sandbox tem bugs. Policies de rede podem ter gaps. Criptografia depende de gestão de chaves. O objetivo é exigir que múltiplas barreiras independentes sejam comprometidas pra que um ataque tenha impacto real.

Com as camadas padrão, uma vulnerabilidade no kernel pode ser suficiente. Com camadas adicionais, o impacto de uma falha individual tende a ser contido antes de atingir dados ou infraestrutura crítica.

Segurança é probabilística, não determinística. Mas existe diferença mensurável entre uma camada de defesa e cinco.

Se você já se preocupou com isolamento de container em produção, a BrasaCloud está em beta aberto: brasacloud.com.