AWS Nitro Sandboxes isola cada pod do EKS e task do ECS com fronteira de hardware

O que mudou

A AWS anunciou nesta semana, no AWS Compute Blog, o AWS Nitro Sandboxes: um novo bloco de construção do Amazon EC2 que dá a cada container a fronteira de isolamento de uma máquina virtual completa. Cada Nitro Sandbox é uma VM leve, lançada e controlada a partir da instância EC2, que roda com kernel próprio e herda as propriedades de segurança do Nitro System: isolamento forte, zero acesso do operador aos dados do cliente e atestação criptográfica.

A ideia resolve um problema conhecido de quem opera cluster compartilhado: todos os pods ou tasks num mesmo nó dividem o mesmo kernel Linux. Uma CVE no kernel compromete, em tese, qualquer vizinho no host, e o operador do cluster tem acesso de fato à memória de qualquer workload rodando ali. Com Nitro Sandboxes, cada pod ou task ganha kernel isolado por hardware: um problema em uma sandbox não vaza para as outras, e nem o administrador do cluster, nem o time de plataforma, nem a própria AWS conseguem ler a memória do pod ou da task.

Tecnicamente, a sandbox roda como VM de primeiro nível, sem hipervisor aninhado, com o Nitro Hypervisor aplicando a fronteira de vCPU e memória em hardware. É a mesma base das Nitro Enclaves, mas adaptada para workload de container: a sandbox pode compartilhar núcleos com a instância pai por time slicing, recebe dispositivos de rede e storage virtio (não só o canal vsock das enclaves) e roda sobre uma VMM padrão, como o Firecracker.

No EKS e no ECS, a AWS oferece dois modos: isolated sandbox, que protege o nó e os vizinhos mas ainda confia no operador do nó (igual ao modelo de hoje); e confidential sandbox, totalmente atestável, com política Cedar controlando o carregamento de imagem, camada efêmera criptografada e liberação de segredos do AWS KMS só para workload que prove, via atestação, que está rodando o código aprovado.

Onde está disponível

A fonte afirma disponibilidade para "every EC2 instance type that supports Nitro Enclaves", cobrindo famílias general purpose, compute optimized, memory optimized, storage optimized e accelerated, em processadores Graviton, Intel e AMD, "in commercial Regions worldwide" (em regiões comerciais no mundo todo). A região América do Sul (São Paulo), sa-east-1, é uma região comercial da AWS, então entraria nessa descrição geral. A fonte, porém, não cita sa-east-1 nominalmente nem traz uma lista explícita de regiões, então vale confirmar a cobertura exata na documentação do Nitro Sandboxes antes de planejar a adoção em produção.

Quanto custa

Segundo a fonte, Nitro Sandboxes, junto com as integrações no EKS e no ECS, estão disponíveis sem custo adicional. Você paga a instância EC2 que já rodaria de qualquer forma, mais a taxa padrão de gestão do EKS Auto Mode ou do ECS Managed Instances, caso use essas camadas gerenciadas. A fonte não traz valor por hora da taxa de gestão nem preço específico de instância; o modelo de cobrança continua sendo o da instância EC2 escolhida, somado à cobrança já existente do Auto Mode ou do Managed Instances.

Como começar

No EKS, o caminho recomendado é o EKS Auto Mode: basta adicionar runtimeClassName à especificação do pod, com o valor confidential-sandbox ou isolated-sandbox, e o Auto Mode cuida da seleção de instância, da configuração dos componentes Nitro e do agendamento.

spec:
 runtimeClassName: confidential-sandbox
 containers:
 - name: app
 image: minha-imagem:v1

Para EKS autogerenciado, é preciso uma Amazon Machine Image compatível com Nitro Sandboxes, o que pode exigir atualização do pipeline de AMI do cluster.

No ECS, o recurso roda sobre ECS Managed Instances. É preciso habilitar nitroEnclavesEnabled no capacity provider e, no task definition, adicionar o bloco trustedExecutionConfiguration com isolationMode igual a ISOLATED_SANDBOX ou CONFIDENTIAL_SANDBOX. Tasks isoladas ou confidenciais usam modo de rede awsvpc, então cada task recebe sua própria elastic network interface. Ao descrever a task, o modo aplicado aparece no campo somente leitura trustedExecutionSummary.

No EC2 puro, quem gerencia a própria plataforma pode lançar Nitro Sandboxes diretamente em quase qualquer instância com Nitro System, hoje com suporte do Amazon Linux e do Firecracker. Existe ainda o modo "Direct Mode", que desliga a atestação mas permite que a instância pai acesse a memória da sandbox, usado por early adopters para rodar sistemas operacionais não preparados, como Windows ou Android, ou para criar ambientes de build com assinatura à prova de adulteração dos insumos usados.

O que muda para quem já usa

Para quem desenha rede e multi-conta com VPC, a boa notícia é que nada muda na camada de rede que já existe: no EKS, o pod mantém seu próprio IP de VPC via Amazon VPC CNI; no ECS, a task continua com sua elastic network interface própria em modo awsvpc. Security groups, VPC Flow Logs, Application Load Balancer, Network Load Balancer e Amazon VPC Lattice seguem funcionando como hoje, e a fonte destaca um ponto relevante para Well-Architected: as políticas de rede são aplicadas na instância pai, fora da sandbox, então um workload comprometido dentro dela não consegue desligar o próprio security group.

O ganho arquitetural está em densidade com segurança equivalente. Um provedor SaaS que hoje dedica uma instância EC2 por tenant para garantir isolamento forte passa a poder rodar vários tenants no mesmo nó do EKS ou em ECS Managed Instances, cada um dentro de sua própria sandbox, sem abrir mão da fronteira que justificava a instância dedicada. Isso reduz o número de instâncias, Auto Scaling groups e ENIs provisionadas por tenant, com impacto direto em custo e em complexidade de rede.

O trade-off que fica para quem for adotar: as vCPUs da sandbox ainda são compartilhadas com a instância pai por time slicing, então o dimensionamento de nó e as políticas de Auto Scaling precisam considerar quantas sandboxes cabem por instância, não só a capacidade bruta. Clusters EKS autogerenciados precisam de AMI compatível antes de usar o recurso, o que implica revisar pipeline de imagem. E quem optar pelo modo confidencial passa a depender de política Cedar e de chaves do AWS KMS condicionadas a atestação, uma peça nova no desenho de segurança que ainda não existia para quem só queria isolar containers sem entrar em computação confidencial.

Fonte: AWS Compute Blog