Clever Geek Handbook

Prevent the user from even knowing about other users (folders) on AWS S3

I have a question about writing IAM policies on AWS S3 which is partially answered here in this nice post from Jim Scharf:

https://aws.amazon.com/blogs/security/writing-iam-policies-grant-access-to-user-specific-folders-in-an-amazon-s3-bucket/

Taking Jim's post as a starting point, I'm trying to get the user not even aware of the existence of other users accessing the same bucket when using the S3 console. Jim, as well as others I have found, restrict a given user's access to content inside another user's folder. But none of the solutions allow user "u" to do what I call "partial listing", i.e. Don't even display folders whose contents are not allowed by "u".

The following post is also very similar to my question:

How do I configure S3 policies for multiple IAM users so that each user has access to their personal bucket folder?

But unlike the setting in a post like this, I need to be like a filesystem structure that has an "intermediate" home folder between the bucket name and the user folder (as in Jim's post):

mybucket / home / user1

mybucket / home / user2

What I have done so far is as follows:

  • Created a single bucket, as well as several "folders" inside it
  • Created several users grouped in a group. Each user has a corresponding folder inside the bucket with the same name

  • Install the IAM policy that I linked to the group as follows:

    {
    "Version": "2012-10-17",
    "Statement": [
    {
        "Sid": "AllowUsersToSeeBucketListInTheConsole",
        "Action": ["s3:ListAllMyBuckets", "s3:GetBucketLocation"],
        "Effect": "Allow",
        "Resource": ["arn:aws:s3:::*"]
    },
    {
        "Sid": "AllowRootAndHomeListingOfMyBucket",
        "Action": ["s3:ListBucket"],
        "Effect": "Allow",
        "Resource": ["arn:aws:s3:::mybucket"],
        "Condition":{"StringEquals":{"s3:prefix":["","home/"],"s3:delimiter":["/"]}}
    },
    {
        "Sid": "AllowListingOfUserFolder",
        "Action": ["s3:ListBucket"],
        "Effect": "Allow",
        "Resource": ["arn:aws:s3:::mybucket"],
        "Condition":{"StringLike":{"s3:prefix":["home/${aws:username/*"]}}
    }
    ]
}

I understand that the Sid "AllowRootAndHomeListingOfMyBucket" above gives permission to "ListBucket" when the prefix is ​​"home /". This effectively allows any user "u" in the group to list the entire set of "f" folders inside the "home" folder, regardless of whether "u" has access to the given item "f" or not. I don't know if there is any reasonably designed Deny rule that even restricts the listing of those folders that "u" is not allowed to see.

According to Bob Kinney, this was not possible in 2013:

IAM policy to display specific folders inside S3 bucket for user

However, I'm not sure if everything changed at the same time. Any suggestion is greatly appreciated.

Thank.

+2


source to share


1 answer


No, this is not possible, because what the politician allows is not what you can see, but rather what you can ask to see. And S3's request to view object lists is done with a prefix and separator.

When moving the bucket, behind the scenes, the console prompts for the following things:

  • Click on the bucket: specify the root from the trash can (prefix an empty string with a delimiter /

    ) - returns all common prefixes ("folders") and all objects in the root to the same depth /

    . (This is not shown, but the folder names actually end with /

    when creating folders with consoles are the only reason the console shows them as folders - hidden /

    at the end of what is actually a regular empty object).

  • Click home

    : list all in the prefix home/

    with a separator /

    - returns all the common prefixes and objects home/

    to another /

    - so it returns home/david/

    , home/emily

    , home/genevieve/

    , home/james/

    , etc.

  • press david

    : list all prefixed home/david/

    with delimiter /

    ... you might get this idea.



Notice how these three clicks correspond to the allowed actions on the blog — root list, home list, directory list for the user at home.

Without being able to list other user's home directories, you can see that they exist, but you cannot drill through them.

To repeat ... politicians control what you can ask for, not what you can see. To go to your own home directory, you must be able to list the home directories, or you cannot go to yours. The main reason why this cannot be done with the console is that there is no policy you can write that prevents users from seeing other entries in the same level of the /

-delimited hierarchy that they can see, because the permission applies to the request, not the response.

+1


source






More articles:


All Articles