The Firewall Can Read Kubernetes Labels Now. Secure the Label Maker.

Container security has long forced network teams to write policy in a language the workload does not speak. The application is “payments in production.” The firewall sees 10.42.17.93—until the pod disappears and that address belongs to something else.

AWS Network Firewall’s container attribute-based rules, generally available since June, close much of that translation gap. A rule group can reference Amazon EKS attributes including cluster, namespace, workload, service account, pod, and labels, or Amazon ECS attributes such as cluster and container instance. AWS maintains dynamic IP sets from container lifecycle changes and enriches firewall logs with the resolved container context.

That is a major architectural improvement. It also moves trust. The policy no longer depends only on who controls the firewall and the route table. It depends on who may create a namespace, edit a deployment label, select a service account, or alter the path traffic takes. When a label can open an egress path, the label is no longer metadata. It is a security credential.

What AWS changed

The feature creates an association between Network Firewall and an EKS cluster or ECS infrastructure. Monitoring configurations select the container attributes Network Firewall should follow. The service subscribes to lifecycle changes and translates matching resources into dynamic address sets, which stateful rules can reference alongside domains, FQDNs, protocols, and ports.

For EKS, that creates policies operators have wanted for years: permit only pods labeled data-class=public to reach a third-party enrichment API; allow a named namespace to contact an approved package repository; deny a service account from reaching an administrative network. For ECS, cluster and container-instance context provide a similar bridge. The feature carries no additional charge beyond normal Network Firewall processing and endpoint charges.

The association must be in the same account and Region as the protected resource. An association supports up to five monitoring configurations, and the default adjustable quota is 100 associations per account per Region. Those are design constraints for large multi-cluster estates, not footnotes to discover after standardizing a landing zone.

Labels become authorization inputs

Kubernetes labels were designed to organize and select objects. Many organizations allow application teams broad freedom to set them. That freedom is incompatible with a label that grants network access.

Reserve a prefix for security-significant attributes, such as security.example.com/egress-profile. Enforce allowed values and eligible namespaces with an admission controller. Prevent workload deployers from changing protected labels unless the change passes an approved delivery path. Where a service account drives policy, restrict who can bind it and prevent arbitrary token use.

Do not derive high-consequence access from a single mutable label. Combine stable context—cluster and namespace—with a protected workload label, and constrain destination and protocol in the firewall rule. “Any pod labeled trusted may reach anywhere” is merely an IP allowlist with easier self-service escalation.

The control should fail safely. A pod missing a required label should receive the baseline-deny profile, not disappear from governance. Admission should reject ambiguous or conflicting profiles before the pod is scheduled.

The firewall only sees traffic that reaches it

Semantic policy can create dangerous confidence if routing coverage is assumed. AWS explicitly requires source network address translation to be disabled so the firewall can see the pod address that the dynamic set contains. If an intermediate device rewrites the source, the workload identity is lost.

Traffic between pods on the same node may never traverse the Network Firewall endpoint. East-west traffic may follow different paths from north-south egress. Asymmetric routing can cause a stateful firewall to observe only half a conversation. Each architecture therefore needs a path matrix: pod to internet, pod to VPC service, pod to another node, same-node pod to pod, and ingress return traffic.

For every path, document whether it traverses the endpoint, which address is visible, and which control covers any gap. Kubernetes NetworkPolicy, a service mesh, security groups for pods, and Network Firewall solve overlapping but different problems. Container attributes do not turn a centralized egress firewall into a universal microsegmentation system.

Test with packets, not diagrams. Deploy controlled pods representing each profile, exercise allowed and denied destinations, and verify enriched firewall logs show the expected namespace, pod, and labels. Repeat after networking upgrades and cluster changes.

Account for identity propagation delay

Pods are ephemeral; “near real time” is not instantaneous. A new or relabeled pod can exist before every downstream association reflects its state. A terminating pod’s address can later be reused. The dynamic service greatly reduces manual race conditions, but security design still needs to bound the transition.

Use default-deny rules so a newly launched address does not inherit broad access while awaiting classification. Measure the observed delay during scale-out, rolling deployments, and node failure. Alert when association state is unhealthy or when expected container enrichment is absent from logs.

Avoid policies that require a short-lived batch pod to gain privileged connectivity immediately after creation unless the workload can wait for readiness. A readiness gate or startup check can confirm that its security identity is visible before processing sensitive work.

Enriched logs change investigations

The operational gain may be as valuable as enforcement. A flow record that includes cluster, namespace, pod, and workload context eliminates the fragile after-the-fact exercise of matching an old IP to a historical pod. That can shorten containment and make policy violations intelligible to an application owner.

Preserve the original network fields alongside the enrichment. Analysts should distinguish what the sensor observed from what the association inferred. Send both to the detection platform and include association health and attribute freshness where available.

Build detections for policy identity, not only destination. A production namespace adopting a development egress profile, a protected label appearing outside an approved deployment, or a service account reaching a first-seen FQDN may be more informative than a raw deny count. Correlate admission audit events with firewall decisions so investigators can see who changed the attribute that changed the path.

Separate rule ownership from label ownership

Network security should own the meaning and blast radius of each egress profile. Platform engineering should own the mechanism that maps approved workload declarations to protected attributes. Application teams should request profiles through code and own their destinations. Security operations should own monitoring and exception expiry.

That separation prevents two failure modes: a central firewall team manually chasing every application deployment, and application teams granting themselves new network privilege with an innocuous metadata edit. Policy-as-code can join the workflow: a pull request changes the destination set or eligible workload scope; tests prove both allow and deny cases; a reviewer sees the expected traffic and the maximum affected population.

A migration sequence that produces evidence

Start with one cluster whose egress already traverses Network Firewall. Inventory existing CIDR rules and identify those that approximate workload identity poorly. Create associations and log-only rules first. Compare the dynamic membership with Kubernetes and ECS inventory during normal churn.

Next, protect the labels with admission policy and delivery permissions. Convert a low-risk allowlist to an attribute rule, retain the old rule temporarily, and observe mismatches. Test SNAT, same-node, failover, and scale events. Then remove the old rule and measure denied connections, association lag, rule hit rates, and uncovered paths.

Scale by reusable egress profiles, not bespoke application labels. A small vocabulary—public web, approved SaaS, package mirrors, data services, and no egress—is easier to audit than hundreds of names that encode one team’s architecture.

Better language, same burden of proof

Network policy is strongest when it expresses business intent. Container attribute-based rules make that possible without forcing security teams to treat transient addresses as durable identities. But expressive policy is not automatically correct policy.

The organization must be able to prove who controls the attribute, how quickly it maps to an address, which paths reach the firewall, and what protects the paths that do not. Secure those four things and the firewall finally speaks the workload’s language. Ignore them and a friendly label becomes the shortest path around the perimeter.

Sources and reporting notes

• AWS Security Blog: Secure Amazon container workloads using container attribute-based rules, July 1, 2026.
• AWS announcement: container attributes referencing in Network Firewall, June 2026.
• AWS Network Firewall container associations documentation, consulted for prerequisites, quotas, and traffic limitations.

---

CloudDefender connects exposed paths with workload, network, and ownership context, helping teams prove that a semantic firewall rule protects the traffic—and the containers—they believe it does.