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

[John Ferlan]

On 07/05/2016 09:37 AM, Daniel P. Berrange wrote:
> 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.
> 

That then requires the "usage" of a <secret> in the domain xml to list
the volume path. So rather than:

      <encryption format='luks'>
         <secret type='passphrase' usage='luks_example'/>
      </encryption>

it'd be:

      <encryption format='luks'>
         <secret type='volume' usage='$LUKS_VOLUME_PATH'/>
      </encryption>

(or of course uuid='$UUID')

I was looking to have a "more clear" delineation between a secret that
"could be" generated automagically (e.g. some randomly generated
passphrase) for a qcow volume and one that "someone" defines/sets for a
luks volume.


The automagic generation is done in virStorageGenerateQcowEncryption and
virStorageGenerateQcowPassphrase

John

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