Re: [libvirt] [PATCH 2/4] qemu: Introduce qemuBuildSecretObjectProps
On Wed, Jun 01, 2016 at 09:04:00AM -0400, John Ferlan wrote:
My quandary is less about the qemu-img infrastructure than the
storage
driver code.
That is, it's "less clear" in my mind how the storage_backend.c code
would need to handle a ",file=" for its short lived master key. Where to
create the file? What issues around permissions will there be?
Basically anything that virSecurityManagerDomainSetPathLabel handles for
the domain master key. I've been working under the assumption that it'll
need to be done, but hadn't quite got that far yet.
I see three possible options
1 Have storage driver create a random master key when libvirtd starts up
and use that with all qemu-img invokations
2 Have storage driver create a random master key per pool and use that
with all qemu-img invokations against that pool
3 Ignore master keys entirely and just put the encryption key for the
luks volume in a file directly. ie just one secret object using file=
instead of two secret objects
I think any of these are valid approachs really, so pick whatever you
think fits best
FWIW: The current "working" plan is a command such as:
qemu-img create -f luks \
--object secret,id=m0,file=$FILE \
--object secret,id=s0,data=$SECRET,keyid=m0,iv=$IV,format=base64 \
-o key-secret=s0 $LUKSFILE $SIZE
That's certainly a valid cli arg set if you pick my options 1/2 above
Thanks for the feedback so far... trying to make sure I don't get too
far off into the weeds and the dog just keeps looking at me like I'm
crazy when I ask her.
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 :|