Azure ARC Machine support for immutable systems

Question

Is it possible to have support for immutable systems to have the azcmagent running?

Could this be provided e.g. as a sysext so that it would be supported on systems like Kairos/Talos/fedora IOT/... ?

Answer 1

Hello Jasper De Keukelaere (imec)

Thank you for posting your query on Microsoft Q&A portal.

Azure Arc’s Connected Machine Agent (azcmagent) cannot run natively on Talos, Kairos, bootc, Fedora IoT, Flatcar, or any other immutable/atomic system today. But it doesn’t mean that there is no way to onboard those environments to Azure Arc.

Use Azure Arc–Enabled Kubernetes Instead of Arc-Enabled Servers: This is the only fully supported and realistic option for Talos, Kairos, bootc, Flatcar, etc.

• These OSes are Kubernetes‑native and primarily used as container-only / node-managed OSes.
• Use Arc-enabled Kubernetes for node types that cannot run azcmagent.
• Arc-enabled Kubernetes does not require azcmagent, does not need a package-manager install, and is fully compatible with Talos, Kairos, Flatcar, etc., because it runs entirely using Kubernetes primitives.

What you get is:

• Governance with Azure Policy for K8s
• GitOps (Flux v2)
• Azure Monitor for containers
• Defender for Containers
• Inventory + security posture via K8s APIs

But you don't get OS-level Arc capabilities (extensions, guest configuration, Arc machine identity) as the OS doesn’t support it.

If the workload runs in Kubernetes, Arc-enabled Kubernetes is the supported resolution.

Run azcmagent in a “sidecar VM/microVM” (KubeVirt, Talos Workload VM, Firecracker, etc.)

• Create a small Linux VM (e.g., Ubuntu or Mariner) on top of the immutable OS using:
  • KubeVirt (Kairos/Talos with virtualization enabled)
  • Talos Workload VM support
  • Firecracker microVMs (Flatcar + Firecracker setup)
• Install azcmagent in that VM.
• Treat the VM as the Arc-connected machine, not the host OS.
• The real goal is typically: Get Arc governance/visibility into a cluster or device fleet.
• You don’t need the node OS Arc-enabled , you can Arc-enable a companion VM.

Pros:

• Fully supported agent behavior
• No modification to immutable host
• VM can be rebuilt/recreated automatically

Cons:

• Does not give deep OS insights of Talos/Kairos itself
• Extra resource overhead
• Must manage lifecycle of the VM template

This is the best approach when you need Arc-enabled servers capabilities but the underlying OS is immutable.

Use Arc-enabled Edge/IoT (IoT Operations) instead of Arc-enabled Servers:

For edge devices, industrial gateways, or secure hardened IoT systems, the right model is often Azure IoT Operations, not Arc Connected Machine Agent.

• IoT Operations supports immutable OSes, container-only devices, and environments where the host is read-only.
• It uses:
  • Arc-enabled Kubernetes
    • IoT layers
      • Edge workloads
        • Data plane via agents running in containers
        • No azcmagent installation is required.

This is the correct path for “edge devices with immutable OS” mentioned in the user’s use case.

1. You cannot run azcmagent directly on Talos/Kairos/Flatcar because:

• No deb/rpm
• No writable /usr
• No systemd user creation
• No extension lifecycle folders
• No stateful agent paths
• No supported package manager

2. You cannot build your own sysext image to workaround this.

Even if Microsoft published binaries, the agent needs writable state, so sysext is insufficient.

3. You cannot use a static binary: The agent is not a single binary it’s multiple coordinated components.

If you have any other queries, please do let us know.

Thanks,

Suchitra.

Answer 2

Azure Arc does not support running the Azure Connected Machine agent (azcmagent) on immutable systems such as Kairos, Talos, or Fedora IoT. The Azure Connected Machine agent is designed for server infrastructure and requires regular connectivity to Azure, which may not align with the operational model of immutable systems. Additionally, the agent is not tested on operating systems that are hardened or configured in a way that would typically be used in immutable environments. Therefore, it is unlikely that the azcmagent could be provided as a system extension (sysext) for these types of systems.

---

References:

• Connected Machine agent prerequisites
• Supported operating systems

Answer 3

Currently, azcmagent relies heavily on post-install scripts (deb/rpm) to create users, symlinks, and writable directories. This makes it incompatible with "Immutable" or "Atomic" operating systems where /usr is read-only.

Requested Features:

Official sysext images: Provide a .raw or SquashFS image containing the agent for use with systemd-sysext.

1. Stateless Configuration: Allow the agent to run by looking for configuration in /etc or /var while keeping binaries strictly in /usr

Static/Self-contained Binary Option: A way to run the agent without relying on host-level package manager hooks.

Use Case: Managed Kubernetes nodes (Talos, Kairos, bootc), security-hardened edge devices, and Flatcar Container Linux environments.