Proteja workloads de containers na AWS com regras baseadas em atributos no Network Firewall

O problema com IPs efêmeros em ambientes de containers

Quem já operou clusters Kubernetes em produção conhece bem o desafio: pods sobem, morrem e reiniciam o tempo todo, e cada vez que isso acontece, o endereço IP muda. Manter regras de firewall baseadas nesses IPs é uma tarefa ingrata — trabalhosa, propensa a erros e, na prática, uma fonte constante de brechas de segurança.

O AWS Network Firewall já era capaz de proteger o tráfego de aplicações containerizadas no Amazon Elastic Kubernetes Service (Amazon EKS) e no Amazon Elastic Container Service (Amazon ECS). Mas a dependência de endereços IP para definir regras tornava a gestão dessas políticas complexa em ambientes dinâmicos.

Isso vale especialmente para workloads de Inteligência Artificial e Machine Learning (IA/ML) rodando no Amazon EKS — como inferência de modelos, pipelines de Geração Aumentada por Recuperação (RAG) e ambientes JupyterHub. Essas cargas de trabalho exigem as mesmas proteções de firewall aplicadas a qualquer outra aplicação, e a rotatividade de IPs torna essa proteção ainda mais difícil de garantir.

As Kubernetes Network Policies oferecem controle básico de tráfego no nível de namespace, operando nas camadas 3 e 4 do modelo de rede. Dependendo dos requisitos de segurança, pode ser necessário ir além: inspeção de camada 7, filtragem por Nome de Domínio Totalmente Qualificado (FQDN), e proteção via regras gerenciadas de Sistema de Detecção e Prevenção de Intrusões (IDS/IPS). Além disso, saber exatamente qual pod ou serviço gerou um tráfego bloqueado é fundamental para investigações e auditorias.

A solução: regras baseadas em atributos de containers

A AWS introduziu o suporte a regras baseadas em atributos de containers no Network Firewall. Com esse recurso, é possível definir políticas de firewall usando atributos nativos do Kubernetes — como namespaces, nomes de pods, nomes de clusters e labels — em vez de depender de IPs efêmeros.

O funcionamento é direto: ao criar uma associação de container (container association) vinculada ao cluster EKS, o Network Firewall passa a descobrir e monitorar automaticamente os pods que correspondem aos atributos definidos, resolvendo-os para seus endereços IP atuais. Quando pods escalam, reiniciam ou migram entre nós, o mapeamento de IP é atualizado em tempo quase real — sem necessidade de intervenção manual ou edição de regras.

Em ambientes com múltiplos clusters, o recurso viabiliza inspeção centralizada de tráfego entre clusters para qualquer tráfego que passe pelo endpoint do firewall.

Outro benefício relevante é o enriquecimento dos logs de alerta com contexto de container. Os logs agora incluem um novo campo de metadados com o nome da associação de container relacionada à regra que foi acionada. Isso permite que equipes de segurança rastreiem tráfego bloqueado, permitido ou alertado diretamente até a workload de origem. Esses logs enriquecidos são exportados para o Amazon CloudWatch Logs e para o Amazon Simple Storage Service (Amazon S3), de onde podem ser encaminhados para o SIEM de preferência da equipe.

Vale destacar: o recurso está incluído no plano base do Network Firewall, sem custo adicional.

Como funciona na prática

O Network Firewall monitora continuamente o cluster EKS em busca de eventos de ciclo de vida dos pods (criação e exclusão) nos namespaces cobertos pela definição da associação de container. Essa definição é armazenada em uma associação de container, indexada por nome e valor de atributo.

Após a publicação, esses grupos de atributos são referenciados nas regras Suricata usando aliases com o prefixo @. Veja alguns padrões comuns:

Regra por grupo de pods — Permitir apenas pods do serviço de pagamento para acessar o gateway externo via TLS:

pass tls @ecommerce_pods any -> any 443 (msg:"allow ecommerce to payment gateway"; tls.sni; content:"checkip.amazonaws.com"; flow:to_server,established; sid:1; rev:1;)

Regra de aplicação de camada 7 — Bloquear todos os pods de acessar destinos maliciosos:

drop tls @all-pods any -> $EXTERNAL_NET any (msg:"Block malicious sites"; aws_domain_category:malicious-sites; sid:10; rev:1;)

No momento da avaliação de pacotes, o Network Firewall expande cada referência @ contra o catálogo atual de IPs. Quando pods escalam, reiniciam ou se movem entre nós, o controlador atualiza a associação de grupo e o firewall absorve os novos IPs — sem edições de regras ou intervenção do operador.

Passo a passo: configurando o recurso

