[libvirt] [PATCH v3 02/10] conf: Add new secret type "passphrase"

[Daniel P. Berrange]

On Tue, Jul 05, 2016 at 09:33:30AM -0400, John Ferlan wrote:
> 
> 
> On 07/04/2016 09:42 AM, Daniel P. Berrange wrote:
> > On Fri, Jun 24, 2016 at 04:53:31PM -0400, John Ferlan wrote:
> >> Add a new secret type known as "passphrase" - it will handle adding the
> >> secret objects that need a passphrase without a specific username.
> >>
> >> The format is:
> >>
> >>    <secret ...>
> >>      <uuid>...</uuid>
> >>      ...
> >>      <usage type='passphrase'>
> >>        <name>mumblyfratz</name>
> >>      </usage>
> >>    </secret>
> > 
> > I'm not seeing the purpose of adding this secret usage type. It also
> > seems quite different from the usage types we have already.
> > 
> > The essential purpose of the usage 'name' is to allow you to figure
> > out what corresponding libvirt object is using the secret. So for
> > example with usage type=volume, the name refers to the disk path
> > of the volume. With usage type=iscsi or type=ceph, the name refers
> > to the server name.
> > 
> > This usage type=passphrase is not directly associating the secret
> > with anything, and doesn't appear to have any defined sematics for
> > what the 'name' should contain or refer to.
> > 
> > This all feels quite odd & possibly wrong to me.
> > 
> 
> FWIW: I'm on PTO this week, but I do have a few minutes of time to
> provide some feedback...

NP, we can wait until you return to resolve it - as long as we decide
before the 2.1 release we're fine.


> This type of secret started out in my own branches as a "luks" secret,
> since that's what it was designed to (at least) initially support.
> 
> After starting to think and work with the TLS code, I modified it to a
> "key" secret - mainly because they were the essentially the same type of
> secret. At that time I did consider passphrase, but wasn't convinced it
> was the best name, so "key" was it (plus less characters to type). I
> also figured it was better to use the same type of secret since they
> provided essentially the same functionality - a key/passphrase to be
> provided for some other object to unlock access to the object (for lack
> of a better term, at this moment).
> 
> Both series were posted and I noted the common parts of both. The luks
> code was reviewed and the suggestion was to use "passphrase", so I went
> that way.

Ok, so for LUKS i'd expect us to continue to just use the existing
USAGE_TYPE_VOLUME we already have for this purpose.

> If it needs to change again, that can be done when I'm back next week
> (or by someone before I get back). If the two need to be separated
> that's fine too. They'll share a lot of similarities though. I think
> other than the target service object they support, the iscsi and ceph
> secret are fairly similar. So it's not unprecedented. If they are
> separated, then does that mean there's a TCPTLS secret, a MIGRATIONTLS
> secret, and an NBDTLS secret?

The secret usage is associated with a particular type of object requiring
credentials. In that case the object type is a TLS key. The fact that you
can use the TLS key for different services is not relevant. So I'd say
the usage would be USAGE_TYPE_TLS_KEY and the data associated with it
would be the path of the TLS key pem file.

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 :|