CODEWITHSUNDEEP
amazon-web-servicesamazon-s3virtuozzo
Luca Manea
Luca Manea

Reputation: 1

Disable ACLs for S3 buckets in Virtuozzo

I have an S3 environment which is hosted by Virtuozzo, but it implements the aws API. All the things I hit it with like boto3, s3cmd and aws s3api work just fine.

I'm trying to achieve the following functionality for buckets:

I've quickly seen that ACLs are not fine grained enough to achieve this, and therefore tried with policies.

I ended with something like this policy:

{
    "Statement": [
        {
            "Effect": "Allow",
            "Action": ["s3:PutObject", "s3:GetObject"],
            "Resource": "arn:aws:s3:::<bucket-name>/*",
            "Principal": { "AWS": "arn:aws:iam::<guest_user_id>:user/test.guest" }
        },
        {
            "Effect": "Allow",
            "Action": ["s3:ListBucket"],
            "Resource": "arn:aws:s3:::<bucket-name>",
            "Principal": { "AWS": "arn:aws:iam::<guest_user_id>:user/test.guest" }
        },
        {
            "Effect": "Deny",
            "Action": ["s3:DeleteObject", "s3:PutObject"],
            "Condition": {
                "StringEquals": {
                    "s3:x-amz-metadata-directive": "REPLACE"
                }
            },
            "Resource": "arn:aws:s3:::<bucket-name>/*",
            "Principal": { "AWS": "arn:aws:iam::<guest_user_id>:user/test.guest" }
        }
    ]
}

I quickly realized my policy was completely ignored and the test.guest user had no rights in the bucket. I read here and here and understood that if ACLs are enabled, policies are somewhat overwritten:

ACLs no longer affect access permissions to your bucket. As a result, access control for your data is based on policies, such as IAM policies, S3 bucket policies, VPC endpoint policies, and Organizations SCPs.

Also, from what I tested with both policies and ACLs in place, policies are ignored and ACLs rule.

I've read here that in order to disable ACLs I need to set "Bucket owner enforced setting for S3 Object Ownership". I quickly stumbled upon this command for AWS CLI command, as you couldn't do it with s3cmd . Finally, after running it as it's explained in the Examples section of the article, the bucket still had no Policy Statuses and policies were still ignored (i.e. the guest user had no rights):

aws --endpoint-url=https://<my-endpoint> s3api get-bucket-policy-status --bucket <bucket-name> 
{
    "PolicyStatus": {}
}

Moreover, I've seen that default options for new buckets should have ObjectOwnership=BucketOwnerEnforced by default, but this is obviously not the case for my endpoint. The admin web interface for Virtuozzo doesn't really have any options in this direction.

And this is where my boss told me to give up and do something more useful. I'd like to know though what I did wrong, just to know for the future. I'm also wondering if my endpoint is at fault and actually it's not behaving as an S3 server would.

Upvotes: 0

Views: 54

Answers (1)

John Rotenstein
John Rotenstein

Reputation: 269826

Buckets are private by default, so you should never need to use a Deny policy unless permissions were granted by another policy that you want to override. For example, perhaps the Admins group has been granted access to all buckets, but there is an HR bucket that you don't want them to access. You could use Deny to achieve this.

In general, a Bucket Policy should only be used for:

  • Granting public (anonymous) access, or
  • Granting cross-account access

To grant permission to a group of users (eg Admin) or to specific users, it is better to grant the permissions via a policy on the IAM User or IAM Group (without using a Bucket Policy).

ACLs are best avoided because they are confusing and limited in scope. You should be able to meet your security goals via IAM policies instead.

Upvotes: 0

Related Questions