Unable to Delete Bucket Contents As Root User

It's surprising that you're encountering access denied errors while attempting to delete objects from an S3 bucket as the root user. As the root user, you should have the highest level of access and permissions within your AWS account. However, there could be several potential reasons why you're facing this issue.

In the case of S3 buckets, there might be specific bucket policies, object lock configurations, or other settings that could be preventing the deletion of objects or the bucket itself.

To troubleshoot this issue, I recommend reviewing the following resources, which provide insights and potential solutions for similar scenarios

1. *Impossible to Delete Bucket Policies Even with Root Account *(https://repost.aws/questions/QUs1FxxgSaRxaQZTigxLfygQ/impossible-to-delete-bucket-policies-even-with-root-account): This article discusses potential issues with bucket policies and how to resolve them, even when using the root account.

2. Unable to Delete Bucket Contents as Root User (https://repost.aws/questions/QUo_YPqafiT4GyB_bmJfkp-A/unable-to-delete-bucket-contents-as-root-user): This resource specifically addresses the problem you're facing and provides potential solutions and workarounds.

3. Not Able to Delete an S3 Bucket (https://repost.aws/questions/QUcLPm_ss2S6KK5pCPmDSuew/not-able-to-delete-a-s3-bucket): While this article focuses on deleting the bucket itself, it may also provide insights into issues related to deleting bucket contents.

4. Troubleshoot Access Denied (403 Forbidden) errors in Amazon S3 https://docs.aws.amazon.com/AmazonS3/latest/userguide/troubleshoot-403-errors.html

By reviewing these resources, you may gain a better understanding of the potential causes and find solutions tailored to your specific scenario. If the issue persists after exploring these resources, you may want to consider reaching out to AWS Support for further assistance.

Deleting objects in an S3 bucket as the root user should typically grant you the necessary permissions, but there are several potential reasons why you might encounter an "Access Denied" error. Here are some common issues and their solutions:

Common Issues and Solutions Bucket Policy Denial:

Check if the bucket policy explicitly denies the s3:DeleteObject action for the root user or any user. Object Ownership and ACLs:

Ensure the objects you are trying to delete are owned by your AWS account. Sometimes, if objects are uploaded by another account and have different ACLs, you might face access issues. Bucket Policy Conflicts:

Ensure there are no conflicting statements in the bucket policy that might override root user permissions. CloudFront Policy:

Verify if the CloudFront policy attached to the bucket restricts any actions. Steps to Troubleshoot and Resolve Step 1: Check Bucket Policy View Bucket Policy:

Go to the S3 Console. Select the bucket in question. Go to the Permissions tab and view the Bucket Policy. Verify Policy Statements:

Ensure there are no explicit Deny statements for s3:DeleteObject. Ensure there are Allow statements for the root user or your IAM user for s3:DeleteObject. Example Bucket Policy Allowing Delete: Json:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::your-account-id:root"
            },
            "Action": "s3:DeleteObject",
            "Resource": "arn:aws:s3:::your-bucket-name/*"
        }
    ]
}

Step 2: Check Object ACLs View Object Permissions:

Navigate to the objects you are trying to delete in the S3 console. Check the Permissions tab for each object. Update ACLs if Necessary:

Ensure the ACL grants the necessary permissions to your root user or the IAM user attempting the deletion. Step 3: Review IAM User Permissions Check IAM Policies: Go to the IAM Console. Select the user or role you are using. Ensure the policy attached to the user or role grants s3:DeleteObject permission. Example IAM Policy: Json:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:DeleteObject",
            "Resource": "arn:aws:s3:::your-bucket-name/*"
        }
    ]
}

Step 4: Check and Modify CloudFront Policy View CloudFront Policy:

Go to the CloudFront Console. Select your CloudFront distribution. Check the Origin Access Identity and related policies. Ensure Compatibility:

Ensure the policy attached to CloudFront does not conflict with the permissions needed to delete objects. Step 5: Use AWS CLI for Debugging Use AWS CLI to Delete Objects: Sometimes, the console might not show all details. Using AWS CLI can help diagnose issues better. Sh:

aws s3 rm s3://your-bucket-name/your-object-key --profile your-profile

