ac1d887849
Introduce a new QCryptoSecret object class which will be used
for providing passwords and keys to other objects which need
sensitive credentials.
The new object can provide secret values directly as properties,
or indirectly via a file. The latter includes support for file
descriptor passing syntax on UNIX platforms. Ordinarily passing
secret values directly as properties is insecure, since they
are visible in process listings, or in log files showing the
CLI args / QMP commands. It is possible to use AES-256-CBC to
encrypt the secret values though, in which case all that is
visible is the ciphertext. For ad hoc developer testing though,
it is fine to provide the secrets directly without encryption
so this is not explicitly forbidden.
The anticipated scenario is that libvirtd will create a random
master key per QEMU instance (eg /var/run/libvirt/qemu/$VMNAME.key)
and will use that key to encrypt all passwords it provides to
QEMU via '-object secret,....'. This avoids the need for libvirt
(or other mgmt apps) to worry about file descriptor passing.
It also makes life easier for people who are scripting the
management of QEMU, for whom FD passing is significantly more
complex.
Providing data inline (insecure, only for ad hoc dev testing)
$QEMU -object secret,id=sec0,data=letmein
Providing data indirectly in raw format
printf "letmein" > mypasswd.txt
$QEMU -object secret,id=sec0,file=mypasswd.txt
Providing data indirectly in base64 format
$QEMU -object secret,id=sec0,file=mykey.b64,format=base64
Providing data with encryption
$QEMU -object secret,id=master0,file=mykey.b64,format=base64 \
-object secret,id=sec0,data=[base64 ciphertext],\
keyid=master0,iv=[base64 IV],format=base64
Note that 'format' here refers to the format of the ciphertext
data. The decrypted data must always be in raw byte format.
More examples are shown in the updated docs.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
36 lines
855 B
Python
36 lines
855 B
Python
# -*- Mode: Python -*-
|
|
#
|
|
# QAPI crypto definitions
|
|
|
|
##
|
|
# QCryptoTLSCredsEndpoint:
|
|
#
|
|
# The type of network endpoint that will be using the credentials.
|
|
# Most types of credential require different setup / structures
|
|
# depending on whether they will be used in a server versus a
|
|
# client.
|
|
#
|
|
# @client: the network endpoint is acting as the client
|
|
#
|
|
# @server: the network endpoint is acting as the server
|
|
#
|
|
# Since: 2.5
|
|
##
|
|
{ 'enum': 'QCryptoTLSCredsEndpoint',
|
|
'prefix': 'QCRYPTO_TLS_CREDS_ENDPOINT',
|
|
'data': ['client', 'server']}
|
|
|
|
|
|
##
|
|
# QCryptoSecretFormat:
|
|
#
|
|
# The data format that the secret is provided in
|
|
#
|
|
# @raw: raw bytes. When encoded in JSON only valid UTF-8 sequences can be used
|
|
# @base64: arbitrary base64 encoded binary data
|
|
# Since: 2.6
|
|
##
|
|
{ 'enum': 'QCryptoSecretFormat',
|
|
'prefix': 'QCRYPTO_SECRET_FORMAT',
|
|
'data': ['raw', 'base64']}
|