IAM Policy Condition with Role Session Name

0

Is there a way we can restrict the access to AWS resources for certain user ids through an assumed role session name ? Something like below ?

{
  "Sid": "VisualEditor1",
  "Effect": "Allow",
  "Action": [
      "ec2:*"
  ],
  "Resource": "arn:aws:ec2:*:1234567890:*",
  "Condition": {
      "StringEquals": {
          "aws:PrincipalArn": "arn:aws:sts::1234567890:assumed-role/accounting-role-name/kalmesh@xyz.com"
      }
  }
}

I tried multiple combinations for StringEquals and aws:PrincipalArn fields but didn't get it working.

  • Would below condition work?

         "Condition": {
            "StringEquals": {
              "aws:username": [
                "username1",
                "username2"
              ]
            }
          }
    
2 Answers
0

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"]}

profile picture
answered a year ago
  • 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?

0

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 a AssumedRole value,
  • aws:username is not present,
  • aws:userid has the format role-id:caller-specified-role-name, where role-id is the role internal identifier and caller-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"
        }
    }
}
AWS
ivan
answered 3 months ago

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