On Thu, Nov 27, 2025 at 15:00:08 +0000, Daniel P. Berrangé wrote: > 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]> >
[...] > > > +[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. Well, if you ask me I prefer libvirtd for my dev setup (and thus run it on almost all my machines) as it's easier to setup debuggers. Obviously it's just a mild inconvenience though :D
