[Feature] [Application Gateway for Containers] Ability to set the public IP for whitelisting

[winromulus]

Is your feature request related to a problem? Please describe.

Application Gateway for Containers (AGfC) frontends using ALB controller are assigned auto-generated anycast IP addresses that cannot be controlled or predicted. This is a blocker for enterprise scenarios where external partners and vendors need to allowlist our service endpoints in their outbound firewall rules. Since the anycast IPs assigned to AGfC frontends can change without notice and are not customer-controlled, partners cannot reliably configure their firewalls to reach our services. Today, the only way to expose Kubernetes workloads behind a stable, known public IP is through alternatives that each have significant drawbacks (see below). Without BYO public IP support on AGfC frontends, organizations that serve partner-facing APIs and services cannot adopt AGfC as their primary ingress solution.

Describe the solution you'd like

Support for associating a customer-owned static Azure Public IP address (Standard SKU) with an AGfC frontend, either through:

1. A Kubernetes annotation on the Gateway or Ingress resource (e.g., alb.networking.azure.io/frontend-ip-resource-id) that references an existing Azure Public IP resource, or
2. A property on the AGfC Frontend ARM resource that accepts a Public IP resource ID, which the ALB controller can then expose via Gateway/Ingress configuration.

Describe alternatives you've considered

• NGINX Ingress Controller (community): Supports static PIP via loadBalancerIP on the Service. However, the https://github.com/kubernetes/ingress-nginx project is being discontinued (archived), making it an unsuitable long-term solution.
• Application Gateway Ingress Controller (AGIC): Supports static PIP through the App Gateway v2 SKU. However, AGIC only supports the Ingress API and does not support the Gateway API, limiting its future applicability as the ecosystem moves toward Gateway API as the standard.
• NGINX Gateway Fabric: Supports Gateway API but relies on a cloud provider LoadBalancer for its data plane services, which brings us back to needing a stable IP on the load balancer — not on the gateway controller itself.
• CNAME-based allowlisting: Partners could allowlist the AGfC FQDN (e.g., *.fz78.alb.azure.com) instead of IPs. In practice, most enterprise firewalls require IP-based rules for outbound traffic, and the anycast IPs behind the FQDN can change without notice, making this unreliable.
• Azure Front Door in front of AGfC: Adds a stable anycast layer, but introduces unnecessary cost, latency, and architectural complexity for what should be a simple IP pinning requirement.

Additional context

• AGfC is positioned as the successor to both AGIC and classic Application Gateway for Kubernetes workloads, and is the only Azure-native ingress controller that supports both Ingress API and Gateway API. Static IP support would remove the last major blocker preventing migration from AGIC to AGfC in regulated and partner-facing environments.
• Application Gateway v2 (non-containers) already supports BYO static public IPs on frontends — parity with this capability is expected.
• Common industries affected: healthcare, financial services, payments, and any B2B integration scenario where partner outbound firewall allowlisting is a contractual or compliance requirement.

[microsoft-github-policy-service]

@JackStromberg, @chasewilson would you be able to assist?

[JackStromberg]

Thank you for your feedback. This is not currently planned, but we will leave open to gather feedback.

In general, we'd recommend allowlisting traffic via your firewall or proxy to the FQDN used with your deployment.

E.g. FQDN filtering with Azure Firewall: https://learn.microsoft.com/en-us/azure/firewall/fqdn-filtering-network-rules