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). 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? On Thursday, August 7, 2014 9:01:12 AM UTC+10, Daniel Farina wrote: > > On Wed, Aug 6, 2014 at 3:43 PM, Matt Silverlock <[email protected] > <javascript:>> wrote: > > Hi all, > > > > In the process of finishing up an application and as part of the last > few > > things prior to launch, I'm looking to firm up my IAM policies. I have > an > > unversioned S3 bucket that I'm planning to turn versioning on for and > set a > > lifecycle policy to delete old versions after a set period, and > therefore > > want to trim my IAM user permissions down to the set necessary for > pushing > > backups and deleting versions (only). > > > > Right now I have the following permissions for the group on the folder > that > > WAL-E pushes to: > > > > { > > "Sid": "Stmt1390013977000", > > "Effect": "Allow", > > "Action": [ > > "s3:GetBucketAcl", > > "s3:GetBucketLocation", > > "s3:GetBucketPolicy", > > "s3:GetBucketRequestPayment", > > "s3:GetBucketVersioning", > > "s3:GetObject", > > "s3:GetObjectAcl", > > "s3:GetObjectVersion", > > "s3:GetObjectVersionAcl", > > "s3:DeleteObject", > > "s3:DeleteObjectVersion", > > "s3:AbortMultipartUpload", > > "s3:ListBucket", > > "s3:PutObject", > > "s3:PutObjectAcl" > > ], > > "Resource": [ > > "arn:aws:s3:::appname/backups/*" > > ] > > } > > I have dealt with IAM quite a bit for Heroku Postgres. > > See > https://github.com/wal-e/wal-e/blob/8a012cadfd27d25fd53b8b595fc1a79c9f149c68/tests/test_aws_sts.py > > (may be useful to use that to iterate on your policy) which calls > > https://github.com/wal-e/wal-e/blob/8a012cadfd27d25fd53b8b595fc1a79c9f149c68/tests/s3_integration_help.py#L73-L103 > > > In Heroku the deletes are processed somewhere else than the computer > doing the archiving, so the delete privileges are conspicuously > absent. It may be pragmatic for you to add them. > > Note the optional GetLocation: if one uses the non-preferred > non-virtualhosted calling format (e.g. capitals in a bucket name or > any other number of things) then this is important to give as a > privilege so WAL-E can figure out what S3 endpoint to talk to. In > such a case WAL-E falls back on US-Classic. > > > What is the list of policies that I need to trim it down to? I would > assume > > removing DeleteObject (and unnecessary stuff like > GetBucketRequestPayment) > > would be as far as it goes. > > In the case where I need to pull an old version, how does WAL-E interact > > with that? i.e. if the current version is deleted manually via wal-e > delete > > --confirm - how would I go about running a backup-fetch on older > versions? > > (is that even possible?) > > WAL-E is not S3 versioning aware in any way, and it seems not very > useful to support that as the archival format is not reliant on > overwrites: each key will nominally be written once. Delete is > designed to be final. > -- 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.
