Comment 0 for bug 2039676

Modern disk drives like NVMe propose an hardware offloaded encryption management. The idea of Self-Encrypting Drives (SED) is to offload the encryption complexity (and hardware resources) directly to the disk.
When SED is activated on a device, the disk is locked when power off (the disk "forget the key").
To unlock the key on power on, the user should enter the key, and the disk is uncrypted up to the next power off.

One common way to unlock the NVMe is to use the MBR sector of the drive to flash a dedicated small Linux that will ask for the drive password, but we can do it differently.

The SED management on Linux is usually done via a tool call 'sedutil-cli' (https://github.com/ChubbyAnt/sedutil).

There is multiple way to address this feature. The idea of this RFE would be to manage the SED interaction via IPA.
When the hardware node is power on, Ironic might bforce the host to boot on IPA to unlock the drive, annd boot the customer OS.

This RFE proposes that we change how ironic boot a node. We need to create a new driver type like "hardware encryption" to let the administrator activate or not the encryption.
During the installation process, if the driver is activated, we would need to activate encryption BEFORE installing the OS on the drive, and after lock the disk.
After a hardware stop, the disk will be encrypted. So when customer ask for a node power on, Ironic will need to do a rescue like boot:
Ironic move the interface to rescue network, boot on IPA image with a grub argument like "action=disk-unlock".
IPA will ask to Ironic what is the unlock key (key should be stored on a secured backend, behind barbican) and (if the unlock succeed) do a kexec (if it's a Linux) or a soft reboot.