Ciao Robert, Robert Sander <ceph-users@ceph.io> writes:
Hi,
Am 21.08.26 um 4:10 PM schrieb Nico Schottelius:
a) All VPS/VMs need to be restarted To be able to rotate keys, aside from the almost impossible flow to actually doing the rotation (more to that below), this will affect every consumer of VMs. The usual setup is that all hypervisors are using the same key.
VM live migration should be able to do the trick here. When the new compute node already has the new key and the librbd version to support it.
That's a very good point. However this might also need work (or hacks) in the hypervisor sphere, to support using different keys in the 2 qemu processes. By default in opennebula, the ceph key is saved in a libvirtd secret. So in the best case, the new process will read it from the local secret store. In the not so great case, opennebula (and other hypervisors) might infer the key from the previously deployed VM, instead of reading it from the local secret store. (*)
I'm not saying anything cannot be done, but the way how this vulnerabilty is solved will cause major headache around the industry.
IMHO we will see a muted health warning for the years to come.
Agreed. BR, Nico (*) I'm not sure about the state of other hypervisors, but in the opennebula case keys are actually embededd in the XML VM definition (sic!) that is saved in the database (sic!!) and copied on creation of the VM (!!!) and will never every be changed. A likely working hack is to modify the key inside the XML inside the database and then trigger live migration with a small time window of uncertainty that if the VM crashes on the original host before the live migration is triggered, it will likely not restart. -- Sustainable and modern Infrastructures by ungleich.ch