S3 backup permissions

Support

AI-generated summary

S3 Backup Permissions Summary

The discussion revolves around controlling access to S3 backup keys in Discourse. gchiu initially inquired about limiting key access to a single admin. jomaxro clarified that all admins have access to everything, suggesting moderators as an alternative for users who need content control without access to settings.

gchiu proposed displaying encrypted S3 keys, similar to Travis-ci and GitHub, to add an extra security layer. gchiu also asked if backup logs contain S3 keys, considering encryption if not.

Falco mentioned that backups contain the database, including site settings. pacharanero suggested creating a user specifically for backup with limited access to only the designated S3 bucket. This approach involves creating an S3 bucket, an AWS user, and a custom policy to restrict access to the bucket. By following these steps, users can perform backups while minimizing the risk of exposing S3 keys.

Key Takeaways:

  • All admins have access to S3 keys by default.
  • Moderators can be used as an alternative for users who need content control without access to settings.
  • Creating a user with limited access to only the designated S3 bucket can enhance security.
  • A custom policy can be used to restrict access to the S3 bucket.
1

I note that S3 backup can be enabled.

I’m not entirely sure about the S3 permissions but is there a way to only allow one admin (me) to view and set the two keys required for this? Or do all admins have the rights to access the S3 keys?

2

All admins have access to everything. If you cannot trust your admin(s) with S3 keys, don’t make them admins. Moderators do not have access to site settings, and therefore are a good alternative if you need users to have control over content on the forums, but not settings.

3

Well I was hoping that there would be a way to display encrypted S3 keys such as used with Travis-ci and ones GitHub .travis.yml repository file. The decryption key could be stored in the file system. It just creates an extra layer of security.

4

Do the backup logs contain the S3 keys? If not , then I might look at encrypting them.

5

Backups contain the database, and the site settings are all on the database.

6

If you are concerned about the level of S3 access you are giving away by putting S3 keys in plaintext in Discourse backups, you could create a user which is specifically for backup of that discourse instance and has access to nothing else on AWS. (I got most of this policy from various blogs but I can’t remember where exactly so unfortunately I can’t give credit)

  • create an S3 bucket in the S3 panel and give it any name - you’ll need this name later
  • create an AWS user in the IAM panel
  • choose any user name you like, ideally something that will remind you what that user can access and why
  • choose Access type - programmatic access
  • Don’t add the user to any groups
  • When setting permissions, select ‘Attach existing policies directly’ and then click the button ‘Create policy’
  • in the JSON editor, paste this policy, replacing NAME_OF_YOUR_S3_BUCKET with the actual name of your S3 backup bucket.
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:ListAllMyBuckets",
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::NAME_OF_YOUR_S3_BUCKET",
                "arn:aws:s3:::NAME_OF_YOUR_S3_BUCKET/*"
            ]
        }
    ]
}
  • review and save the policy, you also are asked to name the policy, which means you can use it for other single-access s3 setups if you need to.
  • get the AWS credentials/keys for that user and put them in Discourse, along with the name of the S3 bucket
  • you should now be able to perform a backup to your specified bucket, but that user can’t do anything else on AWS.