Re: [libvirt] passing secrets to block devices

On Thu, Oct 20, 2011 at 11:30:42AM -0700, Josh Durgin wrote: > We're working on libvirt support for block device authentication [1]. To > authenticate, rbd needs a username and a secret. Normally, to > avoid putting the secret on the command line, you can store the secret > in a file and pass the file to qemu, but when this is automated, > there's no good way to know when the file can be removed. There are > a few ways to pass the secret to qemu that avoid this problem: This is the same problem the iSCSI block driver currently faces, and also if the Curl/HTTP block driver wanted todo authentication we'd hit this. So it isn't unique to Ceph/RBD. > 1) pass an fd to an unlinked file containing the secret > > This is the simplest method, but it sounds like qemu developers don't > like fd passing from libvirt. [2] That would be workable, but it means people trying to run the libvirt QEMU command line themselves, would have to remove some args.

> 2) start guests paused, without disks requiring authentication, then > use the drive_add monitor command to attach them > > This would make disks with authentication somewhat of a special case > in libvirt, but would be simple to implement, and require no qemu changes. This makes it very hard for people to take the libvirt QEMU command line and run themselves, since now an entire chunk of it is just missing. So I really don't want to go down this route. > 3) start guests paused, then send the secret via a new QMP/HMP > command (block_set_conf<key> <value>?) > > This is a larger change, but it would be more generally useful for > changing configuration at runtime. I don't think you need to try to solve the problem of a general purpose 'set configuration' command here, not least because that will likely get you drawn into a huge discussion about qemu device configuration in general which will likely never end. We already have a 'block_passwd' command for setting qcow2 decryption keys. These aren't decryption passwords, rather they are authentication passwords, so they're a little different, but I think this command could still likely be leveraged for Ceph/iSCSI/etc auth passwords. Ideally, we want to cope with having both a decryption& auth password for the same block device. eg, an encrypted qcow2 image accessed, over HTTP would require both. In these case there are 2 block drivers involved, the 'qcow2' driver and the 'http' driver. So perhaps an extra parameter for the 'block_password' command to identify which driver the password is intended for is the right approach. If omitted,we'd default to 'qcow2' for back compat. So eg, for a encrypted qcow2 disk accessed over http -drive file=http://fred@host/my.iso,format=qcow2,id=mydrive the app would invoke { "execute": "block_password", "argument": { "device": "mydrive", "driver", "qcow2", "password", "12345" } } { "execute": "block_password", "argument": { "device": "mydrive", "driver", "curl", "password", "7890" } } For Ceph/RBD with a plain file, you'd just do { "execute": "block_password", "argument": { "device": "mydrive", "driver", "rbd", "password", "7890" } }