On Thu, Nov 13, 2025 at 03:57:32PM +0100, Peter Krempa wrote: > 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.
Yes, I've just replied to that effect on the previous patch. > > 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. We should be using a different file extension for the plain text vs cipher text secrets to make this unambiguous at a glance. > The config setting flag will then influence the format only when storign > the secret. Yep. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
