• Resolved andywerdna

    (@andywerdna)


    I’ve been experimenting with the Offload Media Lite plugin and managed to configure it with an S3 role per the quick start guides. My main question is what is the minimal set of S3 permissions required by the plugin?

    What works:
    An s3 role with full S3 permissions. Documentation online does outline that you can restrict the role down to a single bucket and its objects. If that’s the case, then why does the role need create/delete bucket permissions? (The bucket exists already.)

    What doesn’t:
    A role that has permissions on all S3 resources to: ListBucket, GetBucketLocation, PutObject, GetObject, DeleteObject, ListAllMyBuckets, HeadBucket. I’m not sure why this policy would show as “Unable to access bucket” since the site is already configured to use a bucket that already exists. Is there a hard requirement in the plugin for create and delete bucket, or have I missed some other permission(s) in the policy below? I am able to use the CLI and this policy to upload objects to the bucket with zero issues, so I can’t really infer what’s missing or why another permission would be needed.

    JSON below:

    {
    “Version”: “2012-10-17”,
    “Statement”: [
    {
    “Sid”: “VisualEditor0”,
    “Effect”: “Allow”,
    “Action”: [
    “s3:ListBucket”,
    “s3:GetBucketLocation”
    ],
    “Resource”: “arn:aws:s3:::*”
    },
    {
    “Sid”: “VisualEditor1”,
    “Effect”: “Allow”,
    “Action”: [
    “s3:PutObject”,
    “s3:GetObject”,
    “s3:DeleteObject”
    ],
    “Resource”: “arn:aws:s3:::*/*”
    },
    {
    “Sid”: “VisualEditor2”,
    “Effect”: “Allow”,
    “Action”: [
    “s3:ListAllMyBuckets”,
    “s3:HeadBucket”
    ],
    “Resource”: “*”
    }
    ]
    }

Viewing 3 replies - 1 through 3 (of 3 total)
  • Thread Starter andywerdna

    (@andywerdna)

    I spent an hour whittling down to the minimal permissions for the plugin to work, and found the following 5-6. This was just light testing – checking plugin settings page for “access denied” errors as well as testing certain media CRUD operations. So it is possible that others may come into play through interactions I didn’t test.

    {
    “Version”: “2012-10-17”,
    “Statement”: [
    {
    “Sid”: “VisualEditor0”,
    “Effect”: “Allow”,
    “Action”: [
    “s3:PutObject”,
    “s3:GetObject”,
    “s3:ListAllMyBuckets”,
    “s3:CreateBucket”,
    “s3:DeleteObject”,
    “s3:PutObjectAcl”
    ],
    “Resource”: “*”
    }
    ]
    }

    Of those, all are required for normal object operations. CreateBucket only matters while in the UX flow to create a bucket, so it is not relevant if you are simply going to select an existing bucket. Similarly, I imagine ListAllMyBuckets is only relevant to the bucket selection UX, but I’m not concerned about removing it since it is just a read operation.

    The one permission I’m still curious about is why PutObjectACL is required while GETting it is not. Is it genuinely required by the upload flow and if so why?

    Plugin Contributor ianmjones

    (@ianmjones)

    The current version of WP Offload Media (Lite) requires PutObjectACL so that it can specifically set the ACL to either public or private. It does not need to read it.

    We have the following doc…

    https://deliciousbrains.com/wp-offload-media/doc/custom-iam-policy-for-amazon-s3/

    At present it’s still relatively open in its sample permissions, I have it on my todo list to go through and test just how restrictive we can get the sample permissions.

    Be warned, future updates to WP Offload Media (Lite) may require slightly different permissions than your current sample set. We’ll make sure the doc reflects that as needed.

    Thread Starter andywerdna

    (@andywerdna)

    Thanks very much for your reply and explanation. I’ll be sure to keep a lookout for doc changes in the future.

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘What are S3 Minimum Permissions?’ is closed to new replies.