Check Detailed Error Messages: If the above command fails, it provides more detailed error messages that can help pinpoint the issue. Example of Comprehensive Bucket Policy Ensure your bucket policy is comprehensive and does not contain any conflicting deny statements. Jason:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowRootDelete",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::your-account-id:root"
            },
            "Action": "s3:DeleteObject",
            "Resource": "arn:aws:s3:::your-bucket-name/*"
        },
        {
            "Sid": "AllowIAMUserDelete",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::your-account-id:user/your-iam-user"
            },
            "Action": "s3:DeleteObject",
            "Resource": "arn:aws:s3:::your-bucket-name/*"
        }
    ]
}

By following these steps, you should be able to diagnose and resolve the issue preventing you from deleting objects in the S3 bucket.

The typical things that could block root from deleting an object or object version in an S3 bucket they own are 1) an explicit "deny" statement in the bucket policy, 2) S3 Object Lock applied to the object, 3) MFA delete configured for the bucket, 4) a Service Control Policy (SCP) configured in AWS Organizations, 5) a VPC endpoint policy, if the request is being made via an endpoint.

You mentioned there's a statement in the bucket policy for s3:DeleteObject. You're sure it isn't a "deny" statement? It sounds unlikely that you'd be using Object Lock or MFA delete without knowing it (and logging on as root without MFA), so perhaps your AWS Org might be blocking root users from taking destructive actions?

Hi Leo,

Yes, it is a Deny statement, one that you help crafted for me. I ended up removing it and that solved my problem, the delete operation had proceed without an additional delete request.

This was the delete statement that you had suggested:

{
            "Sid": "DenyAllButMyUserRWDaccess",
            "Effect": "Deny",
            "Principal": "*",
            "Action": [
                "s3:PutObject",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::amazon-cloudfront-secure-static-site--s3bucketroot-xxxxxxxxxxxx/htdocs/my_repo/*"
            ],
            "Condition": {
                "StringNotEquals": {
                    "aws:username": "myuser"
                }
            }
        }

Its a bit odd that it would block the root user from modifying those objects. I did create a policy object and added "myuser" to it as you had suggested but I am holding my breath that some other strange behavior does not happen henceforth.

Well maybe I spoke too soon. Hit another deletion block.

Yes changing it to Allow is what I had intended to do. I am still trying to understand how the root user is differentiated from the IAM user in various contexts but the simple answer seems to be, it is not.

Changing it to Allow solved my problem. One oddity I am observing is that if I have an empty directory on my source system, it does not get copies to my bucket. Is this "normal" behavior?

Root is subject to most of the same rules as IAM users and IAM roles, except for the primary rule that it has no identity-based policies attached to it, instead being hardwired with the equivalent of an Allow statement for "Action": "*" without restrictions. That gives it implicit access to everything inside the same account, with the exceptions of assuming an IAM role and accessing customer-managed KMS keys, which have their own particular rules.

Resource-based policies (like S3 bucket policies), as well as VPC endpoint policies, Service Control Policies (SCPs) from AWS Organizations, S3 Object Lock, and various other features designed to restrict access apply to the root user mainly the same as for everyone else, with a few exceptions. For example, root can always see, modify, or delete an S3 bucket policy, even if there's an explicit Deny in the bucket policy, unless an SCP blocks those actions. That's meant as a hardwired failsafe for people locking themselves out of their own S3 buckets, which is relatively common, but with SCPs still allowing customers to decide to disable the failsafe.

Note that if you only changed the previous bucket policy statement to an "Allow", it'll be excessively permissive. It allows everyone in the world (not just in your account) to upload data to your bucket or delete objects, unless their aws:username condition key contains the value you'd specified. In general, you should always either specify a specific principal in the Principal element of an "allow" policy statement, or require a StringEquals, ArnEquals, or ArnLike match for aws:PrincipalArn or one of the other condition keys that identify the requesting principal (https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principal-properties).

If you have a specific IAM user you want to allow to delete and upload object, I suggest you change the statement to specify "Principal": { "AWS": "arn:aws:iam::000000000000:user/user-name-here" } and remove the "Condition" clause containing the aws:username comparison.'

The CLI commands that upload data to S3 generally only upload files, along with their relative folder paths. I'm not 100% sure if one of them might simulate empty folders, but I would assume they don't. If you want what appears as an empty folder structure in your bucket, you should create it separately, either via the console or with the CLI like so (note that there shouldn't be a leading / to the folder name):

aws s3api put-object --bucket my-bucket-name --key folder-to-create/ 
aws s3api put-object --bucket my-bucket-name --key folder-to-create/subfolder1/