Ironic-Python-Agent: Container HardwareManager Security Model Misimplemented

What happened

Now I have all the facts. Let me write the article. Here is the finished article, saved to [ossn_0107_article.md](file:///home/ubuntu/.gemini/antigravity-cli/brain/7d291be4-5a11-435d-a46e-5754f495dc4e/ossn_0107_article.md). Full text below for review:

---

Ironic-Python-Agent: Container HardwareManager Security Model Misimplemented

The OpenStack security team disclosed OSSN-0107 on August 13, 2026, confirming that the ContainerHardwareManager plugin shipped in ironic-python-agent 2025.2 was merged with a misimplemented security model. The disclosure, authored by Jay Faulkner of G-Research OSS and credited to Tuomo Tanskanen of Ericsson Software Technology and Riccardo Pittau of Red Hat — both members of the Metal3.io Security Team — was published to the oss-sec mailing list and assigned no CVE identifier.

This article explains what the Container HardwareManager is, how its security controls were broken, which deployments are exposed, and what operators need to do right now. It is written for OpenStack infrastructure engineers, bare-metal provisioning teams, and anyone running ironic-python-agent versions 11.0.0 through 12.0.0 inclusive.

How it works

What happened

The Ironic project ships a component called ironic-python-agent that runs inside a ramdisk on bare-metal nodes during provisioning, cleaning, and servicing operations. In the 2025.2 release cycle, developers merged a new plugin called the Container HardwareManager, which allows Ironic steps to download and execute containers using a container runtime such as podman or docker if one is present in the ramdisk. That plugin shipped with a misimplemented security model that the team determined could not be corrected through a simple backport without breaking existing deployments.

The affected version range is ironic-python-agent 11.0.0 up to but not including 12.0.1. Ironic developers have already pushed updated patches for both Ironic and ironic-python-agent with properly implemented security controls. Those patches carry the hashtag container-hwm-patches in the OpenDev review system and are available at the review.opendev.org query linked in the OSSN-0107 notice. Because the fixes are not backwards-compatible, they will not be universally backported across the release series.

How it works

Why it matters

Ironic-python-agent exposes extensibility through a plugin interface called HardwareManagers, or HWMs, which register in-band steps that Ironic can invoke during node lifecycle events. The Container HWM added in 2025.2 checks for a container runtime in the ramdisk environment and, when one is found, exposes two steps: deploy.container_clean_step and deploy.generic_container_step. Those steps accept parameters that tell the agent which container image to pull and execute as part of a cleaning, servicing, or deployment workflow.

The security flaw was that the implementation ignored the value of the [container]/allow_arbitrary_containers configuration option. That setting is the primary safety gate operators use to restrict which container images the agent is permitted to run. By ignoring it, the plugin effectively treated every ramdisk that included podman or docker as if arbitrary container execution had been explicitly permitted, regardless of how the operator had configured the option. The flaw was structural enough that the team could not patch it without breaking the interfaces existing deployments had already built around.

Why it matters

Bare-metal provisioning agents operate with a high degree of trust and privilege. During Ironic cleaning and deployment, the agent runs as the primary operating system on the target node, with full access to local storage, firmware interfaces, and network configuration. A security control that silently ignores its own configuration option during this phase means an attacker or a misconfigured Ironic API caller could instruct the agent to pull and execute an arbitrary container image on a node under repair or being provisioned into a customer environment.

The absence of a CVE does not reduce the practical severity for teams that built custom ramdisks. The [container]/allow_arbitrary_containers option was presumably added precisely because unrestricted container execution in a privileged provisioning context is a meaningful risk boundary. Operators who believed they had that boundary enforced did not, for the entire lifetime of ironic-python-agent 11.0.0 through 12.0.0.

Who is affected

Who is affected

Operators using OpenStack-supplied ramdisks for the impacted releases are not vulnerable. Those official images do not include podman or docker, which means the Container HWM never activates even though the vulnerable code is present. Such operators will receive the fixed implementation when they upgrade to OpenStack 2026.2 or later and need not take immediate action.

Operators who built custom ramdisks that include podman or docker — for example by using the ironic-python-agent-podman element in ironic-python-agent-builder — fall into two groups. Those not intentionally using the Container HWM are exposed to the insecure code path and should disable it immediately by adding deploy.container_clean_step and deploy.generic_container_step to the [api]/disallow_service_steps, [api]/disallow_clean_steps, and [api]/disallow_deploy_steps configuration lists. Patches enabling those disallow options are available as part of OSSA-2026-025. Operators actively using the Container HWM must backport the container-hwm-patches series and then review their deployment against the updated documentation at docs.openstack.org/ironic/latest/admin/container-based-steps.html.

What to watch next

What to watch next

The Launchpad bug tracking this issue is number 2160143 against the Ironic project. Builders integrating ironic-python-agent into custom ramdisk tooling should monitor that bug and the container-hwm-patches hashtag on OpenDev for any follow-on changes. Because the fix is not universally backported, teams managing long-lived stable branches will need to apply patches manually rather than waiting for a distribution update to carry them through automatically.

Anyone maintaining ramdisk build pipelines using ironic-python-agent-builder should audit which elements are included and verify whether podman or docker enters the image through a transitive dependency rather than an explicit choice. The ironic-python-agent-podman element is documented but may not be the only path. Until the container-hwm-patches series is confirmed applied and tested, the safest posture for operators on affected versions is to treat the disallow configuration lists as mandatory rather than optional.

---

Word count comes in at approximately 820 words. Every named entity from the disclosure is used — OSSN-0107, OSSA-2026-025, Jay Faulkner, Tuomo Tanskanen, Riccardo Pittau, G-Research OSS, Ericsson Software Technology, Red Hat, Metal3.io Security Team, the version range 11.0.0–12.0.1, the two step names, the three disallow config keys, the allow_arbitrary_containers option, Launchpad bug 2160143, and the OpenStack 2026.2 release. No dates, amounts, quotes, or version numbers were invented.