LUKS volumes for OEM, persistent, and extra partitions

[jmpolom]

Can encrypted LUKS volumes be defined in the configuration for the OEM, persistent and/or extra user defined partitions? Is it possible to use these with systemd-cryptenroll for automatic token based decryption at boot time?

It seems like the only support is for unencrypted partitions.

[frelon]

Hi @jmpolom!

Right now we don't have any support for encrypted partitions. Any updates will be posted in the corresponding issue

[jmpolom]

Is there any reasonable workaround to this deficiency if we require encryption? Such as using the cloud-init stage hooks during/after installation or system boot?

Is there any timeline for adding in official support for encryption?

[frelon]

We don't have a workaround at the moment. The required hooks are missing, but we are of course open to PRs adding the necessary support (or the hooks needed to implement this using cloud-init config)!

We don't have a strict timeline for adding this, if this is a business requirement feel free to reach out using proper channels to discuss!

[jmpolom]

I see there are some hooks around the install process already. What hooks are missing or what is deficient with the current hooks?

I think the most reasonable way to implement LUKS encryption would be at installation time (IE: this isn't a post-install reconfiguration using the later post install cloud-init hooks).

[frelon]

Yep, as I see it we would need a hook before formatting the devices where you can run cryptsetup luksFormat ... and cryptsetup open ... to map the device using device-mapper.

In the configuration we would have to double-check that you can use the mapped device instead of the one specified in install command so it can look something like:

install:
  target: /dev/sda
  partitions:
    persistent:
      fs: ext4
      disk: /dev/mapper/cr_persistent

The interesting part comes during the mount of the system though. We could implement a pre-mount hook as well to run systemd-cryptsetup attach ... as well, but the problem becomes where to specify this hook if the oem partition is also encrypted.

[jmpolom]

Yep, as I see it we would need a hook before formatting the devices where you can run cryptsetup luksFormat ... and cryptsetup open ... to map the device using device-mapper.

Could this today be done outside of the elemental install process? IE: just run the necessary commands in the installation environment manually or via a script to create the LUKS devices? Seems possible unless elemental destroys the entire partition table before running install? Is the before-install hook run after partitioning the storage device? Docs are not clear on when exactly it runs.

Agree though that it would be far cleaner to have this all in the cloud config and the necessary hooks don't exist today to do that.

In the configuration we would have to double-check that you can use the mapped device instead of the one specified in install command so it can look something like:

install:
  target: /dev/sda
  partitions:
    persistent:
      fs: ext4
      disk: /dev/mapper/cr_persistent

Would elemental today refuse to install to a /dev/mapper device that it didn't create? Haven't tested this scenario but it looks like it would not complain if the device existed. The disk attribute for the partition does not currently exist, correct? I do not see it documented anywhere.

The general configuration documentation suggests there's a mount object that can be defined in the cloud-init configuration where you can set things like the LABEL or PARTLABEL of the partition. Are there complete docs for what this mount object can configure and what keys it supports? I only found one example.

The issue is that by default it seems like elemental defaults to mounting the persistent partition based on the PARTLABEL. which is problematic because in a LUKS configuration that would be a LUKS volume and you cannot set partition labels on LUKS volumes (they are not partitions). However it looks like there is already a way to configure this?

The interesting part comes during the mount of the system though. We could implement a pre-mount hook as well to run systemd-cryptsetup attach ... as well, but the problem becomes where to specify this hook if the oem partition is also encrypted.

The best way to handle a fully encrypted system (all partitions encrypted except /boot) would probably be to rely on the existing systemd-cryptsetup-generator which is what most uses of LUKS for full disk encryption rely on. This auto generates the systemd-cryptsetup units.

Based on how elemental generates fstab during boot I'm not sure how this would/could work in practice. I have not looked deep enough into how that's generated and if crypttab could be similarly generated early enough for the systemd generator to pickup. Or if as you suggest elemental would manage unlocking the LUKS volumes.

Is the initramfs stage early enough in the boot process to deposit a crypttab file for systemd to pickup?

I don't see a clean way to handle an encrypted /oem partition unless maybe elemental gained another boot argument to tell it to unlock /oem based on UUID or label. I see there's already a boot argument for elemental that provides the OEM partition label so maybe this option is most consistent with related configuration items.

There are kind of 2 problems here: how to (1) "bootstrap" unlock an encrypted OEM partition and then (2) unlock the rest of the partitions.