Description of problem: The modern TLS credentials config in QEMU supports used of encrypted TLS keys. Libvirt supports this for migration/chardevs using the -object syntax, but does not yet support it for VNC. This will cause a problem if /etc/libvirt/qemu.conf sets a default_tls_x509_cert_dir to point to a set of encrypted x509 creds, and the user has not set different creds with vnc_tls_x509_cert_dir. We must fix that problem with use of default_tls_x509_cert_dir for VNC, and also allow vnc_tls_x509_secret_uuid parameter to be used. Version-Release number of selected component (if applicable): 4.5.0-1.el8
Proposed upstream patches: https://www.redhat.com/archives/libvir-list/2019-January/msg00490.html
v2: https://www.redhat.com/archives/libvir-list/2019-January/msg00689.html
Pushed as: commit 2e2b0d69a99e9f985796f8399fdc8f2253a53e59 Author: Ján Tomko <jtomko> CommitDate: 2019-01-22 12:18:28 +0100 qemu: add support for encrypted VNC TLS keys Use the password stored in the secret driver under the uuid specified by the vnc_tls_x509_secret_uuid option in qemu.conf. https://bugzilla.redhat.com/show_bug.cgi?id=1602418 Signed-off-by: Ján Tomko <jtomko> Reviewed-by: John Ferlan <jferlan> git describe: v5.0.0-80-g2e2b0d69a9
Verified with libvirt-5.5.0-1.el8.x86_64. Test steps: 1.Define a secret: # cat tls-secret.xml <secret ephemeral='no' private='yes'> <description>sample tls secret</description> <usage type='tls'> <name>TLS_example</name> </usage> </secret> #virsh define secret.xml #virsh secret-list # virsh secret-list UUID Usage --------------------------------------------------------- 32526718-87f7-47a8-ac13-bf48cc639aa0 tls TLS_example 2.Set a value to the secret: # MYSECRET=`printf %s "redhat" | base64` #virsh secret-set-value 32526718-87f7-47a8-ac13-bf48cc639aa0 $MYSECRET Secret value set 3.Set vnc secret ane enable vnc_tls in qemu.conf and restart libvirtd service: #vim /etc/libvirt/qemu.conf vnc_tls =1 vnc_tls_x509_secret_uuid = "32526718-87f7-47a8-ac13-bf48cc639aa0" #systemctl restart libvirtd 4.set up vnc tls env; 5.Start a guest with vnc graphical device: #virsh dumpxml vm2 | grep -i vnc <graphics type='vnc' port='5901' autoport='yes' listen='0.0.0.0'> <listen type='address' address='0.0.0.0'/> </graphics> 6.Check the qemu cmd line: #ps aux | grep -i passwordid ...-object tls-creds-x509,id=vnc-tls-creds0,dir=/etc/pki/libvirt-vnc,endpoint=server,verify-peer=no,passwordid=vnc-tls-creds0-secret0 -vnc 0.0.0.0:1,tls-creds=vnc-tls-creds0... 7.Connect guest by vncviewer # vncviewer $hostname_or_ip:5901 -X509CA /etc/pki/libvirt-vnc/ca-cert.pem Click on 'yes' in popped vncviewer window to continue, can connect guest successfully. 8.Also check there are no memory leak while starting/destroying guest when vnc tls secret enabled.
Also test setting a non-exist secret uuid in the qemu.conf, can get expected error info. Test steps: 1.Set a non-exist and malformed secret uuid in the qemu.conf and restart libvirtd: #vim /etc/libvirt/qemu.conf vnc_tls =1 vnc_tls_x509_secret_uuid = "1111-1111" #systemctl restart libvirtd 2.Start a guest with vnc graphical device: # virsh start vm2 error: Failed to start domain vm2 error: unsupported configuration: malformed TLS secret uuid '1111-1111' provided 3.Set a non-exist secret uuid in the qemu.conf and restart libvirtd: #virsh secret-list UUID Usage --------------------------------------------------------- 32526718-87f7-47a8-ac13-bf48cc639aa0 tls TLS_example #vim /etc/libvirt/qemu.conf vnc_tls =1 vnc_tls_x509_secret_uuid = "32526718-87f7-47a8-ac13-bf48cc639aaa" #systemctl restart libvirtd 4.Start a guest with vnc graphical device: # virsh start vm2 error: Failed to start domain vm2 error: Secret not found: no secret with matching uuid '32526718-87f7-47a8-ac13-bf48cc639aaa'
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, 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/RHBA-2019:3723