Azure Linux 4.0 and Azure Container Linux GA: Microsoft's Hardened OS for Cloud-Native and AI Workloads

Microsoft has been building its own Linux distribution for longer than most people realise. What started as CBL-Mariner — an internal distribution used across Azure infrastructure — has matured through three major versions into a legitimately interesting distro with a clear design centre: minimal attack surface, supply chain integrity, tight Azure integration, and now a specific focus on AI workload performance. The announcements at Open Source Summit North America 2026 on May 18th brought Azure Linux 4.0 into public preview and pushed Azure Container Linux to general availability. Both are worth understanding before you decide what runs your next AKS node pool.

The History in Brief

The naming history is confusing enough to deserve a table before anything else.

Azure Linux 2.0 reached end of support in November 2025; AKS stopped providing node images for it in March 2026. If you have node pools pinned to AL2, you are running without security patches. The migration path is straightforward — upgrade to AL3 now, AL4 when it hits GA in H2 2026.

What Changed in Azure Linux 4.0

The Fedora Upstream Shift

The most significant architectural change in 4.0 is the switch to Fedora as the upstream base. CBL-Mariner and Azure Linux 1.x–3.x were built from scratch — Microsoft maintained their own package sources, their own spec files, and their own toolchain. That gave tight control but meant a lot of reinvented wheels.

Azure Linux 4.0 inherits Fedora’s package ecosystem while Microsoft curates the subset that ships on Azure. Practically this means:

• Broader package availability without waiting for Microsoft to package something
• Faster security patches flowing from the Fedora/RHEL pipeline
• More familiar tooling for engineers who come from RHEL/CentOS/Rocky backgrounds
• The same RPM package format and TDNF/DNF package management as prior versions, but with access to a much larger package set

TDNF (Tiny DNF) remains the preferred package manager for container images and minimal installs; DNF is available for interactive use. Both point at Microsoft’s curated Azure Linux repositories.

Kernel and Runtime

Azure Linux 4.0 ships with a 6.6 LTS kernel with Microsoft’s Azure-specific patchset applied. The kernel is compiled with a hardened configuration:

• Retpolines — mitigation for Spectre variant 2
• Shadow Stack (CET-SS) — hardware-enforced return address protection on supported hardware
• Indirect Branch Tracking (IBT) — forward-edge CFI via Intel CET
• TIOCSTI disabled — closes a classic terminal injection attack vector
• kexec hardened — the file-based kexec syscall is retained, direct kexec is disabled

Python 3.12 is the system interpreter. The previous practice of shipping Python 3.9 or 3.10 as the system Python meant AL2/AL3 nodes were increasingly out of step with modern ML tooling requirements; 3.12 closes that gap.

Atomic A/B Updates

Azure Linux 4.0 adopts an image-based, atomic update model similar to Flatcar Container Linux and CoreOS. The base OS image is a signed, read-only snapshot. Updates are applied to a staged partition and activated on the next reboot, with automatic rollback if the new image fails health checks.

┌──────────────────────────────────────────────────────┐
│                  Azure Linux 4.0 Node                 │
│                                                       │
│   ┌─────────────────┐    ┌─────────────────────┐     │
│   │  Partition A     │    │  Partition B         │     │
│   │  (active image)  │    │  (staged update)     │     │
│   │  Signed, R/O     │    │  Signed, R/O         │     │
│   └────────┬────────┘    └──────────┬──────────┘     │
│            │                        │                 │
│            └──────────┬─────────────┘                 │
│                       │                               │
│            ┌──────────▼──────────────┐                │
│            │    /var, /etc (R/W)      │                │
│            │    Overlayfs on top      │                │
│            └─────────────────────────┘                │
└──────────────────────────────────────────────────────┘

The separation of the immutable OS layer from mutable runtime state (/var, /etc) means OS upgrades no longer require careful management of configuration drift. Your node configuration lives in the mutable layer; the OS itself is swapped atomically.

This is a significant operational improvement over AL3, which used a more traditional package-based update model that accumulated drift over time. For AKS node pools, it means image-based node rotation (the AL4 node image ships the new OS version, nodes are cycled) is simpler and more auditable.

TCMalloc-Azure

Microsoft contributed a custom memory allocator to AL4 called TCMalloc-Azure, derived from Google’s TCMalloc with optimisations specific to multi-tenant Azure VM workloads. The headline number from Microsoft’s OSS Summit benchmark: a Llama 4 70B model serving workload on AL4 with TCMalloc-Azure showed p99 token generation latency of 142ms versus 174ms on the same hardware running AL3. That’s an 18% reduction in tail latency without any application changes.

