Description of problem: LUKs key management for VMs running on RHV We want to encrypt VMs root disk and non root disk by LUKs encryption and that encryption related things should be taken care by RHV. Customer's statement :- I'm required to run our guest linux VMs (RHEL7.2) with full LUKs encryption of their root fs and any extra virtual disks attached. Having to enter a LUKS key phrase on boot of each VM is not practical. Does RHEV have any sort of LUKS key management for supporting LUKS encrypted virtual machines?
I have communicated same to the customer. Customer didn't came back yet.
there is https://bugzilla.redhat.com/show_bug.cgi?id=1336045 with a similar goal, but in general this is already covered by rhel I'd say ( https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-using_network-bound_disk_encryption )
Thank you for submitting this request for inclusion in Red Hat Virtualization. We've carefully evaluated the request, but are unable to include it in a future release. To request that Red Hat re-consider this request, please re-open the bugzilla via appropriate support channels and provide additional business and/or technical details about its importance to you.
BZ<2>Jira Resync
I understand there may by situations where encryption on storage level is necessary, but I am wondering how well are customers aware of other existing methods for key management. For example network-bound encryption [1] provided by teng/clevis. [1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/configuring-automated-unlocking-of-encrypted-volumes-using-policy-based-decryption_security-hardening
(In reply to Tomáš Golembiovský from comment #13) > I understand there may by situations where encryption on storage level is > necessary, but I am wondering how well are customers aware of other existing > methods for key management. For example network-bound encryption [1] > provided by teng/clevis. > > [1] > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/ > html/security_hardening/configuring-automated-unlocking-of-encrypted-volumes- > using-policy-based-decryption_security-hardening From a customer pov: See comment 8, I am aware of clevis/tang. But the golden image scenario is not covered by clevis/tang ( https://github.com/osbuild/osbuild-composer/issues/326 ). Once this is possible I would see no need for another layer of encryption outside of the individual VMs.
Milan, can you please check what needs to done on our side to support this with vTPM?
Virtual TPM can assist with storing a LUKS encryption key into the virtual TPM (and then, I think, clevis can be used to load the key from TPM and arrange disk decryption inside the guest on boot). However, this TPM data must also be stored somewhere. In the currently developed implementation, it's stored in the following places: - Local file system on the host. - Engine database. - TLS connection between Engine and the host, or between hosts on migrations. In order to protect the decryption keys from an untrusted administrator, such an administrator must not have access to the hosts, Engine and the Engine database (including its backups etc.). Compared to a manually provided password, this means Engine and its database must be protected from untrusted administrators; it's a choice between convenience and security. Additionally, unencrypted data can appear in images of suspended VMs or snapshots with memory, so giving untrusted administrators access to storage and Engine Web UI or REST/host API is dangerous even with a manually entered password. And finally, if a new encryption key is stored into TPM and synchronization between Engine and the host fails, the updated key may be lost -- it's important to backup the data properly to a safe place and not to depend on a single key. In summary, depending on particular customer's needs and policies and clevis or other functionality, virtual TPM may or may not help with automatic disk decryption. But untrusted administrators must not have access to Engine, RHV management generally and the hosts under any circumstances, even with manually provided passwords.
Would TPM support together with introducing an extra permission that would be needed to perform VM operations writing TPM data to storage in some form (VM export, snapshots with memory, hibernation) solve the needs? This way, common images on the storage could contain encrypted file systems that couldn't be decrypted without access to TPM data, which is stored only in the Engine database and on hosts where the corresponding VMs are running. Administrators with the given permission could still produce images including TPM data.
(In reply to Milan Zamazal from comment #17) > Would TPM support together with introducing an extra permission that would > be needed to perform VM operations writing TPM data to storage in some form > (VM export, snapshots with memory, hibernation) solve the needs? This way, > common images on the storage could contain encrypted file systems that > couldn't be decrypted without access to TPM data, which is stored only in > the Engine database and on hosts where the corresponding VMs are running. > Administrators with the given permission could still produce images > including TPM data. Hi, yes, this would be sufficient for me. What I need at the end of the days is data-at-rest encryption with my virtualization. I would love for this to be solved inside of the OS in a very general manner (ie clevis/luks with additional features), but I am happy with a solution that solves this inside of the virtualization platform. This in turn means I will have a couple of different solutions depending on where I put a system but I can work with that. I do wonder how your proposed solution works with hosted-engine, because there you will have a kind of chicken/egg problem :) Greetings Klaas
As discussed above, this can be achieved using vTPM
The changes we've introduced in 4.4.5-4.4.7 cover this flow with vTPM