Try to unlock existing LUKS device with Clevis

[rugk]

Feature Request

My use case is to mount an existing LUKS clevis-encrypted device (without wiping) and integrate it into the system with a (new) Clevis config via Ignition.

Environment

bare-metal

Desired Feature

As I noticed in #1209 for existing LUKS devices, you only try to unlock them via a keyfile (i.e. password).
However, given you now support Clevis, IMHO you should also try to unlock the disk via Clevis, so in case Clevis is already configured, it can be (re)configured by Ignition.

Other Information

You should also try a Clevis unlock here:

ignition/internal/exec/stages/disks/luks.go

Lines 375 to 380 in 0cbe33f

	if _, err := s.Logger.LogCmd(
	exec.Command(distro.CryptsetupCmd(), "luksOpen", devAlias, luks.Name, "--key-file", keyFilePath),
	"opening luks device %v", luks.Name,
	); err != nil {
	return false, nil
	}

If you do this, maybe you also need to delete that old keyslot used for unlocking via Clevis or overwrite it.(?)

---

Edit: Just saw in #1016 this was already mentioned, but apparently forgotten (respectively not being tracked) afterwards:

Currently unsure what would be needed to support this for Clevis based devices.

[arithx]

The main problem that was found during the implementation of #1016 was that we couldn't determine what exact config is set for clevis devices. As such we cannot validate that a given device matches what is specified to Ignition, purely being unlockable isn't sufficient.

If a happy path method of validating that a given config is exactly implemented on a given LUKS device (whether that's from header checks or some command querying) then I'd be happy to have this implemented but without it I'm afraid that this isn't something Ignition should support natively.

[rugk]

was that we couldn't determine what exact config is set for clevis devices.

You cannot?
Can't you just do sudo clevis luks list -d [device]?

Then maybe apply some JSON normalization and compare the result with the part ignition config. Should not that work?
(or rather than JSON normalization, I guess you can also parse then JSON and then iterate the appropriate values and compare them.)

[rugk]

And BTW, even if you could not verify the Clevis config, you could – what I argued here initially – actually just treat it the same as with a keyfile, i.e.:

• use clevis to unlock device
• add new clevis binding with provided config
• delete old slot that was previously used for unlocking the device

AFAIK you do the same if a keyfile is used.

[arithx]

You cannot?
Can't you just do sudo clevis luks list -d [device]?

Then maybe apply some JSON normalization and compare the result with the part ignition config. Should not that work?
(or rather than JSON normalization, I guess you can also parse then JSON and then iterate the appropriate values and compare them.)

From the top of my head one of the problems was that there were additional values that are generated in the clevis versions that we don't have access to (nor do we know if it would be correct and match what would occur if we were to be creating that device from scratch). If you're up for it then feel free to submit a pull request adding the verification that the config EXACTLY matches the specified config.

And BTW, even if you could not verify the Clevis config, you could – what I argued here initially – actually just treat it the same as with a keyfile, i.e.:

use clevis to unlock device
add new clevis binding with provided config
delete old slot that was previously used for unlocking the device
AFAIK you do the same if a keyfile is used.

Ignition's reuse semantics (filesystems and partitions for reference) is to only reuse pre-existing items when they exactly match what is specified in the config.