NBDE, Clevis And Tang For Non-root Disk

Home » CentOS » NBDE, Clevis And Tang For Non-root Disk
CentOS 4 Comments

Hi,

Has anybody managed to get network disk bound disk encryption to work with a non-root disk? It works fine for the root device, but the moment I add another volume to /etc/crypttab the system will no longer boot automatically. A tcpdump on the tang server shows no traffic while the system is stuck at the LUKS password prompt. The second encrypted volume is set up in the same way as the root device and I can unlock the volume using clevis-luks-unlock -d /dev/vda3. I’ve seen in https://rhelblog.redhat.com/2018/04/13/an-easier-way-to-manage-disk-decryption-at-boot-with-red-hat-enterprise-linux-7-5-using-nbde/
that clevis-luks-askpass.path needs to be enabled but it doesn’t make a difference. Any ideas on what ‘s wrong or how to debug this?

Best regards, Radu

4 thoughts on - NBDE, Clevis And Tang For Non-root Disk

  • Thanks, this is working as expected and it gave me the hint needed to find the actual problem. The problem is that the initramfs image generated by dracut -f does not include the /etc/crypttab from the OS (it only contains the entry for the root device). Once I have manually added the other volumes in the /etc/crypttab file from the initramfs image, clevis is able to decrypt all volumes. Now the question is why the generated iniramfs image has a different
    /etc/crypttab. How can I specify /etc/crypttab for the initramfs so that furhter kernel updates will not replace it with the wrong file?

    Radu

  • Radu Radutiu wrote:
    Sorry, I think you misunderstood. The key for root is *not* in
    /etc/crypttab – that’s only for the secondary ones.

    mark

  • in the /etc/crypttab gave me the idea to check if the initramfs image will have the same content for crypttab. So now I have 2 working solutions:
    1) /etc/crypttab on OS has a reference to the file that contains the key to decrypt the second volume (the key is on the encrypted root fs). I have checked and the initramfs /etc/crypttab has only the line for the root volume, without any reference to the second volume. The root volume gets decrypted by clevis+tang. The second volume is decrypted after the root volume is decrypted, /etc/crypptab is read and the key is found.
    2) the initramfs /etc/crypttab was manually updated to add the line for the second volume. Clevis + tang will decrypt both the root fs and the second volume. I was surprised to find out the the /etc/crypttab in initramfs is different from the one in OS. So now I’m searching for the correct way to force dracut to include /etc/crypttab unchanged in the initramfs image.

    Radu

  • I had the same issue: the system wasn’t able to open a non-root LUKS device and was stuck at the LUKS prompt after each reboot. Adding _netdev to /etc/crypttab and /etc/fstab solved this problem. I think the system was trying to contact the Tang server before enabling the network (I wasn’t able to ping it when it was stuck at the LUKS prompt). The _netdev option instructs the system to start the network before trying to enable the storage device.