Back in November I wrote about Flatcar Container Linux landing on AKS in preview. The short version was that it was a promising immutable OS worth testing for cloud-native workloads, but rough around the edges as a preview. Well, Microsoft has now taken that foundation and turned it into something more production-ready. At Microsoft Build 2026, they announced the general availability of Azure Container Linux (ACL), and the backstory behind it is worth knowing. Microsoft acquired Kinvolk in 2021, the company behind Flatcar, bringing that expertise directly into Azure. They then donated Flatcar to the Cloud Native Computing Foundation (CNCF) to keep it community-driven. ACL is the result of that investment: Flatcar’s proven immutable design with Azure Linux packages, Microsoft’s supply chain processes, and proper platform integration layered on top. It is now GA on AKS starting with Kubernetes v1.34.
What ACL actually is
ACL is not just Flatcar with a new name. It is derived from the Flatcar Container Linux project and keeps the same container-first, immutable design, but layers in Azure Linux packages, Microsoft’s supply chain processes, and tighter Azure platform integration. Think of it as Flatcar with Azure Linux’s signed packages, secure build pipelines, and native support for Trusted Launch baked in.
The key difference from the preview you may have already tested is that ACL ships as a fully supported, Microsoft-managed OS SKU with weekly image updates, GA-level support from AKS v1.34 onwards, and a proper security stack that includes SELinux in enforcing mode, Trusted Launch, Secure Boot, and dm-verity on the /usr directory.
That last one is worth paying attention to. The kernel validates a signed root hash against the /usr partition at boot and runtime, blocking tampering even if something manages to escape a container. Combined with SELinux enforcing mode and Secure Boot via a Unified Kernel Image (UKI), this is a meaningfully harder target than a general-purpose Linux node.
What changed from the Flatcar preview
If you tested Flatcar on AKS last year, there are a few things to know before you assume ACL works the same way.
The --os-sku value has changed. The Flatcar preview used --os-sku Flatcar. ACL uses --os-sku AzureContainerLinux. The AKSFlatcarPreview feature flag registration step is gone entirely. ACL is GA and requires no feature flag.
Trusted Launch is now mandatory. You cannot create an ACL node pool without it, so Gen 1 VM sizes are out. If your existing cluster uses Gen 1 SKUs, you will need to plan around that. On ARM64, you will need Cobalt v6 SKUs specifically for Trusted Launch compatibility.
The SecurityPatch and Unmanaged node OS upgrade channels are not supported. You are limited to NodeImage or None. That makes sense given the immutable /usr directory, but it is worth checking your existing upgrade channel configuration before adding an ACL pool to a running cluster.
OS Guard (currently in preview) will eventually be retired once its code integrity features are folded into ACL. If you are already using OS Guard, the recommendation is to stay there for now and migrate once ACL absorbs those capabilities.
Deploying an ACL cluster
No feature registration needed. You just need Azure CLI 2.86.0 or higher.
Create a resource group and set your variables:
|
1 2 3 4 5 |
export MY_RESOURCE_GROUP_NAME="pixelrobots-acl-rg" export REGION="uksouth" export MY_AKS_CLUSTER_NAME="pixelrobots-acl-aks" az group create --name $MY_RESOURCE_GROUP_NAME --location $REGION |
Then create the cluster with the ACL OS SKU:
|
1 2 3 4 5 6 |
az aks create \ --resource-group $MY_RESOURCE_GROUP_NAME \ --name $MY_AKS_CLUSTER_NAME \ --os-sku AzureContainerLinux \ --node-count 3 \ --generate-ssh-keys |
That is all there is to it. No feature flags, no preview extensions, just --os-sku AzureContainerLinux and you will have a three-node cluster running on ACL nodes with Trusted Launch, SELinux enforcing, and dm-verity (a Linux kernel feature that cryptographically verifies the integrity of the OS partition at runtime) active after a few minutes.
Grab credentials and verify the nodes are up:
|
1 2 3 4 5 |
az aks get-credentials \ --resource-group $MY_RESOURCE_GROUP_NAME \ --name $MY_AKS_CLUSTER_NAME kubectl get nodes |
You can also add an ACL node pool to an existing cluster:
|
1 2 3 4 5 6 |
az aks nodepool add \ --resource-group $MY_RESOURCE_GROUP_NAME \ --cluster-name $MY_AKS_CLUSTER_NAME \ --name aclpool \ --node-count 3 \ --os-sku AzureContainerLinux |
To confirm the node image version running on your pool:
|
1 2 3 4 |
az aks nodepool list \ --resource-group $MY_RESOURCE_GROUP_NAME \ --cluster-name $MY_AKS_CLUSTER_NAME \ --query '[].{name: name, nodeImageVersion: nodeImageVersion}' |
The version format follows AKS date-based naming, so you will see something like AKSAzureContainerLinux-202606.01.0. ACL ships weekly node image updates, so that number should tick along nicely without manual intervention when you are on the NodeImage upgrade channel.
SELinux in enforcing mode
This is the part most likely to cause friction when you first start deploying workloads. SELinux runs in enforcing mode by default on ACL, and it will block things it does not like without much warning. If a workload behaves correctly on Ubuntu or standard Azure Linux but silently fails or crashes on ACL, SELinux is the first thing to check.
Microsoft has added a node pool tag that lets you switch a pool to permissive mode for troubleshooting without having to rebuild anything. Apply the tag to an existing pool:
|
1 2 3 4 5 6 |
az aks nodepool update \ --resource-group $MY_RESOURCE_GROUP_NAME \ --cluster-name $MY_AKS_CLUSTER_NAME \ --name aclpool \ --tags acl-node-security-profile="selinux=permissive" \ --no-wait |
Restart the nodes after the update. You can verify the mode by connecting to a node with kubectl debug, chrooting into the host filesystem, and running sestatus. The Current mode line in the output should show permissive if the tag has taken effect.
Switch back to enforcing mode by removing the tag or replacing the value with selinux=enforcing. Do not leave nodes in permissive mode in production, it defeats a core part of the security model.
What to watch for in production
The immutable /usr directory is still the main constraint, and everything I noted in the Flatcar post still applies. DaemonSets that mount /host and try to write to the filesystem will fail. Init containers that run apt-get install to add OS-level packages will not work. Anything that expects to modify the node at runtime needs to be rethought.
The new SELinux enforcement layer adds another dimension to this. Privileged containers or workloads with unusual host access patterns may hit SELinux denials that never surfaced on other OS options. The permissive mode toggle above is specifically for diagnosing these cases; use it, collect your audit.log entries, and then figure out whether the workload needs adjustment or whether a custom SELinux policy is appropriate.
Pod Sandboxing is not supported, so if that is in your requirements you will need to look elsewhere.
Where to go from here
ACL is the GA release of what started as the Flatcar preview. If you tested Flatcar on AKS last year, this is the official upgrade path, and the docs include an in-place OS SKU migration guide if you want to move existing node pools rather than rebuilding from scratch.
For new clusters, ACL is worth treating as your default for security-sensitive or compliance-driven workloads. The immutability, SELinux enforcement, and Trusted Launch stack is a meaningfully stronger baseline than Ubuntu or standard Azure Linux, and it comes without the operational overhead of managing those layers yourself.
The constraints have not changed from the preview, so audit your workloads before you commit. Anything that modifies the node at runtime, writes to host paths, or relies on installing packages outside of a container will need reworking. That is not a reason to avoid ACL; it is just the work that comes with moving to an immutable OS. The permissive SELinux mode toggle is useful for getting through that audit without having to spin up separate infrastructure.
OS Guard users should hold for now. The plan is for ACL to absorb OS Guard’s code integrity features in a future release, at which point OS Guard will be retired. Microsoft is tracking this on the Azure Linux feature roadmap.
0 Comments