crypt: initial pass on supporting clevis-unlocked volumes

[somewhere-or-other]

This is an initial pass at supporting LUKS volumes, that are being non-interactively unlocked by Clevis/Tang, also known as "Network Bound Disk Encryption" or "NBDE". Initial testing seems to work as expected, but I'll certainly do more thorough testing over the next week or so, just to be sure.

I would prefer a better way to have it realize that it needs to use clevis, than the "use_clevis" flag, but I haven't figured that out yet. If you've got suggestions, that would be great. I'll keep working on that, as well.

If it would be helpful, I can outline the steps necessary to set up a Clevis-unlocked volume. These are the steps I was using to add my crypted LUKSv2 volume to pacemaker:

pcs resource create einstein-crypt ocf:heartbeat:crypt encrypted_dev="8e6ef2f2-b06b-46da-969e-3583aaa8360d" crypt_dev="crypteinstein" crypt_type="luks2" use_clevis="true" key_file=/dev/null --group einstein --after einstein-lvm

Here are a few references for Clevis/Tang, as well:

*Introduction to Tang and Clevis by Fraser Tweedale *Clevis and Tang: securing your secrets at rest - Fraser Tweedale (LCA 2020) **Slides *An easier way to manage disk decryption at boot with Red Hat Enterprise Linux 7.5 using NBDE *How to set up Network-Bound Disk Encryption with multiple LUKS devices (Clevis+Tang unlocking) *Automatic data encryption and decryption with Clevis and Tang *Tang software development *Clevis Software Development

[knet-ci-bot]

Can one of the admins verify this patch?

[somewhere-or-other]

I've added a small amount of code that attempts to detect the presence of clevis keys in the volume automatically

[oalbrigt]

ok to test

[oniko]

@somewhere-or-other, when unlocking LUKS2 devices via clevis, does it have --disable-locks cryptsetup equivalent option?

We disable LUKS2 (local) locks for 2 reasons:

1. it does not make much sense to use file based locking when running in cluster env.
2. By disabling locks we also turn off LUKS2 metadata auto-recovery feature.

The later is important because auto-recovery invoked in-parallel from multiple nodes could lead to severe LUKS2 metadata corruption

[somewhere-or-other]

@oniko It does not, at least not obviously. I will look through the clevis tools (which are just bash wrappers to cryptsetup, among other things), including from their github version, and see what I can find. I'll post here again when I have some kind of conclusion.

[somewhere-or-other]

I've submitted a pull request to add an option to allow passing of arbitrary parameters to the underlying cryptsetup open, when unlocking via clevis. Feel free to put this on the back burner until that one is merged, at least.