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

[Peter Krempa]

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.

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.