On Thu, Nov 27, 2025 at 04:12:59PM +0100, Peter Krempa wrote:
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 <armenon@redhat.com>
[...]
+[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.
I'm curious what makes it easier ? Are you debugging across many drivers concurrently ? Normally I'm only focusing on just 1 of the daemons, and so I tend to use sudo ./run virtqemud which stops virtqemud.service & runs the in-tree build, while leaving the other virtnetworkd, virtnodedevd, etc runnnig the RPM builds. 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 :|