Deny EFS actions to all but specific user

Question

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.

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.

Answer

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

Answer

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

Deny EFS actions to all but specific user

Relevant content