Different passphrases for different repositories? #281

Closed
opened 2020-01-14 22:31:26 +00:00 by jucor_ · 10 comments

Loving borgmatic, thanks so much for it. Today was another of these moments where I realise it: the ability to back up to multiple repositories by just adding one extra line in "repositories:" section in Borgmatic config file was magic. Mind blown :) Thanks!

The downside: The way the config file is, it seems all repos mentioned in the config must use the same passphrase, which sounds not ideal security-wise. I could not find a way to specify a different passphrase for each repository encrypted in repokey mode.

Is there a way to specify different passphrases for different repositories, in the same config file, please?

Loving borgmatic, thanks so much for it. Today was another of these moments where I realise it: the ability to back up to multiple repositories by just adding one extra line in "repositories:" section in Borgmatic config file was magic. Mind blown :) Thanks! The downside: The way the config file is, it seems all repos mentioned in the config *must* use the same passphrase, which sounds not ideal security-wise. I could not find a way to specify a different passphrase for each repository encrypted in `repokey` mode. Is there a way to specify different passphrases for different repositories, in the same config file, please?
Owner

I'm glad to hear borgmatic config can sometimes be magical. 😄 I totally get what you're saying though about the repositories in a configuration file having all the same configuration.

Right now, if you want to specify different passphrases per repository, you'd have to declare each repository in a separate borgmatic configuration file. Then, you can vary the settings in each one as you like. And if that causes too much duplication, see the discussion about includes on that page.

Also, if you'd like to see some prior discussion on the general topic of varying configuration per repository in a configuration file, check out this ticket: witten/borgmatic#73

Note that I'm happy to look at ideas for better ways to do this. And/or hear about any challenges you face with the include approach. Let me know what you end up doing.

I'm glad to hear borgmatic config can sometimes be magical. :smile: I totally get what you're saying though about the repositories in a configuration file having all the same configuration. Right now, if you want to specify different passphrases per repository, you'd have to declare each repository in a [separate borgmatic configuration file](https://torsion.org/borgmatic/docs/how-to/make-per-application-backups/). Then, you can vary the settings in each one as you like. And if that causes too much duplication, see the discussion about [includes](https://torsion.org/borgmatic/docs/how-to/make-per-application-backups/#configuration-includes) on that page. Also, if you'd like to see some prior discussion on the general topic of varying configuration per repository in a configuration file, check out this ticket: https://projects.torsion.org/witten/borgmatic/issues/73 Note that I'm happy to look at ideas for better ways to do this. And/or hear about any challenges you face with the include approach. Let me know what you end up doing.
witten added the
question / support
label 2020-01-17 22:42:55 +00:00
Author

Oh, it is definitely magical :)
Thank you very much @witten! I had missed #73 and includes, I will check them out and report!

Oh, it is *definitely* magical :) Thank you very much @witten! I had missed #73 and includes, I will check them out and report!
Owner

Sounds good!

Sounds good!
witten added the
waiting for response
label 2020-01-25 17:52:38 +00:00
Author

Alright, if I understand correctly, because here every YAML key would be the same except for that containing the passphrase, we would need to have multiple includes. Completely feasible, but a bit messier than ideal.

That's no big deal, though. The more I think about my setup, the less I am bothered by having twice the same passphrase. If I am in a situation where the attacker has access to the passphrase of one of the repos, I am already in deep trouble and not protected by having another passphrase.

So nevermind this request, and thanks for the very helpful answer and all the awesome work!

Alright, if I understand correctly, because here every YAML key would be the same except for that containing the passphrase, we would need to have multiple includes. Completely feasible, but a bit messier than ideal. That's no big deal, though. The more I think about my setup, the less I am bothered by having twice the same passphrase. If I am in a situation where the attacker has access to the passphrase of one of the repos, I am already in deep trouble and not protected by having another passphrase. So nevermind this request, and thanks for the very helpful answer and all the awesome work!
witten removed the
waiting for response
label 2020-01-25 17:57:15 +00:00
Owner

Okay! If this sort of need comes up again, please do let me know about it. Includes work well for certain situations, but as you've discovered, not for all of them.

Okay! If this sort of need comes up again, please do let me know about it. Includes work well for certain situations, but as you've discovered, not for all of them.
Owner

