AWS Network Firewall يستبدل IPs Ephemeral Pod باستخدام قواعد أساسية

From today, you can ditch the endless cycle of updating firewall rules every time a Kubernetes pod restarts. AWS Network Firewall now lets you write rules using native container attributes – namespace, pod name, cluster name, labels – instead of chasing ephemeral pod IPs.

That means a Suricata rule like pass tls @ecommerce_pods any -> any 443 automatically resolves whatever IPs the ecommerce namespace pods currently hold. When pods scale or restart, the firewall picks up the new IPs in near real-time. No human in the loop.

How Attribute-Based Rules Solve the Ephemeral IP Problem

Kubernetes Network Policies give you basic L3/L4 controls, but they can't do Layer 7 inspection, FQDN filtering, or managed IDS/IPS. AWS Network Firewall already does all that – except you had to write rules against CIDRs and subnets that shift constantly. The new feature creates a container association that links your EKS (or ECS) cluster to the firewall. The association defines attribute filters (e.g., namespace = ecommerce). At packet evaluation time, the firewall expands each @ variable against a live catalog of pod IPs.

Alert logs now carry a metadata field with the container association name. Security teams can trace blocked traffic back to the exact workload – no more guessing which pod triggered the drop.

Real-World Example: Blocking Payment Pods from Reaching Malicious Sites

The blog walks through a concrete setup: an EKS cluster with a payment-service deployment in the ecommerce namespace. Two Suricata rules demonstrate the capability:

• pass tls @ecommerce_pods any -> any any with tls.sni content ".checkip.amazonaws.com" – allows requests to the payment gateway.
• reject tls @ecommerce_pods any -> any 443 with tls.sni content ".amazon.com" – blocks external ecommerce sites.

Testing via kubectl exec shows the first curl returns HTTP 200, the second gets Connection reset by peer. That's granular, dynamic policy without a single IP address in the rule.

What You Give Up: Pod-to-Pod Traffic and SNAT Requirements

Two gotchas: Source NAT must be disabled on the pod subnet, otherwise the firewall only sees the node IP and can't do pod-level egress controls. And traffic between pods on the same node never hits the firewall – that path still needs a separate solution like a sidecar or eBPF.

Performance impact depends on rule complexity and volume, but the feature itself incurs no extra charge – it's part of the base Network Firewall tier.

For teams running EKS with strict compliance requirements, this feature collapses the gap between container orchestration and network security – expect SIEM enrichment and cross-cluster inspection to become the new norm.

Source: Secure Amazon container workloads using container attribute-based rules in AWS Network Firewall
Domain: aws.amazon.com