Score:0

AWS S3 bucket policy for get and upload

si flag

I have two buckets each with their own goals. So far I cannot understand the complicated configuration of bucket settings. It seems there are three things to configure

  1. Block public access
  2. Bucket policy
  3. ACL

I know that if I turn off (1), that everything that I want to accomplish just works. Even though these are the four most meaningless settings I have ever seen (why would I care about restricting access to a bucket based on when a policy was modified???)

It seems that what I add to (2) doesn't really matter. For example I have one policy that only allows GetObject, yet I can DeleteObject and PutObject from the SDK. I have another policy that allows DeleteObject, GetObject, and PutObject, yet only delete works and put throws an Access Denied (from an IAM account that has Administrative access to everything under the sun).

I don't even know the point of (3). Why would I ever want to allow permissions to any AWS user? Anyway..

I have two buckets with two goals and I cannot figure out the combination of things to do.

A: Public bucket for static website

For this one, I have Bock public access to OFF, and a policy like so (that I think does nothing whatsoever). Anyone can view the bucket contents (good!) but this policy should not allow any PutObject, yet it does.

{
    "Version": "2012-10-17",
    "Id": "Policy1632669906301",
    "Statement": [
        {
            "Sid": "Stmt1632669869776",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::publicwebsite/*"
        }
    ]
}

Why can I upload and delete when only GetObject is defined?

B: Secure bucket for backups

This bucket is for my app to send data backups to. So the only thing that should be able to read/write is my application. But if I turn on Block public access, I cannot upload, yet I can delete. Again, it makes no sense at all. If I turn off Block public access, I can do it all. Here is the policy

{
    "Version": "2012-10-17",
    "Id": "Policy1635858319261",
    "Statement": [
        {
            "Sid": "Stmt1635858317672",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::XXXXXXXXX:user/backup-user"
            },
            "Action": [
                "s3:DeleteObject",
                "s3:GetObject",
                "s3:PutObject"
            ],
            "Resource": "arn:aws:s3:::backups/*"
        }
    ]
}

Why can I delete but not put?


Furthermore, Amazon is ADAMANT about always keeping on Block public access, yet you cannot even modify a Bucket policy if this is enabled! This is insanity!!!!!!!


Here are my findings after some testing.

My accounts are as such

  1. root account, owner of bucket
  2. IAM account (Admin) with Administrative everything
  3. IAM account (User) with absolutely no authority to do anything at all

For bucket policies, see the second one posted above.

I am exploring what the combination of policy and Block public access settings do. They continue to make 0 sense whatsoever.

Case 1

  • Block all public access: OFF
  • Bucket policy: EMPTY
  • ACL: Bucket owner (list, write | read, write)

Result: Admin can upload and delete, User cannot do anything

Case 2

  • Block all public access:
    • [x] new access control lists
  • Bucket policy: EMPTY
  • ACL: Bucket owner (list, write | read, write)

Result: Admin can delete, but not upload, User cannot do anything

Case 3

  • Block all public access:
    • [x] new access control lists
    • [x] any access control lists
  • Bucket policy: EMPTY
  • ACL: Bucket owner (list, write | read, write)

Result: Admin can delete, but not upload, User cannot do anything

Case 4

  • Block all public access:
    • [x] new access control lists
    • [x] any access control lists
    • [x] new access point policies
  • Bucket policy: EMPTY
  • ACL: Bucket owner (list, write | read, write)

Result: Admin can delete, but not upload, User cannot do anything

Case 5

  • Block all public access: ON
  • Bucket policy: EMPTY
  • ACL: Bucket owner (list, write | read, write)

Result: Admin can delete, but not upload, User cannot do anything

Conclusion: Block public access when set to ON allows everything. Any other configuration allows delete (and maybe more, like get) but not put.


Case 6

  • Block all public access: OFF
  • Bucket policy: Admin (Get/Put/Delete object) User (nothing)
  • ACL: Bucket owner (list, write | read, write)

Result: Admin can upload and delete, User cannot do anything

Case 7

  • Block all public access:
    • [x] new access control lists
  • Bucket policy: Admin (Get/Put/Delete object) User (nothing)
  • ACL: Bucket owner (list, write | read, write)

Result: Admin can delete, User cannot do anything

Case 8

  • Block all public access:
    • [x] new access control lists
    • [x] any access control lists
  • Bucket policy: Admin (Get/Put/Delete object) User (nothing)
  • ACL: Bucket owner (list, write | read, write)

Result: Admin can delete, User cannot do anything

Case 9

  • Block all public access:
    • [x] new access control lists
    • [x] any access control lists
    • [x] new access point policies
  • Bucket policy: Admin (Get/Put/Delete object) User (nothing)
  • ACL: Bucket owner (list, write | read, write)

Result: Admin can delete, User cannot do anything

Case 10

  • Block all public access: ON
  • Bucket policy: Admin (Get/Put/Delete object) User (nothing)
  • ACL: Bucket owner (list, write | read, write)

Result: Admin can delete, User cannot do anything

Conclusion: Bucket policy has literally no effect on anything


TLDR: It seems that Bucket policy does nothing. Only Block public access has any measurable effect with the only usable option being to turn it off. I have also removed my bucket policy from my public bucket and it also did not change anything.

My conclusion is that either Bucket policy is broken, that the documentation is not sufficient, or that the settings themselves are counter intuitive and don't actually do what they say. Or any combination of anything.

I'd rather host my content on an FTP server in my basement at this point.

vn flag
What are you using to put the objects? I've seen libraries that require not just PutObject but PutObjectAcl, for example.
pbuzz007 avatar
si flag
The Node.js SDK
vn flag
Can you show the specific calls being utilized, and the specific error message received?
pbuzz007 avatar
si flag
There's nothing really to it. I call the `s3.upload` function provided by the AWS SDK and I get `Access Denied` error. Yet I can delete just fine.
Tim avatar
gp flag
Tim
Unfortunately we don't have enough information to help here. To fully investigate this I would want to see IAM permissions, bucket policy, bucket ACL for each bucket, block public access settings, then the CLI command ran and the results. It would be a lot of work. It can be complex to work through this, but I can assure you it works as documented. Have you done any AWS training? Either specific for S3 security, or even better AWS architect associate / AWS security training. AWS is a very complex enterprise platform, people spend years learning it.
pbuzz007 avatar
si flag
I listed the combinations of the three main bucket permission settings. If it takes years for someone to understand that, it's kind of ludicrous. I just want a private bucket with CRUD for one IAM user and no one else, and one bucket with GET for anyone and CRUD for one IAM user and no one else. I literally tried every combination possible, and the results are nonsense. Block public access is one of the worst defined and worded settings I can imagine.
pbuzz007 avatar
si flag
I also listed each thing you asked for, including the IAM settings (Admin = everything, User = nothing). The commands are run from Node JS SDK and the results are simply "Access Denied" or success, full stop. There's honestly not much to it. It just does not work as described. The policies don't work properly.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.