The improvement comes from reduced lock contention in the allocator under concurrent allocation patterns typical of LLM serving — many threads allocating and freeing similarly-sized tensor buffers. For workloads that don’t fit that profile (traditional web apps, simple microservices), the difference is smaller but generally non-negative.

Supply Chain: Signed Packages Only

Azure Linux 4.0 integrates with Azure Artifact Registry to enforce a signed-packages-only policy at the package manager level. Every package in the default repository is signed, and TDNF rejects unsigned packages by default. Combined with the signed OS images in the A/B update model, this gives AL4 a verifiable chain of custody from build to running node.

The ai-audit tool is new to AL4: it hooks into the kernel’s tracing subsystem to log access to GPU memory, model weights, and training data paths. The target audience is enterprises with compliance requirements around AI workloads — the audit trail feeds into Azure Monitor and can be used to demonstrate data residency and access controls to auditors.

Azure Container Linux: The Purpose-Built Container Host

Azure Container Linux (ACL) is a different product from Azure Linux 4.0, though the two are related. Where AL4 is a general-purpose VM OS, ACL is a stripped-down image with a single purpose: hosting containers. It went GA at OSS Summit alongside the AL4 preview.

What Got Removed

ACL starts from the Azure Linux base and removes everything that isn’t needed to run kubelet and containerd:

• No graphical subsystems
• No man pages or documentation
• No development headers or compilers
• No optional kernel modules for filesystems or hardware you’ll never attach
• No SSH server in the default image (access via Azure Serial Console or Bastion)

The result is an image under 300 MB that boots in under a second on modern Azure VM SKUs. For comparison, Ubuntu node images for AKS typically run 1.2–1.8 GB.

What Stays

• kubelet
• containerd
• systemd (minimal unit set)
• systemd-networkd
• Azure Linux Agent (walinuxagent) for VM provisioning
• auditd
• TDNF (for emergency package installation, not routine use)

Security Posture

ACL passes CIS Level 1 benchmarks out of the box — it’s the only AKS node OS that does. The attack surface reduction from stripping ~200+ packages compared to Ubuntu is real: fewer binaries means fewer CVEs, fewer patch cycles, and a smaller blast radius if a container escape occurs.

The read-only base layer (inherited from AL4’s A/B model) means an attacker who achieves code execution in a system process cannot persist modifications to the OS layer across a reboot.

Support Lifecycle

ACL GA ships with a 3-year support lifecycle, aligned with AKS LTS windows. Microsoft patches the image on the same cadence as AKS node image updates — typically weekly for security patches, monthly for cumulative updates.

Practical Comparison: Choosing Your AKS Node OS

If you’re running AKS today, you’re choosing between three serious options:

Use Ubuntu if: You have existing tooling that assumes Ubuntu, you need SSH access to nodes for debugging, or you’re running GPU workloads that need NVIDIA’s full driver stack with maximum compatibility.

Use Azure Linux 3.0 if: You want the current supported default, you’re not ready to test ACL, or you have a mixed workload that includes some OS-level tooling.

Use Azure Container Linux if: You’re running pure container workloads, security posture and attack surface matter to you, or you’re building a new cluster from scratch and want the tightest possible node image. The lack of SSH is an operational adjustment but not a blocker — Azure Serial Console handles emergency access.

Using Azure Container Linux in AKS

New cluster with ACL node pool

1
2
3
4
5
6
7

az aks create \
  --resource-group myRG \
  --name myCluster \
  --node-count 3 \
  --os-sku AzureLinux \
  --node-vm-size Standard_D4s_v5 \
  --generate-ssh-keys

Add an ACL node pool to an existing cluster

1
2
3
4
5
6
7

az aks nodepool add \
  --resource-group myRG \
  --cluster-name myCluster \
  --name acnodepool \
  --node-count 3 \
  --os-sku AzureLinux \
  --node-vm-size Standard_D4s_v5

Run Ubuntu and ACL side by side

The cleanest migration path for existing clusters is to add an ACL node pool, taint the Ubuntu nodes NoSchedule, and let workloads drain over. You can validate ACL compatibility one workload at a time:

1
2
3
4
5
6
7
8

