CDH | EncryptedDirectMount plugin for SecureMount

[Xynnn007]

After #539 is merged. I'd like to implement a simple secure mount plugin independent on any enterprise storage services. The principle behind is like @arronwy 's excellent work https://github.com/kata-containers/kata-containers/pull/4885/files#diff-261600ce2c691940f7e65ecf8f5768c47d9efabe42000272e408029449dc22fb

The architecture diagram looks like

The straightforward result is that

• TEE could use outer storage media but outside the TEE only ciphertext could be seen

The rationale behind this is to provide

• A quick start up for users to use secure mount
• Make it easier e2e ci for secure mount

Discussions

1. Where to find the decryption key?

There should provide two ways:

• The key is generated inside TEE guest. This hints that the storage will be lost if the pod exits or crashes.
• The key is retrieved from KBS/KMS

The key source could be specified by parameter.

[fitzthum]

This is a great proposal. I think it will also help us develop tests for the secure storage feature (which will be required when we try to add it to kata). It would be cumbersome if the tests depended on some specific cloud offering.

This can also help us convince people to include gocryptfs in the generic confidential image.

I guess the question about the decryption key is about whether it is persistent storage or ephemeral storage. Ideally we could support both. This can probably be configured at the level of the storage driver in the CDH. We can have an option that specifies whether we should generate a new encryption key or try to fetch one from KMS/KBS.

[ChengyuZhu6]

Currently, we'll move the logic that encrypts the block device from host to guest in order to achieve trusted storage for pulling images.

[ChengyuZhu6]

Currently, we'll move the logic that encrypts the block device from host to guest in order to achieve trusted storage for pulling images.

Discussion: kata-containers/kata-containers#9999 (comment)

[ChengyuZhu6]

So I think the task list is as follows:

• Secure mount api in cdh.
• Encrypt a block device and mount it to a specified path (moving the logic of trusted storage from Kata to CDH) .
• Decrypt a block device and mount it to a specified path (the feature of secure mount).

[bpradipt]

@ChengyuZhu6 few questions for my understanding

1. Is there a restriction on how the block device is provided to the guest or only thing that matter for CDH is a source block device inside the guest (TEE) which will be encrypted inside the guest when CDH starts?
2. Adding to the previous question - can the block device can be a memory backed (ephemeral), locally attached from the host or network mounted directly inside the guest?

[ChengyuZhu6]

@ChengyuZhu6 few questions for my understanding

1. Is there a restriction on how the block device is provided to the guest or only thing that matter for CDH is a source block device inside the guest (TEE) which will be encrypted inside the guest when CDH starts?

@bpradipt There is no specific restriction on how the block device is provided to the guest. The caller of CDH (such as kata) is responsible for mounting the block device to the guest.

[ChengyuZhu6]

Adding to the previous question - can the block device can be a memory backed (ephemeral), locally attached from the host or network mounted directly inside the guest?

I have worked on merging trusted storage into kata main and adding related tests to kata CI kata-containers/kata-containers#9999. This involves using a block device created on the host and mounting it to the guest through PVC in k8s. So locally attached from the host is worked.

[ChengyuZhu6]

Adding to the previous question - can the block device can be a memory backed (ephemeral), locally attached from the host or network mounted directly inside the guest?

I have worked on merging trusted storage into kata main and adding related tests to kata CI kata-containers/kata-containers#9999. This involves using a block device created on the host and mounting it to the guest through PVC in k8s. So locally attached from the host is worked.

And as the document (https://github.com/confidential-containers/confidential-containers/blob/main/guides/ephemeral_storage.md) described, we can use a third-party csi-driver to achieve to use ephemeral volumes.

[ChengyuZhu6]

Adding to the previous question - can the block device can be a memory backed (ephemeral), locally attached from the host or network mounted directly inside the guest?

I think the only restriction is that it needs to be a block device in the guest. I’m not sure if the block device can be memory-backed. I think the second and third options are feasible, but I haven’t tried the last one yet.

[zvonkok]

This will "only" support one party in the VM? What if we have multiple personas and each of them is brining an own block device meaning different keys? How do we know which key belongs to which block storage device?

[Xynnn007]

@zvonkok Could you take an example for multiple persona? This is interesting and more complex.

[ChengyuZhu6]

What if we have multiple personas and each of them is brining an own block device meaning different keys? How do we know which key belongs to which block storage device?

@Xynnn007 @zvonkok I think securemount API should now handle a single block device per call. If users need to encrypt multiple block devices, they should call the API for each device, Such as:

for dev in devices {
  if need encrypt {
      storage = new Storage{
          dev.id,
          encrypt_type,
          encrypt_key,
          ...
      }
      cdh.secure_mount(storage)
  }
}

This approach will simplify the API’s logic. In the future, after implementing single block device encryption, we can consider expanding the API to handle multiple block devices in one call if necessary. WDYT?

[ChengyuZhu6]

cc @fitzthum

[fitzthum]

@zvonkok We still don't really have a great framework for handling scenarios with multiple personas, but there are a few things I can imagine for storage. Let's say that there is a workload owner and a data owner, who is going to temporarily grant access to some data. Basically this means that the key for decrypting the block device and some of the logistics of exposing the storage to the guest will involve the data owner.

One potential way to support this would be to store the storage key in an HSM operated by the data owner. The KBS abstraction in the CDH can connect to HSMs. The KBS would be used to provide some credentials for the HSM connection. The data owner would need to coordinate with the workload owner to provide these. The data owner could then have more fine-grained access control by manipulating the HSM, although note that the CDH requests to the HSM don't typically include any context about the guest.

So for this proposal, let's just try to be flexible about how we specify the key. Rather than just pointing to a resource uri, we should also allow the KBS backend to be specified, like it can be with sealed (vault) secrets. wdyt?