From mboxrd@z Thu Jan 1 00:00:00 1970 From: Josh Durgin Subject: Re: passing secrets to block devices Date: Thu, 20 Oct 2011 14:48:15 -0700 Message-ID: <4EA0971F.2010601@dreamhost.com> References: <4EA068D2.4030101@dreamhost.com> <20111020192417.GB16526@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mail.hq.newdream.net ([66.33.206.127]:34673 "EHLO mail.hq.newdream.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751719Ab1JTVsQ (ORCPT ); Thu, 20 Oct 2011 17:48:16 -0400 In-Reply-To: <20111020192417.GB16526@redhat.com> Sender: ceph-devel-owner@vger.kernel.org List-ID: To: "Daniel P. Berrange" Cc: libvir-list@redhat.com, qemu-devel@nongnu.org, ceph-devel@vger.kernel.org, Kevin Wolf 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 ?) >> >> 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60434) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RH0TQ-0004zj-TO for qemu-devel@nongnu.org; Thu, 20 Oct 2011 17:48:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RH0TJ-0002gs-N2 for qemu-devel@nongnu.org; Thu, 20 Oct 2011 17:48:19 -0400 Received: from mail.hq.newdream.net ([66.33.206.127]:39415) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RH0TJ-0002gd-9X for qemu-devel@nongnu.org; Thu, 20 Oct 2011 17:48:17 -0400 Message-ID: <4EA0971F.2010601@dreamhost.com> Date: Thu, 20 Oct 2011 14:48:15 -0700 From: Josh Durgin MIME-Version: 1.0 References: <4EA068D2.4030101@dreamhost.com> <20111020192417.GB16526@redhat.com> In-Reply-To: <20111020192417.GB16526@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] passing secrets to block devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: libvir-list@redhat.com, Kevin Wolf , ceph-devel@vger.kernel.org, qemu-devel@nongnu.org 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 ?) >> >> 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.