On Thu, Nov 27, 2025 at 03:42:13PM +0100, Peter Krempa via Devel wrote: > On Thu, Nov 27, 2025 at 12:52:29 +0530, Arun Menon via Devel wrote: > > This commit sets the foundation for encrypting the libvirt secrets by > > providing a > > secure way to pass a secret encryption key to the virtsecretd service. > > > > A random secret key is generated using the new virt-secret-init-encryption > > service. This key can be consumed by the virtsecretd service. > > > > By using the "Before=" directive in the new secret-init-encryption > > service and using "Requires=" directive in the virtsecretd service, > > we make sure that the daemon is run only after we have an encrypted > > secret key file generated and placed in /var/lib/libvirt/secrets. > > The virtsecretd service can then read the key from CREDENTIALS_DIRECTORY. > > [1] > > > > This setup therefore provides a default key out-of-the-box for initial use. > > A subsequent commit will introduce the logic for virtsecretd > > to access and use this key via the $CREDENTIALS_DIRECTORY environment > > variable. [2] > > > > [1] > > https://www.freedesktop.org/software/systemd/man/latest/systemd-creds.html > > [2] https://systemd.io/CREDENTIALS/ > > > > Signed-off-by: Arun Menon <[email protected]>
> > new file mode 100644 > > index 0000000000..29da6dbcce > > --- /dev/null > > +++ b/src/secret/secret-init-encryption.in > > @@ -0,0 +1,10 @@ > > +[Unit] > > +Before=virtsecretd.service > > +ConditionPathExists=!@localstatedir@/lib/libvirt/secrets/secrets-encryption-key > > + > > +[Service] > > +Type=oneshot > > +ExecStart=/usr/bin/sh -c 'umask 0066 && (dd if=/dev/urandom status=none > > bs=32 count=1 | systemd-creds encrypt --name=secrets-encryption-key - > > @localstatedir@/lib/libvirt/secrets/secrets-encryption-key)' > > + > > +[Install] > > +WantedBy=multi-user.target > > What does this actually do? This should be redundant, as once we make it a depdendency on virtsecretd.service, it'll get enabled automatically in any scenario were virtsecretd is active. > > diff --git a/src/secret/virtsecretd.service.extra.in > > b/src/secret/virtsecretd.service.extra.in > > index 1fc8c672f7..116458b22a 100644 > > --- a/src/secret/virtsecretd.service.extra.in > > +++ b/src/secret/virtsecretd.service.extra.in > > @@ -1,2 +1,10 @@ > > # The contents of this unit will be merged into a base template. > > # Additional units might be merged as well. See meson.build for details. > > +# > > +[Unit] > > +Requires=virt-secret-init-encryption.service > > +After=virt-secret-init-encryption.service > > + > > +[Service] > > +LoadCredentialEncrypted=secrets-encryption-key:@localstatedir@/lib/libvirt/secrets/secrets-encryption-key > > +Environment=SECRETS_ENCRYPTION_KEY=%d/secrets-encryption-key > > This will likely be needed also for the monolithic daemon's unit > (libvirtd.service) as that can also start the secret driver in those > setups. Hmm, its been a whle since we introduced the modular daemons, and we've changed Fedora 4 years ago, and changed it in RHEL-9 too. Wonder about status of other distros ? Perhaps not right now, but we should likely consider whether we want to eventually remove libvirtd or keep it around forever. Preferrably the former so we stop having to think about both deployment scenarios for changes like this in future. 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 :|
