Bug 1352501
Summary: | [RFE] LUKs key management on RHV | ||
---|---|---|---|
Product: | Red Hat Enterprise Virtualization Manager | Reporter: | vaibhav <vpagar> |
Component: | RFEs | Assignee: | Milan Zamazal <mzamazal> |
Status: | CLOSED NEXTRELEASE | QA Contact: | meital avital <mavital> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | 3.5.0 | CC: | ahadas, berrange, cnagarka, emarcus, klaas, lsurette, michal.skrivanek, mkalinin, mtessun, mzamazal, rbalakri, srevivo, stefano.stagnaro, tgolembi, vpagar |
Target Milestone: | ovirt-4.4.9 | Keywords: | FutureFeature |
Target Release: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Fixed In Version: | ovirt-engine-4.4.9.2 | Doc Type: | Enhancement |
Doc Text: |
In this release, using virtual TPM, it is now possible to inject a LUKS encryption key to the guest operating system.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2021-10-18 11:40:52 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | Virt | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
vaibhav
2016-07-04 09:28:00 UTC
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 |