qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC][BROKEN] rbd: Allow configuration of authenticatio


From: Daniel P . Berrangé
Subject: Re: [Qemu-devel] [RFC][BROKEN] rbd: Allow configuration of authentication scheme
Date: Fri, 20 Apr 2018 14:55:29 +0100
User-agent: Mutt/1.9.2 (2017-12-15)

On Fri, Apr 20, 2018 at 03:34:26PM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé <address@hidden> writes:
> 
> > On Wed, Apr 18, 2018 at 06:52:08PM +0200, Kevin Wolf wrote:
> >> Am 18.04.2018 um 18:34 hat Daniel P. Berrangé geschrieben:
> >> > On Wed, Apr 18, 2018 at 06:28:23PM +0200, Kevin Wolf wrote:
> >> > > Am 18.04.2018 um 17:06 hat Markus Armbruster geschrieben:
> >> > 
> >> > > >     Note that users can still configure authentication methods with a
> >> > > >     configuration file.  They probably do that anyway if they use 
> >> > > > Ceph
> >> > > >     outside QEMU as well.
> >> > > 
> >> > > This solution that we originally intended to offer was dismissed by
> >> > > libvirt as unpractical: libvirt allows the user to specify both a 
> >> > > config
> >> > > file and a key, and if it wanted to use a config file to pass the key,
> >> > > it would have to create a merged config file and keep it sync with the
> >> > > user config file at all times. Understandable that they want to avoid
> >> > > this.
> 
> Yes.
> 
> >> > Even if the config file does have auth info setup, we can't assume that
> >> > the QEMU VMs are supposed to use the same auth info.
> 
> If the user tells you to use this config file, you better assume that's
> what he wants.
> 
> >> >                                                      In fact 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.
> 
> Yes, unless the user tells you otherwise.
> 
> >> > So from libvirt POV we want to pretend the config file does not exist at
> >> > all and explicitly pass everything that is needed via normal per-disk
> >> > setup for blockdev.
> >> 
> >> From the rbd driver:
> >> 
> >>  * The "conf" option specifies a Ceph configuration file to read.  If
> >>  * it is not specified, we will read from the default Ceph locations
> >>  * (e.g., /etc/ceph/ceph.conf).  To avoid reading _any_ configuration
> >>  * file, specify conf=/dev/null.
> >> 
> >> So what we actually expected libvirt to do is to create a config file
> >> for each rbd image and pass that to qemu. However, libvirt allows the
> >> user to specify their own config file and passes that, and therefore
> >> doesn't want to create its own config file. If the user doesn't specify
> >> a config file, libvirt should probably indeed use /dev/null at least.
> >
> > 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.

In this specific case of passwords, historically the user providd
the password in the XML, and we passed that to QEMU using the URI
format. We want to change to the blockdev schema instead of URI
so we can use secrets.

IOW, if the user has been relying on the global config file to
provide passwords QEMU needed, we would never have been setting
a password in the URI in the past,  and we would also not set
a password secret in the blockdev schema either. So there's no
compat problem here.

> <heresy>If you're going to break config files on every new feature
> anyway, why not break them once and for all, then use them the way we
> actually expected libvirt to do.</heresy>

We're not breaking it, so there's no issue here.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]