On Mon, Oct 19, 2015 at 05:05:58PM +0100, Alex Bennée wrote: > Daniel P. Berrange <berra...@redhat.com> writes: > > > There are a variety of places where QEMU needs to have access > > to passwords, encryption keys or similar kinds of secrets. > > > <snip> > > > > Example usage for creating secrets... > > > > Direct password, insecure, for ad-hoc developer testing only > > > > $QEMU -object secret,id=sec0,data=letmein > > > > Indirect password via a file, good for production > > > > echo -n "letmein" > mypasswd.txt > > $QEMU -object secret,id=sec0,file=mypasswd.txt > > > > The file based approach supports file descriptor passing, > > so mgmt apps can use that to dynamically add passwords to > > running QEMU. > > > > There is a better way though, which is to use an encrypted > > secret. The intent here is that a mgmt app (like libvirt) > > will generate a random AES-256 key for each virtual machine > > it starts (saved in eg /var/run/libvirt/qemu/$GUEST.key) > > It can then use the direct password passing, but encrypt > > the data. > > > > $QEMU \ > > -object > > secret,id=secmaster0,file=/var/run/libvirt/qemu/$GUEST.key,format=base64 \ > > -object secret,id=sec0,data=[base64 ciphertext],\ > > keyid=secmaster0,iv=[base64 initialization vector] > > > > This means that the mgmt app does not need to worry about > > file descriptor passing at all. It can just use regular > > object properties, safe in the knowledge that the data is > > protected by a secret AES key shared only between QEMU > > and the mgmt app. > > > > Use of encrypted secrets is not restricted to directly > > provided inline data. If the secret is stored in an > > external file, that can be encrypted too > > > > $QEMU \ > > -object > > secret,id=secmaster0,file=/var/run/libvirt/qemu/$GUEST.key,format=base64 \ > > -object secret,id=sec0,file=/some/secret/file.aes,\ > > keyid=secmaster0,iv=[base64 initialization vector] > > > > > > > > Example usage for referencing secrets... > > > > CURL: > > > > $QEMU -object secret,id=sec0... \ > > -drive driver=http,url=http://example.com/someimg.qcow2,\ > > user=dan,passwordid=sec0 > > > > $QEMU -object secret,id=sec0... -object secret,id=sec1 \ > > -drive driver=http,url=http://example.com/someimg.qcow2,\ > > user=dan,passwordid=sec0,proxyuser=dan,passwordid=sec1 > > > > iSCSI: > > > > $QEMU -object secret,id=sec0... \ > > -drive driver=iscsi,url=iscsi://example.com/target-foo/lun1,\ > > user=dan,passwordid=sec0 > > > > RBD: > > > > $QEMU -object secret,id=sec0... \ > > -drive driver=rbd,file=rbd:pool/image:id=myname,\ > > auth-supported-cephx,authsecret=sec0 > > > > QCow/Qcow2 encryption > > > > $QEMU -object secret,id=sec0... \ > > -drive file=someimage.qcow2,keyid=sec0 > > So one use case which I don't see here but do on other programs that > need to access secrets is calling an external program and reading its > stdout. This is simpler than having to mess around with passing FDs > although there may be security concerns having QEMU create new tasks on > the system.
Spawning external programs is a rather heavyweight approach. I can see it being useful if you were locked into an existing API/syntax which you couldn't modify, but we don't have that restriction here. I'm also not a huge fan of having QEMU spawn a program that potentially has access to a large number of passwords that QEMU should not be able to access. I think passing in the required passwords explicitly as done here is a better approach. As noted earlier, FD passing is supported, but I don't think it is going to be commonly needed or used. At least libvirt would not use it, as providing the passwords directly, with encryption, is a more straightforward approach to implement. 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 :|
