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-*.conffiles.
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"directive that simply reads the first line of a
file (stripping any trailing newline) would be a foundational improvement.
*
*Advantages*:
o
Allows separation of secrets from main configuration.
o
Easier secret rotation (update file, reload Bacula).
o
Configuration files become safer for version control (secret
files are gitignored/managed separately).
o
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*:
o
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.
o
At actual runtime, if the dynfile:path doesn't exist when the
secret is needed, it would be a fatal error.
*
*Advantages*:
o
All benefits of file:.
o
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.
o
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_DIRECTORYis 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*:
o
Bacula reads the $CREDENTIALS_DIRECTORYenvironment variable (set
by systemd).
o
It constructs the full path: $CREDENTIALS_DIRECTORY/credential_name.
o
It attempts to read the secret from this path.
o
It inherits the "don't fail early" logic from dynfile:for
configuration checks (if $CREDENTIALS_DIRECTORYisn't set or the
path doesn't yet exist during -t).
*
*Advantages*:
o
Simplifies configuration for users on systemd: they only need
the credential name, not the full runtime path.
o
More robust as it adapts to the actual path provided by systemd
via $CREDENTIALS_DIRECTORY.
o
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.
o
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 Passphraseif 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_identifierDirective (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*:
o
Bacula forks and executes the specified Execcommand,
substituting %s(or other placeholders) with the secret_identifier.
o
The helper script/program is responsible for fetching the secret
from the external store and printing it to its standard output.
o
Bacula reads the secret from the helper's stdout.
*
*Advantages*:
o
Extremely flexible: supports any secret manager via custom
helper scripts.
o
Platform-agnostic core mechanism (exec).
o
Aligns with how many other enterprise tools manage externalized
secrets.
*
*Considerations*:
o
Significantly more involved to implement in Bacula (process
management, IPC, timeout handling, error checking from helper,
argument substitution).
o
Potential performance implications if secrets are fetched very
frequently (though caching within Bacula could mitigate this).
o
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
_______________________________________________
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel
