Azure Container Linux (ACL): making immutable infrastructure practical at scale

FloraTaagen

Microsoft

Nov 10, 2026

Where we left off…

At Microsoft //Build 2026, we introduced Azure Container Linux (ACL) , an immutable, container-optimized OS for Azure Kubernetes Service (AKS) bringing greater consistency, reduced operational overhead, and a stronger default security posture to your nodes. Since GA, we’ve focused on helping customers operate ACL more effectively as their environments scale and security requirements evolve.

Today, we’re announcing the next set of capabilities: simpler fleet scaling, hardware-backed protection for sensitive workloads, and new ways to assess code integrity and software vulnerabilities. These updates bring more of ACL’s benefits into your day-to-day operations. We’re also sharing what’s next for OS updates, an important part of making immutable infrastructure practical at scale.

Stronger security shouldn’t complicate fleet management

As Kubernetes environments grow, small differences between nodes become harder to track. Various platform components may install or update software independently, and non-deterministic package updates can cause hosts that started from the same baseline to gradually diverge over time. Direct changes made during troubleshooting can further contribute to this drift. These differences complicate upgrades, make incidents harder to reproduce, and create uncertainty about what is running in production.

ACL addresses these challenges with an image-based operating system and a read-only /usr filesystem backed by dm-verity. Core OS components, including system binaries and kernel modules, remain consistent with the image you deployed and across your fleet, helping prevent OS-level configuration drift and potential tampering. A minimal package set also reduces the number of components you need to maintain and the potential exposure to vulnerabilities in packages your workloads don’t need.

Node consistency is the foundation, but scaling a fleet also means matching capacity to changing workload needs. As your workloads grow, managing capacity shouldn’t mean spending more time configuring node pools. ACL now supports node auto-provisioning (NAP) in AKS, which automatically selects VM sizes and provisions nodes based on workload resource requirements. This is particularly useful for agentic workloads, where agents can launch parallel jobs and short-lived tasks that create unpredictable compute demand. NAP reduces manual node pool configuration and management, so you can automatically scale with demand while retaining ACL’s immutable OS protections. See Configure NAP with ACL for prerequisites and setup instructions.

Layering OS protection with confidential computing and code integrity

ACL provides layered protection for the operating system. As AI helps attackers analyze newly disclosed vulnerabilities and develop exploits faster than ever, the time between CVE disclosure and active exploitation continues to shrink. Immutability helps protect core OS components from modification, while SELinux restricts process access to limit the impact of a potential compromise. Trusted Launch protects the boot chain, with Secure Boot validating a signed Unified Kernel Image (UKI) that bundles the kernel, initial RAM disk, and kernel command line. Together, these controls help defend against tampering, reduce opportunities for persistence, and contain threats.

Today, we’re extending these OS protections to confidential virtual machines (CVMs), combining ACL’s immutable foundation with hardware-backed protection for data in use on both Intel TDX and AMD SEV-SNP platforms. We’re also introducing FIPS-enabled CVM images for workloads that require FIPS-mode cryptography, making the ACL the only OS on AKS to offer this configuration.

Alongside these protections teams need assurance that executable code comes from trusted, integrity-protected sources. Integrity Policy Enforcement (IPE) addresses this need by evaluating file-backed execution against policies based on a file's integrity properties. Originally developed at Microsoft to enforce code integrity across Azure infrastructure, IPE became part of the mainline Linux kernel in version 6.12. IPE complements SELinux by answering a different question. While SELinux controls what a process is allowed to do, IPE helps verify that the code being executed originates from trusted sources. Together, they provide both access control and code integrity protections.

On ACL, support for IPE is currently focused on evaluation through an optional audit mode. ACL includes an IPE policy that permits file-backed execution only from dm-verity-backed devices with trusted root hashes. When audit mode is enabled, IPE records execution attempts that would violate the policy without blocking them, helping operators understand where workloads or operational practices diverge from a trusted-execution model.

To learn more about enabling IPE audit mode in ACL and inspecting the resulting logs, see Enabling IPE for ACL.

An immutable host still needs to fit your security assessment process

When it comes to securing your fleet, platform teams need to assess host configurations, inventory software components, and identify known vulnerabilities using their existing tools and processes. The ACL CIS Benchmark and embedded software package inventories, published in SPDX format, support these efforts with security configuration guidance and software inventories for use with your existing security scanners.

The CIS Benchmark for Azure Container Linux (ACL) is now generally available, giving teams a community-developed baseline for assessing node OS security. Its configuration recommendations help platform and security teams identify gaps, prioritize remediation, and conduct consistent reviews without defining assessment criteria from scratch. The latest benchmark can be found here: CIS Azure Linux Benchmarks.

Further, Kubernetes users depend on a broad ecosystem of security scanners to assess vulnerabilities. Because ACL nodes do not include an RPM database or a traditional package manager, scanners cannot query installed packages as they would on a general-purpose OS. Instead, each ACL image now includes an embedded software bill of materials (SBOM) in Software Package Data Exchange (SPDX) 2.2 JSON format, listing the components included in the image. Scanners that integrate with this manifest can use the inventory to identify known vulnerabilities.

This gives you inspectable evidence of image contents to incorporate into existing security reviews through compatible scanning tools. If you’re a security or vulnerability-scanning provider interested in integrating with ACL’s embedded SBOM manifests, reach out to: AzureLinuxPartners@microsoft.com.

Bring immutable infrastructure to your fleet

Today’s updates make Azure Container Linux easier to adopt and operate for containerized workloads at scale. Looking ahead, we're exploring support for A/B OS updates to further minimize upgrade disruption, reduce downtime, and simplify rollback scenarios. Stay tuned for future updates as this capability progresses on our roadmap.

We’re excited to see what you build on the Azure Container Linux foundation, from established services to emerging agentic workloads. Try ACL in your AKS clusters and let us know what works well and what you'd like to see on our roadmap. Your feedback will help shape what comes next.

Get started with deployment guidance and best practices at: aka.ms/azurecontainerlinux.