AWS Batch no EKS passa a suportar capabilities Linux, seccomp e configurações de pod por job

O que mudou

O AWS Batch on Amazon EKS passou a suportar, a partir de 13 de novembro de 2026, configurações adicionais de contexto de segurança do Kubernetes nas job definitions. Agora é possível definir capabilities e seccompProfile no securityContext de um container, além de propriedades no nível do pod (como fsGroup) dentro de podProperties.

Antes disso, quem rodava cargas de lote via AWS Batch em clusters EKS que aplicam o perfil restricted dos Kubernetes Pod Security Standards esbarrava numa limitação real: a job definition não expunha os campos necessários para declarar explicitamente quais capabilities Linux o container precisa, nem qual perfil de seccomp usar. Isso forçava times a flexibilizar a política de segurança do cluster ou a rodar esses jobs fora do padrão.

Um detalhe importante de precedência: configurações definidas no nível do container sobrepõem os padrões definidos no nível do pod. Isso segue o mesmo comportamento que arquitetos de EKS já conhecem de manifests Kubernetes nativos, o que facilita portar políticas de segurança já validadas para as job definitions do Batch.

Onde está disponível

Segundo o AWS What's New, as novas configurações de contexto de segurança estão habilitadas em todas as regiões AWS onde o AWS Batch está disponível. A fonte não cita a região América do Sul (São Paulo) nominalmente, mas como o AWS Batch já opera em sa-east-1, o recurso se aplica lá também, já que a liberação segue a disponibilidade geral do serviço e não uma lista fechada de regiões.

Isso importa para quem desenha ambientes multi-região: não há espera por uma rolagem região a região, como acontece com outros lançamentos de features do EKS.

Quanto custa

A fonte não traz nenhum preço associado a este recurso, e isso faz sentido: capabilities, seccompProfile e securityContext são apenas campos de configuração na job definition, não um serviço gerenciado à parte. Você continua pagando pela infraestrutura EKS subjacente (nós EC2 ou Fargate) e pelas chamadas normais do AWS Batch, sem custo adicional por usar essas opções de segurança.

Como começar

A configuração é feita via API RegisterJobDefinition, e pode ser aplicada pelo AWS Management Console, AWS CLI, AWS SDKs ou AWS CloudFormation. O caminho prático:

1. No bloco eksProperties.podProperties.containers[].securityContext, declare capabilities.drop e capabilities.add para listar exatamente quais capabilities Linux o processo do job precisa.
2. No mesmo securityContext, defina seccompProfile.type (por exemplo, RuntimeDefault) para restringir as syscalls permitidas.
3. Para configurações que valem para todos os containers do pod, como fsGroup, use eksProperties.podProperties.securityContext em vez do nível de container.

Um exemplo de job definition com least privilege, seguindo os campos descritos pela AWS:

{
 "jobDefinitionName": "batch-restricted-job",
 "type": "container",
 "eksProperties": {
 "podProperties": {
 "containers": [
 {
 "image": "123456789012.dkr.ecr.sa-east-1.amazonaws.com/meu-job:latest",
 "securityContext": {
 "capabilities": {
 "drop": ["ALL"],
 "add": ["NET_BIND_SERVICE"]
 },
 "seccompProfile": {
 "type": "RuntimeDefault"
 }
 }
 }
 ],
 "securityContext": {
 "fsGroup": 1000
 }
 }
 }
}

Esse padrão (drop: ["ALL"] e depois add só do que é indispensável) é a prática recomendada para conformidade com o perfil restricted, e agora pode ser expressa diretamente na job definition do Batch, sem workaround.

O que muda para quem já usa

Para arquitetos e times de SRE que operam clusters EKS com o Pod Security Standards no modo restricted, o ganho é fechar uma lacuna de conformidade sem precisar tirar as cargas de lote do EKS ou abrir exceção de política para o namespace do Batch. Isso se encaixa diretamente no pilar de segurança do Well-Architected Framework: privilégio mínimo deixa de ser aspiração e passa a ser configurável no próprio artefato de deploy.

Na prática, times que hoje rodam AWS Batch em namespaces separados (muitas vezes com uma política de admissão mais permissiva só para os jobs de lote) podem reavaliar essa segregação. Com capabilities, seccompProfile e fsGroup configuráveis por job, dá para alinhar o Batch ao mesmo baseline de segurança do restante do cluster, inclusive em auditorias que cobram evidência de least privilege por workload.

Fica em aberto, porque a fonte não detalha, se há alguma diferença de suporte entre jobs rodando em nós EC2 gerenciados pelo EKS e jobs rodando sobre Fargate, nem se existe alguma capability ou perfil de seccomp que o AWS Batch bloqueia por padrão independentemente da configuração declarada.

Fonte: AWS What's New