- 最新
- 投票最多
- 评论最多
According to the reference guide StringEquals will limit the value to be a string with exact matching, case sensitive. (https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html) Instead you can try to use Amazon Resource Name (ARN) condition operators such as: "ArnNotLike": { "aws:PrincipalARN": [ "arn:aws:iam::*:role/AWSControlTowerExecution"]}
Both the options suggested above doesn't work for assumed role. It still gives me the same error message "User: arn:aws:sts:: 1234567890:assumed-role/accounting-role-name/kalmesh@xyz.com is not authorized to perform.....because no identity-based policy allows...."
Are you trying to attach the policy that you mention above to your accounting-role-name role? What kind of action(s) are you taking to test it? Are you working in a single account or multiple accounts? Are there any other policies that may be blocking your action(s) such as Service Control Policies?
First of all: when you use aws:PrincipalArn
policy condition key, you shouldn't match assumed role session arn, but the role arn itself (see the docs):
you can specify the role principal as the principal in a resource-based policy or create a broad-permission policy that uses the aws:PrincipalArn condition key. When you use this key, the role session principal is granted the permissions based on the ARN of role that was assumed, and not the ARN of the resulting session.
So, the session is not part of the aws:PrincipalArn
. However, there are other attributes available in the context for examination.
There's a nice table that shows what values are available in the request context when condition is evaluated: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html#policy-vars-infotouse
Depending on the principal type different formats are used. For assumed role principal these are:
aws:PrincipalType
is aAssumedRole
value,aws:username
is not present,aws:userid
has the formatrole-id:caller-specified-role-name
, whererole-id
is the role internal identifier andcaller-specified-role-name
is the session name.
There's no context attribute with only the session name. So, all-in-all the best match attempt may look like this:
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"ec2:*"
],
"Resource": "arn:aws:ec2:*:1234567890:*",
"Condition": {
"StringEquals": {
"aws:PrincipalType": "AssumedRole"
},
"StringLike": {
"aws:userid": "*:kalmesh@xyz.com"
},
"ArnEquals": {
"aws:PrincipalArn": "arn:aws:iam::1234567890:role/accounting-role-name"
}
}
}
Would below condition work?