> On 28 May 2026, at 4:42 PM, Peter Krempa <[email protected]> wrote: > > !-------------------------------------------------------------------| > CAUTION: External Email > > |-------------------------------------------------------------------! > > 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.
Hi Peter, Thank you for the input. We're working on a revised design based on your recommendations and will share the update soon. Thanks Abhisek Panda
