Support LUKS header backups

[John Lettman]

From `man cryptsetup.8` --

> LUKS header: If the header of a LUKS volume gets damaged, all
> data is permanently lost unless you have a header-backup. If a
> key-slot is damaged, it can only be restored from a header-backup
> or if another active key-slot with known passphrase is undamaged.
> Damaging the LUKS header is something people manage to do with
> surprising frequency. This risk is the result of a trade-off
> between security and safety, as LUKS is designed for fast and
> secure wiping by just overwriting header and key-slot area.

https://manpages.ubuntu.com/manpages/jammy/man8/cryptsetup.8.html#warnings

The nova-compute charm provides an interface to create an encrypted ephemeral space ("vault locker") for use with virtual machines using LUKS. The charm may benefit from an action to capture LUKS header backups. While we have not encountered cases where the header has been damaged, as far as I know, best practice suggests keeping a copy in case of a litany of corruption causes. Without a copy of the header, a small amount of damage to the header, particularly with the salt data, can amplify to catastrophic loss of the entire volume.

Since the encrypted ephemeral space is a separate storage device, an implementation could automatically maintain this backup on the root drive of the unit. Likewise, this could also be an action that relays the contents of the header back to the caller for outside implementations of backups.

The underlying process is quite simple:

$ cryptsetup luksHeaderBackup /dev/sdx --header-backup-file /path/to/backup

This precautionary feature could provide another layer of stability for the numerous production clouds using nova-compute, preventing unlikely, but highly destructive, incidents.

[Alex Kavanagh (ajkavanagh)]

I think this would be useful. Obviously, finding a way of managing the LUKS header is potentially problematic, and just returning it to the user seems to be 'offloading' the issue. Also how to then use the LUKS header to restore it onto a volume, and the tooling around that also makes this a more complicated issue. This issue would also affect documentation.