TheRealFalcon
commented
1 year ago @akutz , thanks for the proposal. You have some interesting ideas.
In your scenario, when you speak of bootstrap data, are you referring to the cloud-init user data? Also, if there was a scenario where the TPM is available pre-boot, why do we need a separate shared secret? Why wouldn't we be able to use the public EK directly to encrypt the bootstrap data?
We have explored the idea of working with TPMs in the past and how cloud-init could support confidential compute. In exploring this, we have run into a roadblock. On the public clouds we have tried, the vTPM of the instance isn't available until after the instance is started, but by the time the instance has started, the userdata has already been fed to the cloud. Thus we have no way of pre-encrypting the data. Do things work differently on VMWare?
That said, if this is a viable use case for any cloud currently,I think it'd be valuable to get the infrastructure in place.
akutz
Enhancement
There is often a need to bootstrap a guest with information that may be classified as sensitive, ex. a public/private key pair written out as files. While it is true that every datasource could develop their own means of handling this problem, it occurred to me recently that perhaps they do not have to do so.
I've been busy of late digging into how to leverage TPMs as a means to securely bootstrap machines (see https://github.com/google/go-tpm/pull/343 and https://github.com/vmware/govmomi/pull/3222), and developed a workflow for bootstrapping guests that leverages the TPM's existing endorsement key (EK):
MAX_SYM_SIZEfor portability with respect to TPMs.A secure bootstrap model has been demonstrated before, which eventually became Keylime. I think Keylime is great, and there is nothing in the above workflow that precludes leveraging Keylime for on-going, secure communication with a guest, either from/to Cloud-Init or other actors.
However, the bootstrap problem is one that I think can be addressed without requiring key exchange, either explicit attestation or storage, and instead rely on a simplified version (there may or may not be an auth policy that relies on a specific combination of PCRs) of implicit attestation via the EK, something every TPM already has or has the ability to determinstically generate. To that end, if an EK-based bootstrap model were adopted, it could be something that Cloud-Init directly utilized as opposed to leaving it up to every datasource implementation. For example, the Datasource interface could be augmented with:
With something like the above, it could be up to Cloud-Init core to handle interfacing with the TPM to decrypt the shared secret via the example outlined in
tpm2-ekunseal.sh. I imagine shell execing to tpm2-tools is a better option than requiring Cloud-Init to depend on tpm2-pytss directly. Plus, this way it keeps the use of encryption as optional without adding another dependency to Cloud-Init's Python modules.Anyway, I am quite happy to discuss this further if there is interest. Thanks!