[libvirt] passing secrets to block devices

[Josh Durgin]

On 10/20/2011 12:24 PM, Daniel P. Berrange wrote:
> 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.

Isn't this already the case for chardevs? I can understand not wanting 
more things like that though.

>> 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" } }
>

This sounds good to me, although the same driver might use 
authentication and encryption. Adding another argument to specify 'auth' 
or 'encryption' would fix this, i.e.:

   { "execute": "block_password", "argument": { "device": "mydrive",
                                                "driver": "qcow2",
                                                "use": "encryption"
                                                "password": "12345" } }

I'll prepare a patch if there are no objections to this approach.