Protecting Backups on GCP

Getting Help
1

Hi,

I’m currently using restic to backup some data, on a public-facing server, to a GCP bucket. I was thinking about a scenario in which the server in question is compromised by attackers. I don’t really want an attacker to be able to wipe or corrupt any existing backups. So, I am wondering if there is any way to lock down the GCP permissions such that restic/GCP role associated with the restic key is only able to create new files, and read existing files?

I can see there are a number of different object permissions in GCP that I can assign. Would assigning storage.objects.create, storage.objects.list, and storage.objects.get be sufficient if this server was only performing backups, and pruning/forgetting was handled elsewhere? Does restic ever need to overwrite data in a file?

My understanding is that data packs are only ever created. I don’t know if the same applies to the keys, snapshots, config, and index directories. My assumption from what reading I’ve done is that files/objects under data, snapshots, keys, and config would only ever be created. And I’m guessing that config and keys would be created when the repository is initialized. I’m also assuming that instances running restic backup or restic restore will need delete permissions to locks. I can’t tell with index

I’ve found a number of other posts that seem to suggest that the recommended way of protecting existing backups is to have restic backup to a repository on a local-network host, then have that machine rclone (with some extra flags so that remote data is not overwritten) the repository to the remote backend. I’m curious if this can be done without rclone.

Thanks!

2

I don’t know too much about GCP…

…but it suffices to have delete permissions on the locks dir to get restic backup many other commands which only read the repo working.

If you want to delete keys or run forget or prune or add tags to snapshots, you need additional delete permissions. But of course, you can perform these operations from another server which you give enhanced permissions to GCP.

EDIT: restic never overwrites any file. If it needs to rewrite anything (the commands I listed above), it will delete the file and create a new one. The reason is that for all files (except config which is not changed at all) the filename equals to the SHA256 hash of the file contents. So if the contents change this gives a new filename.

3

You can use the GCS Bucket Lock feature. It is very permanent and cannot be unset even by Google employees. That means if you set a 5 year retention policy, that GCS Bucket, and the GCP account hosting the bucket is permanently locked for 5 years. That is 5 years of GCP bills with zero way to stop it. Best practice is to set very short lock periods like 30 days, lock periods can be extended but never shortened or canceled.

https://cloud.google.com/storage/docs/bucket-lock