Re: [Qemu-devel] [PATCH 00/17] Framework for securely passing secrets to QEMU

["Alex Bennée" <alex.bennee@linaro.org>]

Daniel P. Berrange <berrange@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.


-- 
Alex Bennée