On Wed, Aug 6, 2014 at 4:29 PM, Matt Silverlock <[email protected]> wrote: > Thanks for the reply Daniel. > > Good point RE: the GetLocation permission - ran into a similar issue with an > IAM user for duplicity before. Will fix that. > > It looks like the best solution is then for the IAM user that WAL-E uses on > the server to have only Get/List/Put permissions and to remove all "delete" > permissions from this user. Deletion of older backups should then be managed > by a separate IAM user (on a different machine - i.e. my Mac) that has > delete permissions, and/or by using some generous/safe lifecycle rules to > delete things automatically (i.e. > 90 days old).
That seems reasonable. It's what I do, at least. It gives you a lot more agility in tweaking retention rules and analyzing the output for many databases. > To understand correctly: if the server doing the backups is compromised, it > can't delete any older backups. My only concern is that it [the compromised > server running WAL-E] could still overwrite both WAL backups and full > backups (by issuing a PUT with a key matching an existing object?). Can a > PUT where a key already exists overwrite the existing data? Yeah, unfortunately a hopefully-idempotent PUT is rather useful to deal with the problem of lost responses for successfully processed PUTs from S3 in event of a network blip. And, I don't think S3 has a no-overwrite permission level. There are ways around such a catastrophic scenario like the S3 versioning feature, but then WAL-E would have to learn how to address versions for replay and have deletion semantics (or you'd have to write some side-bar software to massage the version of things and produce a prefix for WAL-E to use). -- You received this message because you are subscribed to the Google Groups "wal-e" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
