On Thu, May 28, 2026 at 09:45:11 +0000, Tejus GK wrote: > > > > >> 2. In a managed direct migration workflow, an intermediary client brokers > >> the connection between > >> the source and destination. > > > > What do you mean by this? How is it brokered? Which part of the > > conenction? > > > > Do you mean the non-P2P migration mode? (which is the only case where > > the migration cookie wouldn't go directly from the source > > libvirtd/virtqemud to the destination libvirt/virtqemud) That one is > > secured by the connection transport mentioned above. > > > >> If the key is embedded within the migration cookie, this client gains > >> full visibility into the secret, creating a significant attack surface > >> within the system architecture. > > > > So IMO this point doesn't make sense either. > > > Hi Peter, thank you for the response! > For the above, we indeed meant it for the non P2P migration mode, > So since the 2 libvirts aren’t talking to each other in this case, the > client, must inform the destination libvirt on > what the PSK is, and in turn for that, the src libvirt must inform the client > what the PSK is.
Actually the client library doesn't have to do anything. The PSK would be generated by the source libvirt daemon and put into the migration cookie. The client handling the migration needs to handle the cookie anyways, so that is for free. The setup would also work out of the box (if both daemons are new enough) which would allow us to actually enable TLS by default. Obviously the client inbetween would get to see the PSK, but as explained in my previous reply, the client itself needs to have a connection with 'domain:write', 'domain:start' and 'domain:migrate' permission (if you'd be using ACLs) so the on-disk key can't really be protected from such client anyways. >I think all this would > have been much easier, if the client controls the lifecycle of the PSK. As said above I don't think that this is the case. In fact for any user it's the simplest if the PSK handling happens automagically without any setup. > > Even outside this scenario, handing over the the PSK lifecycle management to > the client provides > greater flexibility and control over PSK parameters such as its key size, > cryptographic algorithm, Agreed. We could add config options for these. > and rotation policies, Rotation policy doesn't make sense as an advantage because you don't ever get better than single-use keys. > which are indeed some aspects that clients may prefer to manage > according to their own security requirements, similar to what happens right > now in the x509 scenario. With this argument, for any client who really wants to deal with generating the PSK, it would IMO make more sense to have the PSK as a virSecret and use it for a single VM. Storing them as keys is IMO inflexible and actually much worse than the x509 setup because you can't invalidate access to a single (e.g. compromised key) without rekeying everything with a completely shared PSK.
