By using AWS re:Post, you agree to the Terms of Use

Deny EFS actions to all but specific user

0

I'm trying to deny EFS actions to all users, except for one specific user(s).

When attaching a file system policy to my EFS, using a deny entry with NotPrincipal, I'm not able to access the EFS as I would have expected to.

Example file system policy:

{
    "Sid": "Limit to deployer/CI",
    "Effect": "Deny",
    "NotPrincipal": {
        "AWS": [
            "arn:aws:sts::account_id:assumed-role/role_name/my_email@my_domain.com"
        ]
    },
    "Action": [
        "elasticfilesystem:DescribeMountTargets",
    ],
    "Resource": "arn:aws:elasticfilesystem:eu-west-2:account_id:file-system/efs_id"
}

My expectation would be that my role session would have access to the listed action, but no one else would have access. However, when testing this, even my user is denied access. https://aws.amazon.com/blogs/security/how-to-restrict-amazon-s3-bucket-access-to-a-specific-iam-role/ suggests that both the role ARN and assumed-role ARN should be used in this scenario, however when testing this, it does not function.

Following the logic used within the blog post, I can create the following:

{
    "Sid": "Limit to deployer",
    "Effect": "Deny",
    "Principal": {
        "AWS": "*"
    },
    "Action": [
        "elasticfilesystem:DescribeMountTargets"
    ],
    "Resource": "arn:aws:elasticfilesystem:eu-west-2:account_id:file-system/efs_id",
    "Condition": {
        "StringNotLike": {
            "aws:userId": [
                "role_principal_id:my_email@my_domain.com",
                "account_id"
            ]
        }
    }
}

This does appear to work as I intend, however I'd like to understand the reasoning behind the first example not working, because it is much more usable and easily understandable.

3 Answers
1
Accepted Answer

Hi! This is a good question that goes through the nuances of using a combination of a DENY action with a NotPrincipal. As an AWS best practice, when using Deny with the NotPrincipal element - if the NotPrincipal elemnt was missing teh ARN of the aWS account that the role belongs to, the policy may explicitly deny access to the AWS account and all entities in that account, which would include your role session and the role. In some cases as well, assumed-role users cannot have more permissions than their parent role, and roles cannot have more permissions than their parent AWS account.

In the bottom example you give, since you are using the aws:userId, the AWS Account ID represents the AWS Account root user and the "role_principal_id:my_email@my_domain.com" represents the Role Session, which is slightly different than the above.

That most likely is why you are seeing unexpected results with the first policy, because it is possible the policy denies access to the AWS account and all entities in that account. It's not completely clear from AWS documentation.

answered 9 months ago
0

If you wants to allow one specific IAM Role using Role ARN, you should specify the Role ARN as following.

"Principal": { "AWS": "arn:aws:iam::AWS-account-ID:role/role-name" }

The ARN you used in your first policy is not for IAM Role but for Assumed-role session principals. And you missed role-session-name in the ARN. If you wants to specify role session name, you should add role session name as following.

"Principal": { "AWS": "arn:aws:sts::AWS-account-ID:assumed-role/role-name/role-session-name" }

Please refer to AWS docs blow. https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html

answered 9 months ago
  • Thanks for the response. I believe in my first example, I am using the role session name - arn:aws:sts::account_id:assumed-role/role_name/my_email@my_domain.com is in this form as my_email@my_domain.com is the name of my session. Looking through the CloudTrail events shows my ARN as this, so I believe I am including the session name, however it does not work as expected.

0

If an IAM policy associated with the user session or with the resource with does not have an explicit ALLOW then it may not work - the IAM policy evaluation logic you have will result in an implicit DENY as the explicit DENY in the policy does not apply. See https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html#policy-eval-denyallow

profile picture
answered 9 months ago
  • The IAM policy associated with the role session uses the AdministratorAccess permission policy, so an explicit allow exists. I think if this were the cause of the issue, removing the file system policy would result in my role session being unable to complete the elasticfilesystem:DescribeMountTargets action, whereas this is this is possible following the removal of the file system policy

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions