Introducing secrets with 10 different providers

News
1

Being a trust-no-one backup solution, a key problem is to guard the different secrets, in particular the backup passphrase. Until now, Duplicati has supported injecting secrets either via the command line interface or by running a script that obtains the passphrase and injects it.

With the latest canary build, Duplicati now supports “secret providers” that offer different ways to inject sensitive parameters into the process. And the initial version supports no less than 10 different providers!

How does it work?

To ensure full backwards compatibility, nothing changes until a secret provider is enabled. The easiest way to enable a secret provider is to supply one as arguments to the initial process, either TrayIcon, Server, or Agent. Configuration is done with a single argument:

--secret-provider=<provider-url>

This will enable the secret provider which means that any values starting with a $ symbol will be treated as a placeholder for a secret. Any option value that starts with a $ symbol will then be retrieved from the secret provider and replace the placeholder value. To ensure that placeholders are not used as passphrases, any secret that is not found will cause an error.

Local providers

For single-machine use there are a few providers that support various ways to retrieve the secrets:

  • file:// - Reads secrets from a file (optionally encrypted)
  • env:// - Reads secrets from environment variables
  • wincred:// - Reads secrets from Windows Credential Manager (Windows only)
  • libsecret:// - Reads secrets from libsecret (Linux only)
  • pass:// - Reads secrets from the pass tool (Linux only)
  • keychain:// - Reads secrets from the MacOS KeyChain (MacOS only)

Cloud providers

If you have a larger set of machines to manage, it can be easier to manage secrets in a central vault. With the Duplicati secret providers, it is possible to update the vaults and have the updated credentials applied across a set of machines. The secrets are only kept in memory until they are no longer needed.

The following cloud providers are supported:

  • awssm:// - Reads secrets from AWS Secrets Manager
  • hcv:// - Reads secrets from HashiCorp Vault (cloud + self-hosted)
  • gcsm:// - Reads secrets from Google Cloud Secret Manager
  • azkv:// - Reads secrets from Azure KeyVault

For cloud providers, an encrypted on-disk cache can be enabled, which makes backups run with cached credentials, in the event that the provider is down. Enable the cache with either:

--secret-provider-cache=inmemory
--secret-provider-cache=persistent

Using shared providers

If you start either the TrayIcon, Server, or Agent with a secret provider, it will apply to that instance, so you can get the encryption key for the settings database from a secret provider. For example:

--secret-provider=gcsm://?project-id=<projectid>
--secret-provider-cache=inmemory
--require-db-encryption-key
--settings-encryption-key=$server-01-settings-key

This will look up the secret server-01-settings-key in the secret provider and replace the encryption key with the returned value. Since the secret provider is enabled for the Server, it will automatically be available for each of the backups configured. This allows a single configuration of the secret provider to be shared across multiple backups.

Should you want to use a different secret provider for one of the backups, you can also set the secret provider in the backup advanced options, and this provider will then override the shared one for that backup.

Try it out!

The secret providers are available in the latest canary build and you can try it out today:
Release: 2.0.9.109 (Canary) 2024-11-06

If you have questions, leave a comment below.

2 Likes