In this blog post Securing AKS Ingress Why the ALB Controller 1.12.4 Update Matters we will explain what the update changes, why it matters to your risk profile, and how to roll it out without disrupting customer-facing applications.
If your business runs applications on Azure Kubernetes Service, or AKS, the entry point for customer traffic can easily become an overlooked security dependency. The application may be patched and the AKS cluster may be healthy, while the controller managing incoming traffic remains several releases behind.
As at 24 October 2026, Microsoft lists version 1.12.4 as the latest Helm release of the ALB Controller. Microsoft describes the release as containing security patches, making it an update that should be assessed promptly rather than left for the next major infrastructure project.
What the ALB Controller actually does
Application Gateway for Containers is Azure’s traffic management service for applications running in Kubernetes. In plain English, it decides how requests from customers, employees and connected systems reach the correct application inside your AKS environment.
CPI Consulting helps organisations design, build and secure Azure AI solutions, from Azure OpenAI and Microsoft Foundry to agents, governance and production deployment.
Visit CPI ConsultingThe ALB Controller is a small application running inside the AKS cluster. It reads Kubernetes routing instructions and translates them into configuration for Application Gateway for Containers.
Think of it as the coordinator between your development teams and Azure’s managed traffic gateway. Developers describe where traffic should go, while the controller keeps the Azure service aligned with those instructions.
The customer-facing traffic is processed by an Azure-managed data layer outside the cluster. However, the controller remains a critical control component because it can influence routes, listeners, certificates and other traffic settings.
Why a security-only update still matters
Version 1.12.4 is not being promoted as a large feature release. Microsoft currently describes it simply as containing security patches and does not publicly list specific vulnerabilities in the release note.
That limited detail is not a reason to ignore it. It means technology leaders should treat the release as a risk-management decision, assess exposure and compatibility, and document why the update was either deployed or deferred.
1. Ingress is part of your external attack surface
Ingress is the path internet traffic takes into applications running in Kubernetes. If that path is misconfigured or its management components are outdated, the consequences can include service outages, unintended exposure or traffic being sent to the wrong destination.
Updating the controller reduces the period during which your organisation relies on older components with known or internally identified weaknesses. The business outcome is straightforward: less avoidable exposure around systems that customers may use every day.
2. The controller has an important orchestration role
The ALB Controller uses Kubernetes and Azure interfaces to keep traffic configuration synchronised. This makes it more than a passive monitoring tool.
A weakness in a controller may affect the reliability or integrity of the configuration process, even when the application code itself is secure. Security reviews should therefore cover controllers, operators and add-ons, not only AKS nodes and business applications.
3. Delayed patching becomes a governance problem
For Australian organisations, patching infrastructure components supports the intent of the Essential Eight, the Australian government’s baseline cybersecurity framework. It also provides stronger evidence for cyber insurance reviews, customer questionnaires and internal audits.
The goal is not to install every release immediately. The goal is to have a repeatable process for identifying, testing, approving and recording security updates.
If nobody can quickly say which ALB Controller version is deployed, who owns it and when it was last reviewed, the larger problem is operational visibility.
Check compatibility before approving 1.12.4
The most important detail is that the Helm release of ALB Controller 1.12.4 requires Kubernetes 1.32 or later. It uses Gateway API 1.5.1 and Gateway API Inference Extension 1.3.1.
Gateway API is the Kubernetes standard used to describe how traffic should enter and move between services. The Inference Extension adds routing capabilities for self-hosted AI models.
If your AKS cluster is older than Kubernetes 1.32, the answer is not to force the controller update. You may need to plan an AKS upgrade first or select a controller release supported by your current environment.
Start by confirming the versions currently in use:
kubectl version
kubectl get deployment -n azure-alb-system -o wide
helm list -A | grep alb-controllerThe deployment output should show the controller image and version. Also confirm whether the controller was installed with Helm or enabled as an AKS add-on, because the maintenance process is different.
Helm installations and AKS add-ons are not the same
For Helm-managed deployments, your team controls the controller version and upgrade timing. Version 1.12.4 can be planned once the AKS version, routing definitions and configuration values have been checked.
For the AKS add-on, Microsoft automatically applies supported controller updates. The add-on uses a controller version pinned to the AKS and managed Gateway API versions, so you should not assume that every cluster should immediately report 1.12.4.
This distinction prevents a common mistake: comparing a managed add-on with the latest Helm release and treating the version difference as an automatic security failure.
A practical upgrade plan
- Inventory the current environment. Record the AKS version, controller version, installation method, Gateway API resources, certificates and Web Application Firewall policies.
- Review release compatibility. Confirm that the cluster meets the Kubernetes 1.32 minimum for the 1.12.4 Helm release.
- Back up the configuration. Export Helm values and the relevant Kubernetes routing resources before making changes.
- Test outside production. Validate login pages, APIs, redirects, health checks, certificate handling and important customer transactions.
- Deploy with rollback ready. Schedule the production change, monitor it closely and retain the previous configuration until testing is complete.
A controlled Helm upgrade may follow this pattern, using a reviewed values file rather than relying on unexamined defaults:
helm get values alb-controller -n azure-alb-system -o yaml > alb-controller-values-backup.yaml
helm upgrade alb-controller oci://mcr.microsoft.com/application-lb/charts/alb-controller --namespace azure-alb-system --version 1.12.4 -f reviewed-values.yaml --atomic --wait --timeout 10m
kubectl get deployment -n azure-alb-system -o wide
kubectl get pods -n azure-alb-systemThe exact command should match your existing release name, namespace and identity configuration. Do not copy an upgrade command into production without first comparing the existing and new chart settings.
Do not confuse controller patching with complete ingress security
Installing 1.12.4 does not automatically enable a Web Application Firewall, secure your certificates or fix unsafe routing rules. Those controls still require deliberate configuration and testing.
For example, Application Gateway for Containers requires both an Azure security policy and a matching Kubernetes Web Application Firewall policy before traffic is inspected. Seeing a firewall policy in the Azure portal does not, by itself, prove that protection is active.
TLS certificates also need their own lifecycle and protection plan. For environments with strict private-key requirements, our guide to Azure Application Gateway keyless TLS explains how protected hardware can reduce certificate-key exposure.
Organisations routing AI workloads should also review who can create or modify AI routes, how usage is monitored and where approval controls sit. These questions connect directly with the principles in our article on designing a secure control plane for enterprise AI agents.
What this looks like in a real environment
Consider a 200-person software business running customer APIs on AKS. Its application images were scanned weekly, but the networking controllers had no named owner and were only reviewed during major platform upgrades.
The immediate issue was not a confirmed breach. It was that the business could not demonstrate whether ingress-related security updates had been assessed, creating unnecessary uncertainty for management and customer assurance teams.
By adding controller versions to the monthly vulnerability review, testing updates in a staging cluster and assigning ownership to the platform team, the company reduced both technical risk and audit effort. Future releases became routine changes rather than emergency projects.
The decision for technology leaders
ALB Controller 1.12.4 matters because ingress security depends on maintained control components, not just secure application code. Helm-managed environments on Kubernetes 1.32 or later should assess and test the update promptly, while add-on users should verify their AKS-supported release path.
CloudProInc brings more than 20 years of enterprise IT experience across Azure, AKS, Microsoft 365, Defender and Wiz cloud security. As a Melbourne-based Microsoft Partner and Wiz Security Integrator, we focus on practical improvements that reduce risk without creating unnecessary disruption.
If you are not sure which ALB Controller version you are running, whether your ingress is genuinely protected, or whether an upgrade could affect production traffic, we are happy to take a look — no strings attached.