- Newest
- Most votes
- Most comments
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.
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
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 asmy_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.
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
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
Relevant content
- asked 2 years ago
- AWS OFFICIALUpdated 9 months ago
- AWS OFFICIALUpdated 8 months ago
- AWS OFFICIALUpdated 9 months ago
Thanks - https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_notprincipal.html#specifying-notprincipal Actually makes this clear but I guess this is a case of needing to read more.
Best practice is to include the account ARN also, otherwise the entire account may be denied. Additionally, if you are attempting to allow a role session, you must also allow the ARN of the role itself - As the order of validation may cause you be denied access.