[libvirt PATCH v5 27/32] schema: add password configuration for ssh disk

[Jonathon Jongsma]

On 2/16/23 10:43 AM, Peter Krempa wrote:
> On Tue, Feb 14, 2023 at 11:08:14 -0600, Jonathon Jongsma wrote:
>> Right now, ssh network disks are not usable. There is some basic support
>> in libvirt that is meant to support disk chains that have backing disks
>> located at ssh urls, but there is no real way for a user to configure a
>> ssh-based disk.  This commit allows users to configure an ssh disk with
>> password authentication. Implementation will follow.
>>
>> <disk type='network'>
>>    <source  protocol='ssh' ...>
>>      <auth username='myusername'>
>>        <secret type='iscsi' usage='secretname'/>
>>      </auth>
>> </disk>
>>
>> Signed-off-by: Jonathon Jongsma <jjongsma at redhat.com>
>> ---
>>   docs/formatdomain.rst             | 27 ++++++++++++++-------------
>>   src/conf/schemas/domaincommon.rng | 23 ++++++++++++++++++++++-
>>   2 files changed, 36 insertions(+), 14 deletions(-)
>>
>> diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
>> index 36c6d87907..bf071255c5 100644
>> --- a/docs/formatdomain.rst
>> +++ b/docs/formatdomain.rst
>> @@ -2718,7 +2718,7 @@ paravirtualized driver is specified via the ``disk`` element.
>>      ``network``
>>         The ``protocol`` attribute specifies the protocol to access to the
>>         requested image. Possible values are "nbd", "iscsi", "rbd", "sheepdog",
>> -      "gluster", "vxhs", "nfs", "http", "https", "ftp", ftps", or "tftp".
>> +      "gluster", "vxhs", "nfs", "http", "https", "ftp", ftps", "tftp", or "ssh".
>>   
>>         For any ``protocol`` other than ``nbd`` an additional attribute ``name``
>>         is mandatory to specify which volume/image will be used.
>> @@ -2870,18 +2870,19 @@ paravirtualized driver is specified via the ``disk`` element.
>>      ``auth``
>>         :since:`Since libvirt 3.9.0` , the ``auth`` element is supported for a
>>         disk ``type`` "network" that is using a ``source`` element with the
>> -      ``protocol`` attributes "rbd" or "iscsi". If present, the ``auth`` element
>> -      provides the authentication credentials needed to access the source. It
>> -      includes a mandatory attribute ``username``, which identifies the username
>> -      to use during authentication, as well as a sub-element ``secret`` with
>> -      mandatory attribute ``type``, to tie back to a `libvirt secret
>> -      object <formatsecret.html>`__ that holds the actual password or other
>> -      credentials (the domain XML intentionally does not expose the password,
>> -      only the reference to the object that does manage the password). Known
>> -      secret types are "ceph" for Ceph RBD network sources and "iscsi" for CHAP
>> -      authentication of iSCSI targets. Both will require either a ``uuid``
>> -      attribute with the UUID of the secret object or a ``usage`` attribute
>> -      matching the key that was specified in the secret object.
>> +      ``protocol`` attributes "rbd", "iscsi", or "ssh". If present, the
>> +      ``auth`` element provides the authentication credentials needed to access
>> +      the source. It includes a mandatory attribute ``username``, which
>> +      identifies the username to use during authentication, as well as a
>> +      sub-element ``secret`` with mandatory attribute ``type``, to tie back to
>> +      a `libvirt secret object <formatsecret.html>`__ that holds the actual
>> +      password or other credentials (the domain XML intentionally does not
>> +      expose the password, only the reference to the object that does manage
>> +      the password). Known secret types are "ceph" for Ceph RBD network sources
>> +      and "iscsi" for CHAP authentication of iSCSI targets. Both will require
>> +      either a ``uuid`` attribute with the UUID of the secret object or a
>> +      ``usage`` attribute matching the key that was specified in the secret
>> +      object.
> 
> This paragraph doesn't really state what to put into 'type' for ssh as
> 'ceph' and 'iscsi' are only mentioned. For 'ssh' we need a 'ssh' type.

Hmm, do we also need a separate type for http auth as well, then? At the 
moment we seem to just re-use the 'iscsi' type for all of the http auth 
in our tests (e.g. disk-cdrom-network.xml, etc).

> 
> This will also tie nicely in case you want to do ssh key authentication
> with encrypted key, where you can pass the key via a different type
> 'ssh-key' or something like that to unlock the key.
>