I've been noodling on this general problem, because it's come up in other contexts (even if you don't need it solved right now). What if the include merging feature did deep merging instead of shallow merging? That would allow you to do something like this:

<<: !common_config.yaml
location:
    repositories:
        - first_repo.borg

storage:
    encryption_passphrase: phrase1

And then you could have as many instances of that as you needed:

<<: !common_config.yaml
location:
    repositories:
        - second_repo.borg

storage:
    encryption_passphrase: phrase2

The idea is that even if common_config.yaml has other location or storage options set, they would still get carried through after the include due to the deep merging.

Thoughts? Would this still be too cumbersome?

I've been noodling on this general problem, because it's come up in other contexts (even if you don't need it solved right now). What if the include merging feature did deep merging instead of shallow merging? That would allow you to do something like this: ```yaml <<: !common_config.yaml location: repositories: - first_repo.borg storage: encryption_passphrase: phrase1 ``` And then you could have as many instances of that as you needed: ```yaml <<: !common_config.yaml location: repositories: - second_repo.borg storage: encryption_passphrase: phrase2 ``` The idea is that even if `common_config.yaml` has other `location` or `storage` options set, they would still get carried through after the include due to the deep merging. Thoughts? Would this still be too cumbersome?
Contributor

I think I have a situation where being able to set per-repo passphrases would be useful/important.

My config takes a snapshot of an LVM logical volume, mounts the snapshot, backs up the snapshot to two separate repositories, then cleans up the snapshot.

I don't want to use the same passphrase for both repos. If an attacker obtains the passphrase, it becomes much easier for them to corrupt both repos (assuming the passphrases are not saved inside the backups).

I also want to save the same snapshot to both repos. If I use separate configs, then each config will take a snapshot when it is its turn, leading to slightly different snapshots/backups.

I have switched to using before_everything instead of before_backup to take the snapshot, but this feels like a workaround instead of a real solution.

Another workaround I considered was using encryption_passcommand to return a different passphrase depending on the repo, but it doesn't appear that borg or borgmatic pass this information to the command (or set it in an environment variable). I understand from borg's perspective it is only operating on one repo and so the user can hardcode it into the command, and from borgmatic's perspective since borg doesn't support this then there is not much else it can do, so this appears to be a non-starter.

I think I have a situation where being able to set per-repo passphrases would be useful/important. My config takes a snapshot of an LVM logical volume, mounts the snapshot, backs up the snapshot to two separate repositories, then cleans up the snapshot. I don't want to use the same passphrase for both repos. If an attacker obtains the passphrase, it becomes much easier for them to corrupt both repos (assuming the passphrases are not saved inside the backups). I also want to save the same snapshot to both repos. If I use separate configs, then each config will take a snapshot when it is its turn, leading to slightly different snapshots/backups. I have switched to using `before_everything` instead of `before_backup` to take the snapshot, but this feels like a workaround instead of a real solution. Another workaround I considered was using `encryption_passcommand` to return a different passphrase depending on the repo, but it doesn't appear that borg or borgmatic pass this information to the command (or set it in an environment variable). I understand from borg's perspective it is only operating on one repo and so the user can hardcode it into the command, and from borgmatic's perspective since borg doesn't support this then there is not much else it can do, so this appears to be a non-starter.
Contributor

Thinking a bit more, before_everything works for the simple case, but if there are other configs to be processed, taking snapshot(s) before everything starts may not be ideal/feasible.

Thinking a bit more, `before_everything` works for the simple case, but if there are other configs to be processed, taking snapshot(s) before everything starts may not be ideal/feasible.
Owner

If I'm understanding this correctly, it sounds like the basic need/ask is to be able to run borgmatic hooks "around" some particular Borg invocations that borgmatic kicks off—but not necessarily all Borg invocations. In this case, you want to run an LVM snapshot hook before particular repositories are backed up, which by its nature requires multiple Borg invocations.

And an additional ask is to be able to set a separate passphrase per repository. Which right now is only supported by separate borgmatic configuration files... Whether or not there's some configuration merging in place to cut down on duplication.

So am I correct in assuming that having multiple different configuration files (one per repository + passphrase) would be sufficient for your needs, assuming there was a way to run the hooks at the right time?

Thanks!

Related issue: Native LVM support in borgmatic

If I'm understanding this correctly, it sounds like the basic need/ask is to be able to run borgmatic hooks "around" some particular Borg invocations that borgmatic kicks off—but not necessarily all Borg invocations. In this case, you want to run an LVM snapshot hook before particular repositories are backed up, which by its nature requires multiple Borg invocations. And an additional ask is to be able to set a separate passphrase per repository. Which right now is only supported by separate borgmatic configuration files... Whether or not there's some configuration merging in place to cut down on duplication. So am I correct in assuming that having multiple different configuration files (one per repository + passphrase) would be sufficient for your needs, assuming there was a way to run the hooks at the right time? Thanks! Related issue: [Native LVM support in borgmatic](https://projects.torsion.org/witten/borgmatic/issues/80)
Contributor

So am I correct in assuming that having multiple different configuration files (one per repository + passphrase) would be sufficient for your needs, assuming there was a way to run the hooks at the right time?

You could say that, though I think there is semantic / mental model difference between "taking one backup and sending it to multiple places" and "taking multiple backups that contain the same files" (where one config "equals" one backup). Even though there may be no functional difference, personally I find the former to be more intuitive.

> So am I correct in assuming that having multiple different configuration files (one per repository + passphrase) would be sufficient for your needs, assuming there was a way to run the hooks at the right time? You could say that, though I think there is semantic / mental model difference between "taking one backup and sending it to multiple places" and "taking multiple backups that contain the same files" (where one config "equals" one backup). Even though there may be no functional difference, personally I find the former to be more intuitive.
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: borgmatic-collective/borgmatic#281
No description provided.