# Taint the old Ubuntu node pool
az aks nodepool update \
  --resource-group myRG \
  --cluster-name myCluster \
  --name nodepool1 \
  --node-taints "migration=pending:NoSchedule"

# New workloads will land on ACL unless they explicitly tolerate the taint

The most common compatibility issue is DaemonSets that run privileged operations expecting a specific OS layout. Anything that mounts host paths like /usr/bin, /lib, or /etc/os-release for inspection may need updates. The stripped-down ACL filesystem follows the same Filesystem Hierarchy Standard as full AL3, but some paths that existed on Ubuntu don’t exist on ACL.

Enabling GPU workloads on ACL

ACL doesn’t ship NVIDIA drivers by default, but the NVIDIA GPU Operator handles this cleanly:

1
2
3
4
5
6
7
8

helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update

helm install gpu-operator nvidia/gpu-operator \
  --namespace gpu-operator \
  --create-namespace \
  --set driver.enabled=true \
  --set toolkit.enabled=true

The operator detects the container host OS and installs the appropriate driver stack as a DaemonSet, so the base ACL image stays clean and the driver version is managed separately.

Azure Linux 4.0: Running It as a VM OS

AL4 is in public preview and free to run during preview. The image is available in all public Azure regions.

Creating an AL4 VM

1
2
3
4
5
6
7

az vm create \
  --resource-group myRG \
  --name al4-test \
  --image MicrosoftCBLMariner:azure-linux-4:azure-linux-4-gen2:latest \
  --size Standard_D4s_v5 \
  --admin-username azureuser \
  --generate-ssh-keys

Package management

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# Update the package index
sudo tdnf update

# Install a package
sudo tdnf install -y git curl jq

# Search
tdnf search nginx

# List installed packages
tdnf list installed

# Install a package from Fedora upstream (when not in Microsoft's curated set)
sudo tdnf install -y <package>

The TDNF command syntax mirrors DNF closely. Engineers familiar with yum or dnf will find it immediately usable.

Checking the OS image version

1
2
3
4
5
6
7
8
9

cat /etc/os-release
# ID=azurelinux
# VERSION_ID=4.0

# Check the current image slot (A/B)
bootctl status

# Check pending update
sudo bootctl list

Checking kernel hardening features

1
2
3
4
5
6
7
8
9

# Verify CET shadow stack is active (requires compatible hardware)
cat /proc/cpuinfo | grep -o 'shstk\|ibt'

# Verify IBT
grep CONFIG_X86_KERNEL_IBT /boot/config-$(uname -r)

# Check current kexec status
cat /proc/sys/kernel/kexec_load_disabled
# 1 = disabled (expected)

The Broader Picture: Microsoft’s Linux Strategy

Azure Linux 4.0 and Azure Container Linux together represent the clearest statement Microsoft has made about its Linux direction. The Fedora upstream choice is pragmatic — rather than maintaining a full parallel package ecosystem, Microsoft is investing in curating and hardening a subset of a well-maintained community distribution. This is closer to how Google manages ChromeOS and Container-Optimized OS than to how Red Hat manages RHEL.

The AI-workload emphasis throughout AL4 — the TCMalloc-Azure allocator, the ai-audit tooling, the specific Llama benchmarks in the launch material — reflects where Microsoft is seeing demand on Azure. GPU clusters and LLM inference workloads are the fastest-growing segment of Azure compute, and a hardened, performance-tuned OS is a meaningful differentiator when customers are spending six figures a month on H100 capacity.

For the typical AKS operator, the practical takeaway is simpler: if you haven’t evaluated Azure Container Linux for your node pools, this GA announcement is the right time to do it. The attack surface reduction is real, the CIS compliance is immediate, and the operational model (immutable images, no SSH, atomic updates) is where Kubernetes node management is heading regardless of vendor. Azure Container Linux makes it the default rather than something you have to build yourself.

If you’re curious how this fits into the broader container security picture, the container security post covers the host-level hardening decisions that ACL makes for you by default. And if you’re evaluating AL4 as a VM OS for AI inference workloads, the self-hosted AI inference guide has the vLLM and llama.cpp deployment patterns that will run cleanly on it.

Sources:

• Microsoft Open Source Blog — OSS Summit NA 2026
• Microsoft Unveils Azure Linux 4.0 and Container Linux GA — Windows News
• Azure Linux Container Host for AKS — Microsoft Learn
• Azure Linux 4.0 Preview — Redmond Mag