O recurso pode ser configurado pelo console da Amazon Virtual Private Cloud (Amazon VPC), pela Interface de Linha de Comando da AWS (AWS CLI) ou pelo AWS SDK.

Pré-requisito: é necessário ter um Network Firewall já configurado para filtrar tráfego na VPC. Caso ainda não tenha, a documentação oficial tem um guia de introdução ao AWS Network Firewall.

Passo 1 — Criar a associação de container

No console do Amazon VPC, acesse Network Firewall e selecione Container associations. Clique em Create container association e preencha:

• Um nome e uma descrição opcional para a associação;
• Em Cluster configuration, selecione o tipo de cluster e escolha o cluster EKS desejado;
• Em Attribute filters, configure os atributos EKS para identificar quais pods serão associados. Por exemplo: Attribute key como namespace e Attribute value como ecommerce.

Passo 2 — Criar a regra de firewall baseada em atributos

Ainda no console do Amazon VPC, acesse Network Firewall rule groups e clique em Create rule group. Configure:

• Rule group type: Stateful rule group;
• Rule group format: Suricata compatible rule string;
• Rule evaluation order: Strict order.

Na próxima etapa, defina nome, descrição e capacidade para o grupo de regras. Em seguida, na seção IP set references, insira um nome de variável e selecione a associação de container criada no passo anterior como Resource ID.

No campo Suricata compatible rule string, insira as regras desejadas. O exemplo utilizado no artigo original da AWS é:

pass tls @ecommerce_pods any -> any any (msg:"allow ecommerce to payment gateway"; flow:to_server; tls.sni; dotprefix; content:".checkip.amazonaws.com"; endswith; nocase; alert; sid:101; rev:1;)
reject tls @ecommerce_pods any -> any 443 (msg:"block ecommerce pods to external ecommerce website"; flow:to_server; tls.sni; dotprefix; content:".amazon.com"; endswith; nocase; alert; sid:104; rev:1;)

Confirme as configurações e crie o grupo de regras.

Testando as regras

Para verificar se as regras estão funcionando corretamente, o teste pode ser feito com o comando curl em um pod do namespace ecommerce:

Teste 1 — Tráfego permitido:

kubectl exec -n ecommerce deployment/payment-service -- curl -sk --max-time 5 -w "\nHTTP_CODE:%{http_code}\n" https://checkip.amazonaws.com/
HTTP_CODE:200

Teste 2 — Tráfego bloqueado:

kubectl exec -n ecommerce deployment/payment-service -- curl -sk --max-time 5 https://www.amazon.com 2>&1
curl: (35) Recv failure: Connection reset by peer
command terminated with exit code 35

No primeiro caso, a requisição ao gateway de pagamento retorna HTTP 200, pois a ação pass está definida na regra. No segundo, a conexão é recusada com o código de saída 35, porque a ação reject está configurada para aquele destino.

Considerações importantes antes de adotar o recurso

A AWS destaca alguns pontos de atenção que merecem avaliação antes de colocar o recurso em produção:

• Source NAT (SNAT) deve estar desabilitado. Para que o Network Firewall consiga enxergar os IPs dos pods, o SNAT não pode estar ativo. Se estiver habilitado, apenas o IP do nó ficará visível, impedindo o controle granular no nível de pod.
• Tráfego pod-a-pod no mesmo nó não é coberto. O recurso não consegue inspecionar tráfego entre pods que estejam no mesmo nó, pois esse tráfego não passa pelo endpoint do Network Firewall. Para esse cenário, uma solução complementar é necessária.
• Impacto de desempenho variável. O impacto pode variar conforme a complexidade das regras e o volume de tráfego.

O que muda na prática para equipes de segurança

A principal mudança é conceitual: em vez de rastrear IPs que mudam constantemente, as equipes passam a trabalhar com identidades estáveis — namespaces, labels e nomes de pods. Isso aproxima a linguagem das regras de firewall da linguagem operacional do Kubernetes, tornando as políticas mais legíveis, auditáveis e fáceis de manter.

O enriquecimento dos logs com contexto de container é outro ganho direto para operações de segurança. Com o rastreamento até a workload de origem, investigações de incidentes e relatórios de conformidade ficam significativamente mais eficientes.

Para workloads de IA/ML no EKS — que costumam ter padrões de tráfego específicos e requisitos de isolamento elevados — o recurso oferece uma camada de controle que antes era difícil de implementar sem soluções customizadas.

Fonte

Secure Amazon container workloads using container attribute-based rules in AWS Network Firewall (https://aws.amazon.com/blogs/security/secure-amazon-container-workloads-using-container-attribute-based-rules-in-aws-network-firewall/)