CODEWITHSUNDEEP
amazon-s3amazon-iam
Aakash Sheth
Aakash Sheth

Reputation: 350

AWS policy evaluation

I have an IAM role to be attached to a microservice in order to limit S3 folder access based on user-agent. The microservice parent account and the bucket owner are the same.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": [
                "arn:aws:s3:::bucket-test/service/${aws:useragent}/*"
            ]
        },
        {
            "Sid": "AllowListingOfUserFolder",
            "Action": [
                "s3:ListBucket"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::bucket-test"
            ],
            "Condition": {
                "StringLike": {
                    "s3:prefix": [
                        "service/${aws:useragent}/*"
                    ]
                }
            }
        }
    ]
}

The same S3 bucket has a default ACL where the account has R/W on objects and permissions.

Given the ACL and the IAM policy, I don't understand how this policy evaluates. For example, a user with the above role makes a put_object request to bucket-test/service/micro-b/new_object with user agent micro-a. Is this an explicit or implicit deny? Why?

Upvotes: 6

Views: 4800

Answers (1)

kosa
kosa

Reputation: 66637

Based on AWS Policy evaluation logic:

When a request is made, the AWS service decides whether a given request should be allowed or denied. The evaluation logic follows these rules:

  1. By default, all requests are denied. (In general, requests made using the account credentials for resources in the account are always allowed.)
  2. An explicit allow overrides this default.
  3. An explicit deny overrides any allows.

Now if we look at S3 access policy language documentation:

Effect – What the effect will be when the user requests the specific action—this can be either allow or deny. If you do not explicitly grant access to (allow) a resource, access is implicitly denied. You can also explicitly deny access to a resource, which you might do in order to make sure that a user cannot access it, even if a different policy grants access.

Now specifying Conditions in S3 policy documentation:

The access policy language allows you to specify conditions when granting permissions. The Condition element (or Condition block) lets you specify conditions for when a policy is in effect.

From these 3 pieces, specially the last one we can say that your case is "Conditional allow", because "Condition element lets you specify conditions for when a policy is in effect" and here the condition in your policy is "Allow".

EDIT: Here is another interesting blog from AWS on "How does authorization work with multiple access control mechanisms?"

Whenever an AWS principal issues a request to S3, the authorization decision depends on the union of all the IAM policies, S3 bucket policies, and S3 ACLs that apply.

In accordance with the principle of least-privilege, decisions default to DENY and an explicit DENY always trumps an ALLOW. For example, if an IAM policy grants access to an object, the S3 bucket policies denies access to that object, and there is no S3 ACL, then access will be denied. Similarly, if no method specifies an ALLOW, then the request will be denied by default. Only if no method specifies a DENY and one or more methods specify an ALLOW will the request be allowed.

Upvotes: 5

Related Questions