Auto Secure boot key enrollment with disk images

[bsloeserwij]

As discussed in the Slack channel: https://taloscommunity.slack.com/archives/CMARMBC4E/p1767874009521259.

I try to boot Talos with secure boot enabled from a disk image. To fully automate this I want to auto enroll the secure boot keys. This is already a feature when the ISO is used, but not using disk images (@frezbo told me). I think this would be a great feature to support (if possible of couse).

[bsloeserwij]

Any thoughts on this?

[smira]

I think it might be technically possible, but it is not the best flow, as bootloader stays with the machine, so it might try to enroll the keys even when this is not desired, while ISO is a temporary boot media.

If you have a usecase, please describe it here in full details (links to Slack don't work quite well).

[bsloeserwij]

Currently I am using a in house made method of rolling out bare metal nodes. This method uses disk images for installing the OS on the systems. Since we have access to the BIOS via Redfish we cannot add any keys fully automatic. If the disk image could auto enroll the secure boot keys it would help us big time.

[mcanevet]

According to the loader.conf(5) documentation, secure-boot-enroll controls enrollment of keys found under loader/keys/auto/ on the ESP. This is not ISO-specific. It works from any EFI partition.

The if-safe value is particularly relevant here:

Same behavior as manual, but will try to automatically enroll the key 'auto' if it is considered to be safe. Currently, this is only the case if the system is running inside a virtual machine.

So if-safe auto-enrolls specifically in VMs, not on bare metal. This also directly addresses the concern raised about the disk image bootloader being permanent on physical machines, if-safe only presents a manual enrollment entry without auto-enrolling. The risk of unintended enrollment on bare metal disk images does not apply.

The Talos secureboot-iso profile already sets secure-boot-enroll: if-safe in loader.conf. The only difference for disk images is that the enrollment databases (PK.auth, KEK.auth, db.auth) are not included on the EFI partition. Adding them alongside the same loader.conf setting would make auto-enrollment work identically for VM disk image deployments.

[mcanevet]

I added the support of auto-enrollment on disk image here: #13200

[mcanevet]

@smira — picking this back up now that disk-image auto-enrollment is merged (#13214, v1.14.0-alpha.1). As shipped it writes secure-boot-enroll if-safe, which only auto-enrolls inside a VM — so it's safe-by-default, but it doesn't actually serve the use case this thread opened with, and I'd like to find the right way to close that gap.

The use cases you asked for (unattended bare-metal):

• @bsloeserwij above: an in-house disk-image rollout for bare-metal nodes where the SecureBoot keys can't be enrolled automatically — even with BMC access via Redfish — so auto-enrollment from the disk image would solve it directly.
• Mine is the same shape: Talos provisioned to bare-metal via Tinkerbell (raw disk image streamed to disk). Metal³ and any iPXE-driven flow share the constraint.

The common factor is no operator at the console, so the manual Enroll Secure Boot keys: auto menu entry isn't reachable. For these, if-safe is a no-op and the only thing that enrolls is secure-boot-enroll force.

On your concern — that a disk-image bootloader is permanent and "might try to enroll the keys even when this is not desired," unlike a temporary ISO — I think the sd-boot Setup-Mode gate addresses it directly. In secure_boot_discover_keys():

if (!IN_SET(secure_boot_mode(), SECURE_BOOT_SETUP, SECURE_BOOT_AUDIT))
        return EFI_SUCCESS;

Auto-enrollment (even with force) only runs while the firmware has no PK. Once keys are enrolled and the machine reboots into user mode, that path returns early on every subsequent boot — so force enrolls exactly once, in Setup Mode, can never overwrite an existing PK, and never re-triggers later. That seems to make force safe to expose as an explicit opt-in (never a default), gated on the operator having deliberately put the firmware in Setup Mode.

A clarification, because the docs and the code seem to disagree and I want to make sure I'm reading sd-boot correctly. The SecureBoot guide presents setup-mode auto-enrollment as automatic regardless of platform — e.g. "For the first boot, the UEFI firmware should be in the setup mode, so that the keys can be enrolled into the UEFI firmware automatically", "The ISO bootloader will enroll the keys in the UEFI firmware, and boot the Talos Linux in SecureBoot mode", and the SecureBoot flow diagram branches Keys Enrolled? --No--> Setup Mode: Auto-enroll Keys with no VM qualifier. But from the sd-boot source, if-safe requires both Setup Mode and in_hypervisor() (CPUID hypervisor bit on x86, or an SMBIOS virtualization bit). If that's right, then on bare-metal even the stock if-safe ISO wouldn't auto-enroll unattended — the working path is the same manual Enroll Secure Boot keys: auto menu entry, and the docs' "if the UEFI firmware does not support automatic enrollment" framing is really the if-safe policy, not a firmware-capability difference.

So: is it accurate that there's no truly unattended bare-metal auto-enrollment today for either the ISO or the disk image — only the interactive menu? If yes, I'd be happy to send a docs clarification.

And if the Setup-Mode-gate reasoning holds, would you be open to exposing the existing SDBootEnrollKeys field (already in profile.ImageOptions, currently only settable via a hand-written imager profile) as an opt-in — e.g. an imager flag --secureboot-enroll-keys and an Image Factory schematic field secureboot.enrollKeys, defaulting to if-safe? Happy to implement it plus the docs update if you're on board.

[frezbo]

iso supports changing to to be force

[mcanevet]

@frezbo thanks, just want to make sure I follow. Do you mean the ISO can already be built with secure-boot-enroll force by setting output.isoOptions.sdBootEnrollKeys: force in the imager profile (so the capability exists, it's just not surfaced via a flag or Image Factory)? Or is there a more user-facing way to set it that I've missed?

And does that line up with my read that force, not the default if-safe, is what's actually needed for unattended enrollment on bare-metal (since if-safe only auto-enrolls in a VM)?

[frezbo]

yes correct, imager supports this

[mcanevet]

PR created: #13571

[mcanevet]

Follow-up PR siderolabs/image-factory#482