miruky

Posted on Sep 18 Edited on Sep 19

Prove That S3 Bucket Owner Enforced Disables Object ACLs

#aws #s3 #security #tutorial

Introduction

Hi, I'm miruky.

In the current Amazon S3 Console, a new general purpose bucket defaults to Bucket owner enforced Object Ownership. That setting disables bucket and object ACLs; the bucket owner owns every object, and policies replace ACL grants in access evaluation.

This Console run keeps the default, uploads one private text object, and checks the permissions surfaces on both the bucket and object. I am checking the configured ownership model, not trying to make the object public.

The exercise stores one tiny object briefly and makes a few S3 requests. Review the current Amazon S3 pricing dimensions before running it; this article does not assume that every account or request is free.

For a production bucket, plan observability separately: CloudTrail data events can record object-level API activity, server access logging can retain request records, and CloudWatch request metrics can support operational alarms. I leave all three off in this focused ownership test; data events and request metrics are billable, and delivered access-log objects incur normal storage charges.

1. Create a bucket with the modern default

I fixed the Region before creating either resource. The bucket and object remain in us-east-1.

The header confirms United States (N. Virginia) while the S3 Console is in English. This fixes the Region before the bucket and object are created.

Open Amazon S3 and search for miruky-krtlwgxxehhkwwqo. Confirm that the signed-in account has no exact bucket name before creation.

The exact filter for miruky-krtlwgxxehhkwwqo returns no bucket owned by the signed-in account. This exercise explicitly uses the global namespace, so a name already owned elsewhere in the AWS partition would still be rejected during creation and must be replaced with a newly generated value.

Choose Create bucket. Under Bucket namespace, choose Global namespace. Enter miruky-krtlwgxxehhkwwqo, then select US East (N. Virginia) us-east-1. Under Object Ownership, keep ACLs disabled (recommended) and Bucket owner enforced.

The Object Ownership section shows ACLs disabled (recommended) and Bucket owner enforced. The current Console procedure identifies this as the default Object Ownership choice. The bucket uses the global namespace in us-east-1, as specified above.

Keep all four Block Public Access settings enabled and retain default server-side encryption with Amazon S3 managed keys. Block Public Access limits public policies and permissions, while Object Ownership determines whether ACLs participate in authorization. The two controls are not substitutes for each other.

2. Inspect the bucket permissions state

Open the created bucket and locate its Object Ownership card on the permissions view.

The bucket Permissions tab reports Bucket owner enforced and states that ACLs are disabled. Canonical owner IDs are omitted from the screenshots.

With ACLs disabled, the bucket owner owns objects and policy evaluation controls access. IAM identity policies, bucket policies, VPC endpoint policies, and AWS Organizations controls can still allow or deny requests; Object Ownership by itself does not prove whether a caller is authorized.

3. Upload an object without an ACL grant

Create a small local file named owner-control-proof.txt containing owner-control-proof followed by one line-feed byte, then choose Upload and add only that file.

The selected-file row contains only owner-control-proof.txt at 20.0 B. This procedure does not select an ACL grant for the upload.

Inspect the upload permissions area before submitting. With Bucket owner enforced, the Console should not offer ordinary object ACL grants such as public-read; upload without an ACL remains supported.

The upload permissions area shows bucket owner enforced and says Use bucket policies to control access. It contains no ACL-grant checkbox or radio control. The object can still be uploaded without specifying an ACL.

Choose Upload and wait for success. The object is accepted without an ACL because Bucket owner enforced accepts uploads that omit an ACL.

The upload status is Succeeded for the fixed object.

4. Verify the object ACL surface is disabled

Open the uploaded object and go to its permissions view. Locate the access-control-list section to check whether ACL grants are available.

The object Permissions page says, This bucket has the bucket owner enforced setting applied for Object Ownership. This confirms that the uploaded object uses the bucket's ACL-disabled ownership model.

The current page can still render an access-control-list table, but that does not mean ACL grants are active.

The public and authenticated-users rows show - in both permission columns. The owner row is omitted from the screenshot.

Return to the bucket permissions view after the upload.

The bucket Permissions tab still shows Bucket owner enforced after the upload. The object write did not change the ownership control.

AWS still supports ACL read requests in this mode, but the result reports full control for the bucket owner. Requests that try to set or update another ACL fail with AccessControlListNotSupported. This article does not issue that failure request because the disabled Console surface already answers the configured-state question without weakening a control.

Wrap-up

The bucket began with Bucket owner enforced, accepted an upload without an ACL, and kept both its bucket and object ACL surfaces disabled. The object did not acquire a separate editable grant list after upload.

AWS recommends keeping ACLs disabled except when a workload must control access for individual objects. Re-enabling them changes the authorization model, so existing bucket policies and cross-account upload behavior need review before that change.

Thanks for reading this far.

See you in the next one.

Disclosure: This article was written with AI assistance and independently verified against the linked primary sources and observed results.

DEV Community