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.

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.

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 :|

Reply via email to