[PROPOSAL] Allow separation of secrets
Problem statement
Nowadays infrastructure config is handled as code, and stored in git repositories. However, it's undoubtedly bad practice to store secrets in said repository. Also, the same config template might be used for several instances, where only minor things would change: maybe the username and password the host uses to contact the remote backup service.
Currently it is impossible to keep the secrets (or similar host-specific) values in a separate file, so one can deploy the config in an automated manner, and upload the secrets to the host separately.
Goal
Allow the user to create a split configuration: meaning the config file with all the configuration can be deployed separately from the config-snippets storing the actual secrets.
Thinking about the possible implementations for a moment in advance, it might be beneficial to aim for a hierarchical approach, so that several config files can load and freely override the same values, to adhere to the DRY-principle
Proposed approach(es)
Include functionality
Include the same file into the respective config files in /etc/backup.d
. (The config stored in the git repository would contain the include statement, and the file would be deployed separately)
Host specific defaults/override file
The getconf
logic could be amended so that besides the hard-coded defaults, it can do hierarchical lookup:
-
Either: if a value is not found, it will go back to a defaults file (e.g.
/etc/backupninja.local.conf
) and return that value; only if that is also missing would it fall back to the default specified by the caller; -
or the file could be called something like
/etc/backupninja.override.conf
, and would be consulted before the actual config files in/etc/backup.d
whengetconf
is called.
Allow (environment) variable access when specifying values
The files in /etc/backup.d
would allow something like foo = $bar
to be specified, which in turn would fetch the value of the environment variable bar
at run-time and use that.
This case would, however would also depend on environment variables allowed to be specifies somewhere -- and specifying them in /etc/backupninja.conf
would defeat the purpose of this piece of config being truly host-specific: then we would move config data into the secret store. (And in general, for the getconf
-case, the fallback to /etc/backupninja.conf
would not satisfy the goal.
On the other hand this would allow access to standard UNIX environment variables, like: backup_target = b2:some-bucket-name:/backup/$hostname
... further options
Please feel free to chip in with your own ideas; the reason I am raising is to tap into the hive-mind -- I am more than happy to contribute the code, but wanted to see, what the community and the seasoned backupninja contributors think about the topic.