On Thu, Nov 13, 2025 at 14:48:12 +0000, Daniel P. Berrangé wrote: > On Thu, Nov 13, 2025 at 02:57:13PM +0100, Peter Krempa via Devel wrote: > > On Thu, Nov 13, 2025 at 19:02:22 +0530, Arun Menon via Devel wrote: > > > A new configuration file called secrets.conf is introduced to > > > let the user configure the path to the master encryption key. > > > This key will be used to encrypt/decrypt the secrets in libvirt. > > > > > > By default the path is set to the runtime directory > > > /run/libvirt/secrets, and it is commented in the config file. > > > The virtsecretd driver checks if the credentials are available > > > in the CREDENTIALS_DIRECTORY. In case it is not present, then the > > > user is expected to provide the encryption key path in secrets.conf > > > > > diff --git a/src/secret/secrets.conf.in b/src/secret/secrets.conf.in > > > new file mode 100644 > > > index 0000000000..80bb9654ce > > > --- /dev/null > > > +++ b/src/secret/secrets.conf.in > > > @@ -0,0 +1,14 @@ > > > +# > > > +# Master configuration file for the secrets driver. > > > +# > > > + > > > +# The master encryption key is used to override default master encryption > > > +# key path. The user can create an encryption key and set the > > > master_encryption_key > > > +# to the path on which it resides. > > > +# The key must be atleast 32-bytes long. > > > +# > > > +# master_encryption_key = "/run/libvirt/secrets/master.key" > > > +# > > > +# The encrypt_data setting is used to indicate if the encryption is on > > > or off. > > > +# 0 indicates off and 1 indicates on. By default it is set to on. > > > +encrypt_data = 1 > > > > As the default secret seems to be handed in via systemd, which will it > > make available to any upgraded installation, I don't think you can > > unconditionally enable this option as it would break existing > > un-encrypted secrets. > > When I discussed the design with Arun offlist, my suggestion was that > our goal should be to have encryption enabled out of the box on all > systemd based hosts, with zero config by the admin.
I agree with that. We also ought to auto-generate a properly random secret key on each host at installation time, otherwise it's unlikely that an admin will change the key if we provide a default. > This implies that we need the ability to read *both* plain text and > encrypted secrets off disk, as we may have a mixture during the > transitional times of an upgrade. Whether we proactively encrypt > all plain text secrets at startup, or simply always read them on > startup in whatever format they're stored is a choice we have. > > Not immediately encrypting all plain text secrets gives the ability > to downgrade libvirt again without loosing access to previously > created secrets on disk. So I think that's marginally better. Encrypting non-encrypted secrets will still require libvirt knowing whether they are encrypted or not, so it's simpler to just leave them in whatever state they were in. That information will need to be stored somewhere out-of-band (e.g. by the filename or location of the file) in order to properly detect the current state. The config setting flag will then influence the format only when storign the secret.
