Encryption: All disks are belong to us

[darkmuggle]

All disks are belong to us

With Openshift Enhancement Request for Policy-Based Encryption RHCOS will be extended to support root disk encryption. It is the strong preference that both RHCOS and FCOS align with respect to disk handling.

This is a tracking issue to ensure alignment with the idea.

Phase 0 (OpenShift 4.3)

• RHCOS encryption using LUKS by default
• RHCOS uses Clevis Dracut for re-encryption
• FCOS re-writing of the root filesystem
• FCOS allows for Clevis Dracut setup of LUKS (via Ignition Flag)
• Clevis support for:
  • TPM2
  • Tang

Phase 1 (OpenShift 4.4)

• RHCOS back to XFS by default
• RHCOS uses Clevis Dracut for setup of LUKS
• Clevis support for Azure, GCP and AWS KMS's (Question on the utility of GCP w/ TPM2)

Phase 2 (OpenShift 4.4 or 4.5)

• Ignition full support for LUKS setup
• Clevis binding via Ignition?
• Clevis automatic detection of KSM?

Action Iteams:

• backport fetch stage to spec 2x
• RHCOS needs to use UEFI bits from RHEL Media (for signed Grub SHIM)
• get vTPMs blessed for FCOS/RHCOS (blessed?)
• add patch to cosa run for qemu w/vTPM
• Dracut module for Clevis Dracut

[ashcrow]

get vTPMs blessed for FCOS/RHCOS (blessed?)

What do we mean by "blessed"?

[darkmuggle]

To be explicitly clear: the purpose of this tracker item is not to propose any change of behavior to FCOS. That can be considered if there is interest.

The reason I created it here is that since FCOS is upstream to RHCOS, and some of the dependent features will benefit FCOS:

• arbitrary disk layouts
• LUKS volume support
• automated unlocking

The other reason why I create it here is so that the changes to CoreOS Assembler, Fedora Core Config, Ignition (and Ignition Dracut), etc, can be reference this tracker item; there didn't seem to be a good place for such a document.

[ajeddeloh]

Summarizing a lot from the IRC meeting:

• RHCOS (short term) will ship with a LUKS container and "do it's own thing". This doesn't change anything for FCOS
• FCOS should implement LUKS support by:
• Supporting LUKS device creation in Ignition (Ignition ticket, Prior work)
• Support moving the root filesystem, including to complex devices (i.e. devices that require userspace tools to start). Tracker issue
• RHCOS may switch to what FCOS is doing later

The overall flow would look like:

1. Create an Ignition config (probably via FCCT) that creates a LUKS container and a filesystem labeled root on it. Either explicitly or implicitly write configuration for how to mount root (see Support for reconfiguring the root storage #94 for more details about the proposals related to that)
2. Ignition fetch stage writes the rendered config to /run
3. Initramfs sees the FS with label root, saves it's contents
4. Ignition disks runs, creates the LUKS container, filesystem, etc
5. Initramfs copies what it saved to the new root fs in the LUKS container
6. Continue boot normally, run the rest of the Ignition stages, run for a while
7. Reboot
8. Initramfs reads configuration for how to find and mount root
9. Boot normally

[rugk]

It's good to see you are considering supporting encryption a priority. 😃

[arithx]

Initial LUKS support for Ignition has landed in coreos/ignition#960 & coreos/ignition-dracut#192

Outstanding work for getting said work into FCOS is coreos/fedora-coreos-config#503 & cutting a new Ignition release and making it into coreos/fedora-coreos-config

[darkmuggle]

IMO, we can close this out when all the bits land in Fedora. We sort of ignored the game plan...but we got a much better path. Well done @arithx !

[darkmuggle]

Bits have landed in FCOS. I'm going to close this out as work well done.