Hi, what you do in bigger deployments with a few hundred fd. You want change a few hundred different password or do you have the same password on all fd?
When your proposed password rotation does not work on a client what would be your solution?Backup fail? Also to make a dependancy of your Backup system to any 3rd part software is really a bad idea. In case of a disaster restore and your vault is gone what you will do? Regards Reiner > On Mittwoch, Juni 25, 2025 at 9:06 PM, Clinton Bunch > <lists+bac...@clintonbunch.name (mailto:lists+bac...@clintonbunch.name)> > wrote: > > 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 > > > _______________________________________________ > Bacula-devel mailing list > Bacula-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-devel
signature.asc
Description: PGP signature
_______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
