* Re: [Qemu-devel] passing secrets to block devices
@ 2011-10-20 21:48 ` Josh Durgin
0 siblings, 0 replies; 16+ messages in thread
From: Josh Durgin @ 2011-10-20 21:48 UTC (permalink / raw)
To: Daniel P. Berrange; +Cc: libvir-list, Kevin Wolf, ceph-devel, qemu-devel
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.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [Qemu-devel] passing secrets to block devices
2011-10-20 21:48 ` [Qemu-devel] " Josh Durgin
@ 2011-10-21 1:37 ` shu ming
-1 siblings, 0 replies; 16+ messages in thread
From: shu ming @ 2011-10-21 1:37 UTC (permalink / raw)
To: Josh Durgin
Cc: Daniel P. Berrange, libvir-list, Kevin Wolf, ceph-devel,
qemu-devel
On 2011-10-21 5:48, Josh Durgin wrote:
> 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.
Does the authentication be calculated by QEMU finally? If it is, how
the "secrets" will be transported from libvirt to QEMU if they are in
different hosts?
IMO, It should be encrpted to prevent the peek from others on the network.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [Qemu-devel] passing secrets to block devices
@ 2011-10-21 1:37 ` shu ming
0 siblings, 0 replies; 16+ messages in thread
From: shu ming @ 2011-10-21 1:37 UTC (permalink / raw)
To: Josh Durgin; +Cc: libvir-list, Kevin Wolf, ceph-devel, qemu-devel
On 2011-10-21 5:48, Josh Durgin wrote:
> 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.
Does the authentication be calculated by QEMU finally? If it is, how
the "secrets" will be transported from libvirt to QEMU if they are in
different hosts?
IMO, It should be encrpted to prevent the peek from others on the network.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [Qemu-devel] passing secrets to block devices
2011-10-21 1:37 ` shu ming
@ 2011-10-21 7:05 ` Daniel P. Berrange
-1 siblings, 0 replies; 16+ messages in thread
From: Daniel P. Berrange @ 2011-10-21 7:05 UTC (permalink / raw)
To: shu ming; +Cc: Josh Durgin, libvir-list, Kevin Wolf, ceph-devel, qemu-devel
On Fri, Oct 21, 2011 at 09:37:11AM +0800, shu ming wrote:
> On 2011-10-21 5:48, Josh Durgin wrote:
> >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.
> Does the authentication be calculated by QEMU finally? If it is,
> how the "secrets" will be transported from libvirt to QEMU if they
> are in different hosts?
> IMO, It should be encrpted to prevent the peek from others on the network.
libvirt + QEMU are always run on the same host, communicating via a
UNIX domain socket. The application talking to libvirt might be on a
remote host, but the libvirt sockets all have strong encryption. Now
in theory you could have a mgmt app connecting to the monitor over
TCP, I don't think that is something anyone will seriously do in
practice. It doesn't offer any kind of authentication, so exposing
it to the network would be giving away effective remote root access.
So we should just consider the monitor socket to be a secure channel
for this discussion.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [Qemu-devel] passing secrets to block devices
@ 2011-10-21 7:05 ` Daniel P. Berrange
0 siblings, 0 replies; 16+ messages in thread
From: Daniel P. Berrange @ 2011-10-21 7:05 UTC (permalink / raw)
To: shu ming; +Cc: libvir-list, Kevin Wolf, ceph-devel, Josh Durgin, qemu-devel
On Fri, Oct 21, 2011 at 09:37:11AM +0800, shu ming wrote:
> On 2011-10-21 5:48, Josh Durgin wrote:
> >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.
> Does the authentication be calculated by QEMU finally? If it is,
> how the "secrets" will be transported from libvirt to QEMU if they
> are in different hosts?
> IMO, It should be encrpted to prevent the peek from others on the network.
libvirt + QEMU are always run on the same host, communicating via a
UNIX domain socket. The application talking to libvirt might be on a
remote host, but the libvirt sockets all have strong encryption. Now
in theory you could have a mgmt app connecting to the monitor over
TCP, I don't think that is something anyone will seriously do in
practice. It doesn't offer any kind of authentication, so exposing
it to the network would be giving away effective remote root access.
So we should just consider the monitor socket to be a secure channel
for this discussion.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: passing secrets to block devices
2011-10-20 21:48 ` [Qemu-devel] " Josh Durgin
@ 2011-10-21 7:05 ` Daniel P. Berrange
-1 siblings, 0 replies; 16+ messages in thread
From: Daniel P. Berrange @ 2011-10-21 7:05 UTC (permalink / raw)
To: Josh Durgin; +Cc: libvir-list, qemu-devel, ceph-devel, Kevin Wolf
On Thu, Oct 20, 2011 at 02:48:15PM -0700, Josh Durgin wrote:
> 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.
In absence of other suggestions, it sounds workable to me.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [Qemu-devel] passing secrets to block devices
@ 2011-10-21 7:05 ` Daniel P. Berrange
0 siblings, 0 replies; 16+ messages in thread
From: Daniel P. Berrange @ 2011-10-21 7:05 UTC (permalink / raw)
To: Josh Durgin; +Cc: libvir-list, Kevin Wolf, ceph-devel, qemu-devel
On Thu, Oct 20, 2011 at 02:48:15PM -0700, Josh Durgin wrote:
> 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.
In absence of other suggestions, it sounds workable to me.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: passing secrets to block devices
2011-10-20 21:48 ` [Qemu-devel] " Josh Durgin
@ 2011-10-21 8:30 ` Kevin Wolf
-1 siblings, 0 replies; 16+ messages in thread
From: Kevin Wolf @ 2011-10-21 8:30 UTC (permalink / raw)
To: Josh Durgin; +Cc: Daniel P. Berrange, libvir-list, qemu-devel, ceph-devel
Am 20.10.2011 23:48, schrieb 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.
This proposed interface solves a problem that is currently purely
theoretical. With blockdev-add and friends, we'll get all of this for
free, so I'm not excited about adding something preliminary now even
though there's no practical need.
For the rbd driver, please use the existing interface that qcow2 uses
for encrypted images.
Kevin
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [Qemu-devel] passing secrets to block devices
@ 2011-10-21 8:30 ` Kevin Wolf
0 siblings, 0 replies; 16+ messages in thread
From: Kevin Wolf @ 2011-10-21 8:30 UTC (permalink / raw)
To: Josh Durgin; +Cc: libvir-list, ceph-devel, qemu-devel
Am 20.10.2011 23:48, schrieb 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.
This proposed interface solves a problem that is currently purely
theoretical. With blockdev-add and friends, we'll get all of this for
free, so I'm not excited about adding something preliminary now even
though there's no practical need.
For the rbd driver, please use the existing interface that qcow2 uses
for encrypted images.
Kevin
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: passing secrets to block devices
2011-10-21 8:30 ` [Qemu-devel] " Kevin Wolf
@ 2011-10-21 8:40 ` Daniel P. Berrange
-1 siblings, 0 replies; 16+ messages in thread
From: Daniel P. Berrange @ 2011-10-21 8:40 UTC (permalink / raw)
To: Kevin Wolf; +Cc: Josh Durgin, libvir-list, qemu-devel, ceph-devel
On Fri, Oct 21, 2011 at 10:30:39AM +0200, Kevin Wolf wrote:
> Am 20.10.2011 23:48, schrieb 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.
>
> This proposed interface solves a problem that is currently purely
> theoretical. With blockdev-add and friends, we'll get all of this for
> free, so I'm not excited about adding something preliminary now even
> though there's no practical need.
Ok.
> For the rbd driver, please use the existing interface that qcow2 uses
> for encrypted images.
If you're ok with just reusing 'block_passwd' as it is today, with
no arg parameters, then that's fine with me too.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [Qemu-devel] passing secrets to block devices
@ 2011-10-21 8:40 ` Daniel P. Berrange
0 siblings, 0 replies; 16+ messages in thread
From: Daniel P. Berrange @ 2011-10-21 8:40 UTC (permalink / raw)
To: Kevin Wolf; +Cc: libvir-list, ceph-devel, Josh Durgin, qemu-devel
On Fri, Oct 21, 2011 at 10:30:39AM +0200, Kevin Wolf wrote:
> Am 20.10.2011 23:48, schrieb 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.
>
> This proposed interface solves a problem that is currently purely
> theoretical. With blockdev-add and friends, we'll get all of this for
> free, so I'm not excited about adding something preliminary now even
> though there's no practical need.
Ok.
> For the rbd driver, please use the existing interface that qcow2 uses
> for encrypted images.
If you're ok with just reusing 'block_passwd' as it is today, with
no arg parameters, then that's fine with me too.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
^ permalink raw reply [flat|nested] 16+ messages in thread