Good Evening,
This is a very interesting topic. I was thinking about implementing bacula but
at this point I am still weighing my options.
I have bitwarden and its secret manager. This is a key value pair that will
store the secret so all that one would need to do is call the respective secret
from the secret manager.
I think having the ability to connect to a secret manager would be beneficial
and allow for more secure means to use credentials without needing to keep them
in files.
Regards,
Jonathan
From: Clinton Bunch <lists+bac...@clintonbunch.name>
Sent: 25 June 2025 20:49
To: bacula-devel@lists.sourceforge.net
Subject: [Bacula-devel] Proposal: Enhancing Bacula Secret Management - file:,
dynfile:, syscred:, and credstore:
Hello Bacula Developers and Community,
I'd like to initiate a discussion around enhancing how Bacula manages sensitive
information like passwords and potentially TLS key passphrases, moving them out
of the main configuration files. This aims to improve security, simplify secret
rotation, and make Bacula configurations more friendly for version control and
modern deployment practices (e.g., with Ansible, Puppet, systemd). Importantly,
these proposed enhancements would be entirely optional, ensuring no breakage
for existing configurations.
Currently, passwords are often embedded directly in bacula-*.conf files. This
has several drawbacks:
* Exposes secrets if the main config files are inadvertently shared or
checked into version control without protection.
* Makes secret rotation more error-prone as it requires editing the main
config.
* Complicates management with configuration automation tools that might
handle secrets separately.
I propose a few layered approaches to address this, ranging from simpler to
more comprehensive:
1. The file: Directive
Many users might want to separate files for secrets and pointing to them with
restrictive permissions, which is good practice. A Password =
"file:/path/to/secret"<file://path/to/secret> directive that simply reads the
first line of a file (stripping any trailing newline) would be a foundational
improvement.
* Advantages:
* Allows separation of secrets from main configuration.
* Easier secret rotation (update file, reload Bacula).
* Configuration files become safer for version control (secret files are
gitignored/managed separately).
* Aligns well with configuration management tools (e.g., Ansible can
deploy the main config and then deploy the secret file with strict permissions
and content from a vault).
2. The dynfile: Directive (Dynamic/Deferred File Loading)
Building on file:, the dynfile: prefix would address scenarios where the secret
file is provisioned at service startup and might not exist when a configuration
check (bacula-* -t) is run. This is particularly relevant for integration with
systemd-credentials.
* Syntax: Password = "dynfile:/path/to/runtime_secret_file"
* Key Behavior:
* During a configuration test (bacula-* -t), if a dynfile: path does not
exist, Bacula should issue a warning or informational message but not fail the
configuration check. The validity of the rest of the configuration can still be
assessed.
* At actual runtime, if the dynfile: path doesn't exist when the secret
is needed, it would be a fatal error.
* Advantages:
* All benefits of file:.
* Crucially enables seamless integration with tools like
systemd-credentials (e.g., LoadCredential=), which make secrets available only
after the service unit starts processing but before the main daemon fully
initializes.
* Useful for any custom startup script that generates/places a temporary
secret file.
3. The syscred: Directive (Direct systemd-credentials Integration)
For a more streamlined systemd integration, a dedicated prefix could simplify
configuration since the path used by systemd for $CREDENTIALS_DIRECTORY is not
guaranteed to remain the same between systems or systemd versions. While there
might be a natural reluctance to add code specific to one OS's init
system/credential manager, the prevalence of systemd on Linux platforms and the
relative ease of implementing this specific integration could offer a
significant "bang for the buck" for a large portion of the user base.
* Syntax: Password = "syscred:credential_name" (e.g.,
syscred:bacula_db_password)
* Behavior:
* Bacula reads the $CREDENTIALS_DIRECTORY environment variable (set by
systemd).
* It constructs the full path: $CREDENTIALS_DIRECTORY/credential_name.
* It attempts to read the secret from this path.
* It inherits the "don't fail early" logic from dynfile: for
configuration checks (if $CREDENTIALS_DIRECTORY isn't set or the path doesn't
yet exist during -t).
* Advantages:
* Simplifies configuration for users on systemd: they only need the
credential name, not the full runtime path.
* More robust as it adapts to the actual path provided by systemd via
$CREDENTIALS_DIRECTORY.
* Represents a relatively "simple win" for a large and growing portion
of the Linux user base, offering a clean, secure, and modern way to handle
secrets.
* Implementation could leverage the underlying logic developed for
dynfile:, making it a comparatively straightforward addition.
Applicability to TLS Keys/Passphrases:
These file:, dynfile:, and syscred: mechanisms could also be extended to
directives like a new TLS Key Passphrase if Bacula were to support encrypted
TLS private keys (leveraging the linked OpenSSL library which can handle
decryption given a passphrase). This would be a significant security hardening
step for TLS keys. TLS Key = "dynfile:/path/to/key_provided_by_systemd" is also
an option if systemd provides the decrypted key directly.
4. The credstore:name:secret_identifier Directive (External Credential Store
Helper)
For maximum flexibility and integration with various secret managers (Vault,
AWS Secrets Manager, Azure Key Vault, etc.) and platforms:
* Syntax:
* In resource: Password =
"credstore:myvault:database/production/db_password"
* New Stanza:
· Credstore {
· Name = "myvault"
· Exec = "/usr/local/bin/bacula-secret-helper --store vault --secret
%s"
· # Or: Exec = "/usr/local/bin/fetch-from-aws --secret %s"
· Timeout = 5 # Optional timeout for the helper
· }
*
* Behavior:
* Bacula forks and executes the specified Exec command, substituting %s
(or other placeholders) with the secret_identifier.
* The helper script/program is responsible for fetching the secret from
the external store and printing it to its standard output.
* Bacula reads the secret from the helper's stdout.
* Advantages:
* Extremely flexible: supports any secret manager via custom helper
scripts.
* Platform-agnostic core mechanism (exec).
* Aligns with how many other enterprise tools manage externalized
secrets.
* Considerations:
* Significantly more involved to implement in Bacula (process
management, IPC, timeout handling, error checking from helper, argument
substitution).
* Potential performance implications if secrets are fetched very
frequently (though caching within Bacula could mitigate this).
* Careful design needed for config check mode (e.g., should helpers be
executed?).
Discussion Points:
* Is there general interest in these types of enhancements, understanding
they would be optional additions?
*
* Would the proposed file: directive be a welcome foundational feature?
* Following that, would dynfile: (with its specific config-check behavior)
be a good next step?
* Given its potential ease of implementation and wide user base on systemd,
is syscred: a desirable simplification, despite being OS-specific?
* Is the more comprehensive credstore:exec: model something the community
sees a long-term need for, despite the implementation effort?
* Are there other approaches or considerations I might have missed?
I believe even the simpler dynfile: and syscred: options would offer
substantial benefits to many Bacula users by improving security and
manageability without impacting existing setups. The credstore: approach
provides a path for even more advanced integrations.
Looking forward to your thoughts and feedback.
Thanks,
Clinton Bunch
Links contained in this email have been replaced. If you click on a link in the
email above, the link will be analyzed for known threats. If a known threat is
found, you will not be able to proceed to the destination. If suspicious
content is detected, you will see a warning.
_______________________________________________
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel
