Integrate remote attestation support using trustee

[travier]

Feature Request

For Confidential Computing use cases, we want to add support for setting up LUKS for the root device using a key that is fetched from a remote server as part of a remote attestation procedure. In our use case, we will be using trustee: https://github.com/confidential-containers/trustee.

Environment

What hardware/cloud provider/hypervisor is being used to run Ignition?

We will start with QEMU & Azure, and will likely extend to Bare Metal, GCP, AWS, etc.

Desired Feature

Add an entry to Ignition spec to tell it to use trustee to do fetch the key to setup LUKS for the root device.

Example Butane config:

variant: fcos
version: 1.7.0-experimental
boot_device:
  luks:
    trustee:
      - https://...
      - https://...

Ignition:

{
  "ignition": {
    "version": "3.6.0-experimental"
  },
  "storage": {
    "filesystems": [
      {
        "device": "/dev/mapper/root",
        "format": "xfs",
        "label": "root",
        "wipeFilesystem": true
      }
    ],
    "luks": [
      {
        "trustee": [
          "https://...",
          "https://..."
        ],
        "device": "/dev/disk/by-partlabel/root",
        "label": "luks-root",
        "name": "root",
        "wipeVolume": true
      }
    ]
  }
}

Other Information

See: https://github.com/confidential-clusters/investigations

[jlebon]

Can you expand on the theory of operation here? Will the node get its key from the KBS on every boot, similar to Tang? Ideally then, that gets implemented in clevis instead as an additional pin and not in Ignition (Ignition already supports arbitrary clevis pins though it could be promoted one level so it has proper sugar in the spec.)

[alicefr]

/cc

[travier]

Can you expand on the theory of operation here? Will the node get its key from the KBS on every boot, similar to Tang?

Yes, the node will re-do the attestation process to get the root LUKS key on every boot.

Ideally then, that gets implemented in clevis instead as an additional pin and not in Ignition (Ignition already supports arbitrary clevis pins though it could be promoted one level so it has proper sugar in the spec.)

We can try the clevis option as well. I think we may find other changes needed in Ignitions as we work on this.

[alicefr]

I think in this feature request we are missing a little piece.

For trustee in order to be able to retrieve the secret upon a successful attestation, the trustee attester needs to provide the path of the resource. Here, the path is for sure partially dependent on each node, so we cannot fully set it in ignition. However, the initial part might be common to all the nodes.

A secret resource is composed by <repository>/<type>/<tag>. For example, the repository could be set in ignition

[jlebon]

I think most of the work for this should land in clevis instead. It's also possible to have out-of-tree pins, but I also would be surprised if this wasn't already on their radar and we should collaborate there instead. cc @sergio-correia @sarroutbi

[sarroutbi]

Thanks for the ping, @jlebon.

I agree, this sounds like a perfect use case for a Clevis pin. The Clevis framework is designed to be pluggable, and we're very interested in supporting remote attestation workflows like Trustee for Confidential Computing.

Yes, I would strongly suggest creating a new trustee pin. The existing tang pin cannot be used because, as it has been discussed, it uses a completely different protocol.

• How to Create a New Pin

For anyone interested in contributing this, the best "how-to" guide is to follow the pattern of the existing pins. The source code is the best documentation:

• Sample pin: Recently, a PR for "new pins documentation" was merged. You can find the "template" for a new pin creation here: https://github.com/latchset/clevis/tree/master/src/pins/template

• Reference Implementation: As discussed, the Tang pin is the most relevant reference for creating a new network-bound pin. You can find its source code here: https://github.com/latchset/clevis/tree/master/src/pins/tang

• Core Components: If I understood the problem correctly, creating a new feature pin for this functionality involves implementing two main scripts (some extra work is needed, but let me focus on the important stuff at this moment) :

  • clevis-encrypt-trustee: This script would run once during setup. It would take the disk encryption key, perform the initial communication with the Trustee Key Brokering Service (KBS), and store the necessary metadata (like the KBS URL and the secret's resource path) in the LUKS header.

  • clevis-decrypt-trustee: This script runs on every boot. It reads the metadata from the LUKS header, gathers the necessary TPM/attestation evidence, communicates with the Trustee KBS to perform the attestation, and receives the key to unlock the volume.

Regarding @alicefr's point about the dynamic, node-specific secret path, I assume that this is something that can be handled perfectly within the clevis-encrypt-trustee script at binding time.

We would be happy to review a PR for this functionality and provide guidance. Please feel free to open an issue on the Clevis repository to track this feature request directly with us.

[alicefr]

@jlebon @sarroutbi clevis pins sound like a smart direction, although I have a question. How do we drop the clevis pin in coreos? This needs to be run with ignition, so we cannot really create a file. If this needs already to be present in the initrd, this will imply that we need to build a coreos custom image including the pin.
Or was your idea to include the trustee pin in clevis?

[sarroutbi]

@jlebon @sarroutbi clevis pins sound like a smart direction, although I have a question. How do we drop the clevis pin in coreos? This needs to be run with ignition, so we cannot really create a file. If this needs already to be present in the initrd, this will imply that we need to build a coreos custom image including the pin. Or was your idea to include the trustee pin in clevis?

I am not expert on Ignition, but, I agree that, for Clevis to unlock the disk using the new "Trustee" pin, that pin's script must already be present in the initrd when it starts. This is already done for those cases where we need to unlock encrypted root file system. Clevis pin scripts (and its dependencies) are included in initrd. What I sincerely ignore is if this is possible in Ignition.