Current Series Release Notes

12.0.0-15

Upgrade Notes

  • Container steps invoked through runbooks, deploy templates, manual cleaning or servicing are now checked against [container]allowed_containers. Deployments that relied on the allowlist being silently inoperative must either add their images to [container]allowed_containers or set [container]allow_arbitrary_containers to True. Steps defined in the ramdisk’s [container]container_steps_file are authored at image build time and remain exempt.

  • The [container]container_conf_file option has been removed. It was registered but never read by any code path. A conductor that still sends it is now ignored with a warning rather than failing the lookup, along with any other unrecognized or invalid [container] option.

  • [container]pull_options no longer defaults to --tls-verify=false, and --tls-verify=false has been dropped from the [container]run_options default, so the container runtime now verifies the registry certificate as it normally would. A ramdisk which pulls step containers from a registry whose certificate it does not trust must either carry that certificate or set the flag back explicitly. The conductor overrides both options at lookup time, so this is what an agent falls back to before it has looked up, or against a conductor which does not send them.

  • The built-in container step is now called generic_container_step. It lives on the deploy interface and is used for cleaning, deployment and servicing alike, so the previous name was misleading. ContainerHardwareManager version has been raised to 2.

  • The [DEFAULT]md5_enabled option now defaults to False. This value is typically overridden by Ironic via the agent heartbeat configuration.

Deprecation Notes

  • The container_clean_step step name is deprecated in favour of generic_container_step. It is still advertised and still functional, so existing runbooks and deploy templates continue to work, but it logs a warning when used and will be removed in a future release.

Security Issues

  • Fixes a security issue where [container]allow_arbitrary_containers and [container]allowed_containers had no effect in ContainerHardwareManager. A missing line continuation split the guard into two statements, so the check evaluated a configuration group proxy that is always true and the allowlist was never consulted. Separately, the container_clean_step step never consulted the allowlist at all, leaving the runbook and deploy template path completely unguarded. Any container image could therefore be pulled and executed as root on the bare metal node. See bug 2160143.

  • Container options supplied as step arguments are now ignored when [container]allow_arbitrary_containers is False. Options alone are sufficient to defeat an image allowlist, for example --privileged, -v /:/host or --entrypoint, so a caller who is not trusted to choose the image is no longer trusted to choose the flags either. The configured [container]pull_options and [container]run_options are used instead.

  • A container step whose name matched a step the agent already provides silently took its place. Naming a step erase_devices_metadata in the container steps file ran that container instead of erasing disk metadata, and cleaning then reported success, so a node could be handed to the next tenant with the previous tenant’s data still on it. Such a name is now refused, both when the step list is reported and when the step is invoked, and the error names the step and the file it came from instead of the step being scheduled and later failing as “hardware manager method not found”. Names belonging to any hardware manager the ramdisk has loaded are protected, not only the ones the agent ships.

  • The [container] defaults no longer disable registry TLS verification. Both pull_options and run_options previously shipped --tls-verify=false, which left image pulls for container based steps open to interception on any ramdisk that had not overridden them.

  • The Nvidia NIC firmware update steps now enforce checksum algorithm validation. Only sha256 and sha512 are accepted. md5 is permitted only when the [DEFAULT]md5_enabled option is set to True, and weak algorithms such as sha1 are rejected outright. Additionally, firmware image checksum verification now occurs before the image is passed to mstflint for parsing.

Bug Fixes

  • [container]allowed_containers now ignores the transport prefix when matching, so docker://example.com/tool:1 and example.com/tool:1 are recognized as the same image. Previously an allowlist written in one form rejected a runbook that used the other, which read as the allowlist being broken rather than as a spelling mismatch.

  • The container_url step argument is now rejected unless it is a non-empty string. Step arguments are validated by name but not by type, so a runbook passing a list or an object previously reached the container runtime.

  • [container]pull_options and [container]run_options are now accepted whether they are written as a list or as a single whitespace separated string. These options are list valued, and lists split on commas rather than whitespace, so the space separated values sent by the conductor and written by the ironic-python-agent-podman build element previously reached the container runtime as one long argument and every container step failed. Both spellings now produce the same command line.

  • Fixes a RecursionError when a ContainerHardwareManager instance is copied, pickled, or otherwise probed before __init__ has run. Private and dunder attribute names are no longer resolved as container steps.

  • The AttributeError raised for an unknown container step now includes the manager and attribute names, instead of an uninterpolated format string and its arguments.

  • Errors reading [container]container_steps_file are no longer swallowed. A malformed or unreadable steps file was previously logged at debug level and treated as though it contained no steps, so an operator saw their container steps silently disappear. A missing file is still treated as “no container steps”, which is the normal case for a ramdisk that defines none.

  • Container steps are validated when they are loaded. A step missing its name or image key is now reported instead of passing None to the container runtime.

  • The container_url argument of the built-in container step is now marked as required, so a runbook or deploy template which omits it is rejected rather than failing part way through the step.

  • A priority set on a step in [container]container_steps_file now applies to automated cleaning only. get_deploy_steps and get_service_steps returned the cleaning step list unchanged. A deploy step with a priority above zero runs automatically, so a container intended for automated cleaning also ran on every deployment and every service operation. The same steps are still offered in those phases, at priority zero, for explicit invocation from a runbook or deploy template.

