I’m trying to get my head around how to think about keys and permissions for my backup infrastructure with Tardigrade and Duplicati
I have a small team, each with a workstation. I want to have backups go to our tardigrade project where
- Each client can backup to a destination that Cleary identifies it’s footprint in the tardigrade project (size + objects, etc)
- Each client’s setup is similar enough that I can kind of script it (predictable config)
- A new client machine could restore from an existing old client backup
- A root/admin user/client could restore from any backup.
I’m really digging into how to organize apiKeys and capabilities
For workstations A, B, C would I do something like this:
- Make buckets: backup_a, backup_b, backup_c
- Make apiKeys ak_a, ak_b, ak_c
- Set a permission on each key w/ restrictions to individual buckets
- Make apiKey ak_admin with all permissions
- Use a common encryption phrase on alll clients so future restores don’t have to know which key/phrase combo made the backup
Alternatively, I think I could have 1 api_key and use something like:
$ uplink share [some bucket]/[some folder]
What is the best practice here? This all feels sort of new to me and I don’t want to use the wrong mental model for key management and permissions.
Is there a good white paper to that would help me roll prep to roll out for a small team?