Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1739557 - RFE: add support for native TLS encryption on migration TCP transport
Summary: RFE: add support for native TLS encryption on migration TCP transport
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm
Version: unspecified
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ovirt-4.4.0
: 4.4.0
Assignee: Milan Zamazal
QA Contact: Beni Pelled
URL:
Whiteboard:
Depends On: 1754533 1781149
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-08-09 13:56 UTC by Michal Skrivanek
Modified: 2020-08-04 13:27 UTC (History)
11 users (show)

Fixed In Version: vdsm-4.40.13
Doc Type: Enhancement
Doc Text:
With this update, you can enable encryption for live migration of virtual machines between hosts in the same cluster. This provides more protection to data transferred between hosts. You can enable or disable encryption in the Administration Portal, in the Edit Cluster dialog box, under Migration Policy > Additional Properties. Encryption is disabled by default.
Clone Of:
Environment:
Last Closed: 2020-08-04 13:27:17 UTC
oVirt Team: Virt
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github ansible ansible pull 65916 0 None closed Add migration_encrypted option 2020-12-07 07:59:34 UTC
Red Hat Product Errata RHEA-2020:3246 0 None None None 2020-08-04 13:27:55 UTC
oVirt gerrit 103074 0 'None' MERGED virt: Add support for TLS migrations 2020-12-07 07:59:32 UTC
oVirt gerrit 103136 0 'None' MERGED engine: Add is_migrate_encrypted to cluster and vm 2020-12-07 07:59:32 UTC
oVirt gerrit 103137 0 'None' MERGED webadmin: add Migrate encrypted to cluster and vm 2020-12-07 07:59:32 UTC
oVirt gerrit 103138 0 'None' MERGED engine: propagate encrypted property to vds 2020-12-07 07:59:32 UTC
oVirt gerrit 103676 0 master MERGED restapi: add encrypted to the migration options 2020-12-07 07:59:32 UTC
oVirt gerrit 103916 0 'None' MERGED libvirt: Don't link migration certificates to Vdsm certificates 2020-12-07 07:59:31 UTC
oVirt gerrit 104240 0 master MERGED tools: Add QEMU certificate authority 2020-12-07 08:00:00 UTC
oVirt gerrit 104791 0 master MERGED tools: Deploy QEMU migration certificates 2020-12-07 07:59:33 UTC
oVirt gerrit 105779 0 master MERGED virt: Use libvirt migration parameter for host name validation 2020-12-07 07:59:33 UTC

Description Michal Skrivanek 2019-08-09 13:56:58 UTC
This bug was initially created as a copy of Bug #1300769

we should actually do this for RHV as well, at least as an option. It shouldn't be hard to add, the TLS stuff should be all set....just toggle a flag.

Clone of QEMU bug to track libvirt enablement tasks for native TLS encryption with migration. 

+++ This bug was initially created as a clone of Bug #1300768 +++

Description of problem:
None of the QEMU migration transports have native support for encryption. As such apps/users needing security must tunnel the QEMU migration transport over another channel such as libvirt's secure connection. This is inefficient resulting in many more data copies and lower throughput for migration which reduces chances of it completing.

Providing native TLS encryption support for migration in QEMU will allow for secure migration with a lower performance overhead

Latest upstream code review posting is:

  https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg01914.html

Comment 1 Milan Zamazal 2019-08-13 15:03:55 UTC
To implement this functionality we will need (at least):

- To add support for TLS encryption option from Engine to VDSM.
- To add the option to Engine, in the cluster migration UI.
- Point libvirt/QEMU configuration to the right certificates.

Comment 2 Milan Zamazal 2019-09-04 15:42:03 UTC
There is an issue with certificates: We use destination IP address to initiate migrations, while the host certificates use host names. That means the destination (IP) address doesn't match the certificate and a TLS migration fails. We must ensure that IP addresses are put into the host certificates.

Comment 3 Dan Kenigsberg 2019-09-28 07:33:35 UTC
Note that the migration IP of a host can change if a new network is assigned the migration role, or when the migration network is attached to a host with a new static address, or if DHCP server provides a new address instead of renewing the host lease.
In these occasions, someone/something should enroll a new certificate to the host.

Comment 4 Milan Zamazal 2019-09-30 08:12:58 UTC
We've decided to solve the certificate problem by adding an option to libvirt that specifies what to verify in the destination certificate, see bug 1754533. As a temporary workaround until the libvirt feature is implemented, the host name is used in the connection URI when an encrypted migration is requested. This ignores contingent migration network, but we have no better option, since updating the certificates would be too complicated.

Comment 12 Beni Pelled 2020-06-30 08:44:02 UTC
Verified with:
- ovirt-engine-4.4.1.5-0.17.el8ev.noarch
- vdsm-python-4.40.20-1.el8ev.noarch

All tests [1] passed except HE migration which is waiting for [2]

[1] https://polarion.engineering.redhat.com/polarion/#/project/RHEVM3/wiki/Compute/4_4_Migration_Encryption
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1850909

Comment 16 errata-xmlrpc 2020-08-04 13:27:17 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (RHV RHEL Host (ovirt-host) 4.4), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2020:3246


Note You need to log in before you can comment on or make changes to this bug.