Explicit deny in a resource-based policy

Question

Dear Team AWS,

I accidentally got locked out of a s3 bucket because I paste this bucket policy
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::your-bucket-name/*",
      "Condition": {
        "StringNotLikeIfExists": {
          "s3:prefix": ["allowed-prefix/*"]
        }
      }
    }
  ]
}

upload failed: ./123 to s3://test-kms-bucket01/123 An error occurred (AccessDenied) when calling the PutObject operation: User: arn:aws:sts::0123456789012:assumed-role/assumerole/user is not authorized to perform: s3:PutObject on resource: "arn:aws:s3:::test-kms-bucket01/123" with an explicit deny in a resource-based policy

I've given the user and role the required policy and permission and this account was created under Organization and even with OrganizationAccessRole.

Please help.
https://ibb.co/dbbZHjv

Riku_Kobayashi · Answer

Hello.

Sign in to your AWS account as the root user and delete the bucket policy.  
To use the root user with member accounts managed by AWS Organizations, you must reset the root user's password as described in the following documentation:  
https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access-as-root.html

re:Post Agent · Answer

I understand your frustration with being locked out of your S3 bucket. The issue you're experiencing is due to the bucket policy you've applied, which contains an explicit deny statement. This deny statement takes precedence over any allow statements, even if you've granted permissions through user or role policies.

The bucket policy you've shared denies all S3 actions (*) for all principals (*) on the specified bucket, except for objects with prefixes that match "allowed-prefix/*". This means that unless your objects have that specific prefix, all operations will be denied.

To resolve this issue, you'll need to modify the bucket policy. Here are a few suggestions:

1. Remove the bucket policy entirely if it's not necessary for your use case.

2. If you need to restrict access, consider using an allow statement instead of a deny statement. This would grant access only to specific actions or principals.

3. If you must use a deny statement, make sure to include exceptions for the necessary roles and users in the policy.

4. You could also modify the condition to allow your specific role or user, for example:

"Condition": {
     "StringNotEquals": {
       "aws:PrincipalArn": ["arn:aws:iam::0123456789012:role/assumerole"]
     }
   }

Remember, when troubleshooting S3 access issues, it's important to check all levels of access control: bucket policies, IAM policies, ACLs, and any organization-level policies.

If you're still unable to access the bucket after modifying the policy, you may need to contact AWS Support, especially if this is a critical production bucket. They can help you regain access and provide guidance on setting up the correct permissions.

In the future, it's a good practice to test new policies on non-critical resources first, or to apply them gradually to avoid accidentally locking yourself out.  
**Sources**  
[AWS: Deny access to Amazon S3 resources outside your account except AWS Data Exchange - AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_resource_account_data_exch.html)  
[Troubleshoot access denied (403 Forbidden) errors in Amazon S3 - Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/userguide/troubleshoot-403-errors.html)  
[Amazon S3: Restrict management to a specific S3 bucket - AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_s3_deny-except-bucket.html)

Pavel · Answer

There are two options to restore access to S3 bucket that you got locked out from by incorrectly applying resource policy:

1. Use root access to log in and delete/update the policy. Resource policy does not apply to the root user that owns the account.
2. Use recently introduced IAM / Root Access Management functionality to configure access to linked accounts to perform actions that require root access (including restoring access to S3 bucket). This blog will provide guidance for how to do that: https://aws.amazon.com/blogs/aws/centrally-managing-root-access-for-customers-using-aws-organizations/

Explicit deny in a resource-based policy

Relevant content