Support for encrypted luks volumes

[coreosbot]

Issue by @crawford

---

Issue Report

Feature Request

Environment

All

Desired Feature

Ignition should be able to create LUKS devices which can then be used to back filesystems. This is needed for anyone who wants to encrypt their root filesystem.

I'm not sure where the decryption secrets come from just yet. (/cc @brianredbeard @mjg59)

I think the config structure would look something like this:

{
  "ignition": { "version": "2.0.0" },
  "storage": {
    "luks": [{
      "device": "/dev/disk/by-partlabel/ROOT",
      "name": "encrypted-root",
      "other configuration": "goes here"
    }],
    "filesystems": [{
      "name": "root",
      "mount": {
        "device": "/dev/mapper/encrypted-root",
        "format": "btrfs",
        "create": {
          "force": true,
          "options": [ "--label=ROOT" ]
        }
      }
    }]
  }
}

We still have to figure out how to make the initramfs automatically open the LUKS devices before attempting to mount ROOT.

[coreosbot]

Comment by @crawford

---

We just whiteboarded this out and have an idea for a first pass. The Ignition config specifies the URL to a secret-serving endpoint which will create and provide the secret used for decryption (unique on machine-id and device path). Ignition will then save this URL to somewhere stateful and create the LUKS device. On all boots, a service in the initramfs will check for the existence of this URL and, if present, start networking, fetch the secret, and decrypt the volume.

Other ideas included:

• using the EFI variables to hold the URL
• using the TPM to allow the remote secret service to do remote attestation

[coreosbot]

Comment by @brianredbeard

---

In addition one should also be able to specify that swap should generate a
random key on each boot.

[coreosbot]

Comment by @crawford

---

We probably also want to support the simple case of a user specifying a key in the Ignition config.

[coreosbot]

Comment by @mjg59

---

Ok I think I have a decent amount of this implemented, so let's figure out what the format should look like. What I have right now is:

type Luks struct {
        Name            string `json:"name,omitempty"`
        Device          *Path  `json:"mount,omitempty"`
        Key             []byte `json:"key,omitempty"`
        KeySource       string `json:"keysource,omitempty"`
        KeySourceKey    []byte `json:"keysourcekey,omitempty"`
        KeySourceCert   []byte `json:"keysourcecert,omitempty"`
        KeySourceCA     []byte `json:"keysourceca,omitempty"`
}

Should the TLS stuff be pushed into a substructure? Should Key be Secret?

[coreosbot]

Comment by @coresolve

---

Bumping this issue.

[coreosbot]

Comment by @coresolve

---

I think it would serve us well to have a documented way to support luks encryption. This would help the pci compliance story and push our overall security story a bit further.

[coreosbot]

Comment by @lals1

---

Guys any idea when LUKS support will be added to coreOS? Or is there any workaround to enable the support?

[coreosbot]

Comment by @crawford

---

@lals1 This isn't a priority for us right now. We are hoping to make some progress in the next few months. It would be helpful to know how your existing environment gets secrets to the machines for decryption (e.g. a network key server, a peripheral, an intern with a crash cart).

[coreosbot]

Comment by @lals1

---

Sorry for delayed response. Currently, we are getting the secret either from TPM at initramfs boot stage or from USB to decrypt the drive.

CoreOS container Linux version 1465.6.0 seems to contain cryptsetup binary. Do you think is it possible to encrypt the root partition with manual passphrase input for decryption after coreOS is installed?

Any help will be appreciated.

[coreosbot]

Comment by @crawford

---

@lals1 I haven't personally tried to encrypt the root partition with a password. I would be very interested to know how well that works.

What does your TPM setup look like? Are you sealing a key with a well-known SRK or using another method?

[coreosbot]

Comment by @lals1

---

@crawford TPM setup is similar to below project where we have TPM SRK setup with default values (all 0's) and then randomly generated key added to LUKS and also sealed in TPM.
More details here: https://github.com/fox-it/linux-luks-tpm-boot

[rugk]

Also asked for this in https://discussion.fedoraproject.org/t/full-disk-encryption-fde-for-coreos/994/.

[sghosh151]

Would be good to integrate Tang/Clevis network bound disk encryption as part of ignition options
https://github.com/latchset/clevis

[ajeddeloh]

Changed issue name to be more precise.

@sghosh151 do you have specific use cases you want to enable?

cc @lucab since he did some related work with LUKS

Also worth looking at #515

[sghosh151]

On premise baremetal deployments.
Leverage data center specific tang service for obtaining host specific key for encrypted LUKS volumes. Allow automated deployment, upgrades, reboots without manual passphrase requirements.

Moving servers or disks to a different network or tang server will disable automated decryption.

[rugk]

BTW see also the issue that linked to this one here: coreos/fedora-coreos-tracker#287

[rugk]

May I ask what the status of this issue is?

[orange888]

Any update on luks?
Thanks.

[arithx]

#960

[arithx]

The initial implementation has been merged in #960

I've gone ahead and created a new label component/luks for tracking issues, enhancements, etc.

For FCOS users we still have a bit of work left before it starts making it's way into the images (coreos/fedora-coreos-config#503 & a new Ignition release).

Going to close this issue out.

[rugk]

coreos/fedora-coreos-config#503 has been merged, too now.
So as far as I see, the only thing blocking LUKS support for now is a "new Ignition release", is not it?

[rugk]

Ah okay, checking the releases (v2.6.0 is latest) it mentions LUKS a few times already. So only LUKS support for the root file system (see coreos/fedora-coreos-config#503) was missing?
Is there "full LUKS support" then?

[jlebon]

Yes, all the pieces are in and should make it into the next set of releases. But note that it's still experimental.