Re: [Qemu-block] [Qemu-devel] [RFC][BROKEN] rbd: Allow configuration of authentication scheme

[Markus Armbruster]

Daniel P. Berrangé <address@hidden> writes:

> On Fri, Apr 20, 2018 at 04:50:38PM +0200, Markus Armbruster wrote:
>> Daniel P. Berrangé <address@hidden> writes:
>> 
>> > On Fri, Apr 20, 2018 at 03:34:26PM +0200, Markus Armbruster wrote:
>> >> Daniel P. Berrangé <address@hidden> writes:
>> >> 
>> >> > Yeah this is a mess - I wish we had never allowed users to pass a config
>> >> > file, and had used /dev/null all the time. Unfortunately changing either
>> >> > of these aspects would cause backcompat problems for existing 
>> >> > deployments
>> >> > now :-( So we just have to accept that the global config file is always
>> >> > in present, but none the less libvirt should try to specify things as
>> >> > fully as possible.
>> >> 
>> >> I'm afraid you get backward compatibility problems no matter what.
>> >> Whenever you extend libvirt to pass configuration C "via normal per-disk
>> >> setup for blockdev", it breaks user config files containing C, doesn't
>> >> it?
>> >
>> > That's not actually a problem here. We are only passing things to QEMU
>> > that the user already provided us in the XML file. If we gain support
>> > for passing a new item via the blockdev schema, then we'd only be
>> > passing that to QEMU if the user actually provided that item in the
>> > XML too.  We're not likely to pass a new config field without the
>> > user having asked us to first.
>> 
>> What made me guess otherwise: "to properly protect against compromised
>> QEMU, ideally every QEMU would use a completely separate RBD
>> user+password, so that compromised QEMU can't then access RBD disks
>> belonging to a different user" led me to assume libvirt would do this
>> automatically.
>
> No, a mgmt app like OpenStack would have to take care of that, as it
> needs the ability to manage the RBD user accounts & volume ACLs, to
> match the VMs you're creating.
>
> I just meant that even if you have auth info in the global RBD file,
> we shouldn't assume that auth info is desirable to use with QEMU. The
> global auth config file may be an administrative account, while each
> QEMU has its own restricted account.

I understand now, thanks.