12.0.0

New Features

  • The agent now applies TLS configuration received from Ironic’s /v1/lookup endpoint response. When Ironic sends tls_min_version and tls_cipher_suites in the lookup response, IPA will override its local configuration with these values. This ensures consistent TLS security policy across all agent-to-Ironic communication channels, matching the security requirements configured in Ironic.

  • Added a new [mdns]/allowed_overrides option, a list of configuration option names that are allowed to be overridden via mDNS. It is unset by default, which preserves today’s behavior of allowing any recognized configuration option to be overridden via mDNS. Deployers who use mDNS discovery can set this to an explicit list to restrict which options a rogue mDNS responder could affect, especially security-sensitive ones (e.g. TLS verification, credentials, image integrity checks). A future change may populate a reasonable default list and enable this restriction by default.

Upgrade Notes

  • The [mdns]/allowed_overrides option now defaults to ['inspection_callback_url', 'ntp_server'] rather than None (allow everything). Environments relying on mDNS TXT records to override additional configuration options will need to list those options explicitly in [mdns]/allowed_overrides.

  • Implicit discovery of the Ironic API URL via multicast DNS (mDNS) - that is, when neither ipa-api-url nor ipa-inspection-callback-url is set at all - is now disabled by default. Set [mdns]/use_mdns to True (or supply the ipa-use-mdns=true kernel parameter) to enable mDNS discovery. mDNS responses are not authenticated, so only enable this on a trusted deployment network. Explicitly setting ipa-api-url or ipa-inspection-callback-url to mdns will also set [mdns]/use_mdns to true and continues to work – only implicit use of mDNS due to missing ipa-api-url or ipa-inspection-callback-url is disabled.

  • Support for Python 3.10 has been removed. Now Python 3.11 is the minimum version supported.

Security Issues

  • During bootc deployment, the container registry pull secret was written to a well-known path on the host and passed to podman run via --authfile. Because the container runs with --privileged --pid=host, tenant-controlled code in the bootc image could read the credential through /proc/1/root/<authfile-path>. When the pull secret originates from an operator or admin source (driver_info.image_pull_secret, [deploy] image_server_user/password, or [oci] authentication_config) rather than the tenant’s own instance_info.image_pull_secret, this constitutes a cross-boundary credential disclosure to tenant-controlled bootc image code. The image pull is now performed in a separate podman pull step and the auth file is deleted before the tenant container executes. The subsequent podman run uses --pull=never so that no registry credentials are required or present at container runtime. Addresses CVE-2026-54422.

  • The GET /v1/commands and GET /v1/commands/<uuid> API endpoints now always validate the agent_token, matching the POST endpoint. Previously, these GET endpoints only started enforcing the token once a GET request happened to supply one, so if that never occurred, e.g. in typical POST/heartbeat-driven deployments, the endpoints could remain unauthenticated indefinitely. See bug 2160196 for details.

  • Fixes a shell command injection vulnerability in the NTP clock synchronization when using chrony. The ntp_server configuration value was interpolated into a shell command string, allowing a crafted value to execute arbitrary system commands. The chrony execution path no longer uses a shell, and the ntp_server value is now validated and sanitized before use. See bug 2160050 for details.

  • The [mdns]/allowed_overrides option now defaults to ['inspection_callback_url', 'ntp_server'] instead of None. Previously, any recognized configuration option could be overridden by an unauthenticated mDNS responder on the local network, including security-sensitive settings such as TLS verification, credentials, and image integrity checks. The API endpoint and inspection callback URL are provided by the mDNS service record itself and do not require TXT record overrides. Deployers who need additional options overridden via mDNS can extend the list explicitly.

  • Implicit mDNS discovery of the Ironic API URL is now disabled by default, closing a vector where an unauthenticated host on the local network could redirect an agent that never intended to use mDNS to a malicious API endpoint.

Bug Fixes

  • Interfaces with MAC addresses whose first octet is 0xFA are now automatically excluded from discovery and lookup. This prevents duplicate node errors when enrolling servers such as HPE Gen12 that stamp the same locally-administered OUI (e.g. fa:4b:7f) on internal interfaces across multiple machines. A warning is logged for each ignored interface advising operators to investigate, as the presence of such an address may indicate an in-band BMC connection with potential security implications.

  • Fixes an IPA bug where mdadm detail/examine input may not be handled properly if a hostname is not present as set when the volume was created. For more information please see bug 2154279.

11.6.0

New Features

  • Auto-generated TLS certificates now support configurable elliptic curves via the new tls_certificate_curve configuration option. Operators can choose between P-256, P-384, and P-521 curves to balance security, performance, and certificate size based on their requirements. This option can also be set via the ipa-tls-certificate-curve kernel parameter.

  • Added configuration options for TLS protocol version enforcement across all agent connections (both server and client). The new tls_min_version option allows operators to specify the minimum TLS version (1.2 or 1.3) for the agent API server and all outbound HTTPS connections (to Ironic, Inspector, and image servers). The tls_cipher_suites option allows customization of allowed cipher suites for TLS 1.2 connections. Both options can be set via kernel parameters (ipa-tls-min-version and ipa-tls-cipher-suites).

Upgrade Notes

  • Auto-generated TLS certificates now use the P-384 elliptic curve by default instead of P-256. This change is transparent and backward compatible - all actively maintained TLS implementations support P-384. Certificate sizes increase slightly from ~1 KB to ~1.2 KB, with negligible performance impact. Operators requiring P-256 for specific compatibility reasons can set tls_certificate_curve = p256 in the configuration.

  • The minimum supported TLS version has been raised from system default (potentially TLS 1.0) to TLS 1.2. Operators using legacy infrastructure that only supports TLS 1.0 or 1.1 will need to upgrade their Ironic conductors, Inspector services, and image servers to support at least TLS 1.2 before deploying this version of ironic-python-agent. All actively maintained versions of OpenStack Ironic support TLS 1.2.

  • If your environment uses custom or legacy TLS configurations, verify compatibility with TLS 1.2 before upgrading. Test deployments in a staging environment if you have strict TLS requirements. Operators requiring TLS 1.0/1.1 for legacy systems should not upgrade until those systems are modernized, as there is no configuration option to downgrade below TLS 1.2.

Security Issues

  • Disable installation of bootloaders (via grub-install) by default in order to improve security posture by adding a new configuration option enable_bios_bootloader_install which defaults to False. Operators who still need this functionality can re-enable installation of bootloaders by setting enable_bios_bootloader_install to True. Addresses CVE-2026-43003.

  • The default elliptic curve for auto-generated TLS certificates has been upgraded from P-256 to P-384. This provides enhanced quantum resistance, requiring approximately 3-4x more qubits to break compared to P-256 (~6,080 qubits vs ~2,330 qubits). P-384 offers ~192-bit security strength, equivalent to 7680-bit RSA, while maintaining broad compatibility with all modern TLS implementations.

  • Auto-generated TLS certificates now use SHA-512 for signing instead of SHA-256. This upgrade provides enhanced quantum resistance with 512-bit security strength against future quantum computing attacks, aligning with NIST recommendations for long-term cryptographic security.

  • TLS 1.2 is now enforced as the minimum protocol version for all HTTPS connections by default. This applies to the agent API server (inbound connections from Ironic) and all client connections (to Ironic API, Inspector, and image download servers). TLS 1.0 and 1.1 are no longer accepted as they have known security vulnerabilities and are deprecated by RFC 8996. Operators can configure TLS 1.3 as the minimum version using the tls_min_version configuration option for enhanced security.

  • Default cipher suites for TLS 1.2 connections have been limited to forward-secret AEAD ciphers: ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-ECDSA-AES128-GCM-SHA256, ECDHE-RSA-AES256-GCM-SHA384, and ECDHE-RSA-AES128-GCM-SHA256. This removes support for weak ciphers including CBC-mode, RC4, and non-ephemeral key exchange. TLS 1.3 cipher suites are automatically selected by the TLS library and provide superior security.

Bug Fixes

  • Fixed an issue where the ESP filesystem label was replaced with a hardcoded esp when relocating the EFI System Partition to a software RAID device. If the deployed image’s /etc/fstab referenced the ESP by label (e.g. LABEL=MKFS_ESP), the mismatch would cause the system to drop to an emergency shell on boot. The source ESP label is now preserved, matching the existing behavior for the ESP UUID.

  • Fixed an issue where ESP relocation to a software RAID device could fail with No space left on device. The previous block copy approach could fail when the mdadm superblock consumed usable space on the device. ESP contents are now copied at the filesystem level instead, preserving the source ESP UUID so existing /etc/fstab entries remain valid.

  • Bug 2153130<https://bugs.launchpad.net/ironic/+bug/2153130>_ fixed; now the logic handling the RAID skip list does not rely the RAID devices being listed in a particular order.