sts:AssumeRole permissions - not sure how to do that with Policy Sentry's crud templates

[kmcquade]

I'm not actually sure how to include sts:AssumeRole in the permissions using Policy Sentry.

policy_sentry query action-table --service iam --access-level permissions-management

That doesn't give anything with sts.

I think we might need to give this special treatment. I'd like to propose two options:

Option 1: assumeRole section

This would have the section dedicated to sts:AssumeRole. That might be excessive.

Option 2: K/V pairs of actions to resource ARNs

This would essentially allow you to specify individual AWS actions and resource ARNs that you want. We'd need to be careful to not allow this to be a super easy bypass mechanism.

sectionname:
  - action: "sts:AssumeRole"
     resource: "arn:aws:iam::12345678912:role/myrole"

User input would be appreciated here.

[kmcquade]

It's funny that I am filing a user support ticket for my own tool... but interested if anyone else has run into a solution for this, and if they have input.

[kmcquade]

Update: I think we should take approach #2 above. sts is a special case, after all - the resource types defined by the sts service are of ARN types iam - like arn:aws:iam::account:role/${RoleNameWithPath} or arn:aws:iam::account:user/${UserNameWithPath}.

Here's the template that I propose.

# Here, you can list any `sts` action along with a corresponding IAM user or IAM role ARN. 
# You should be able to provide the values as lists or strings.
# The action should be validated to be sts and the resource should be validated to be of IAM role type or IAM user type.
sts:
  - action: "sts:AssumeRole"
    resource: "arn:aws:iam::12345678912:role/myrole" # we should allow either * or the allowed resource types (user, role) here. 

[kmcquade]

I know that this might seem like a good place to use IAM conditions, but I want to avoid getting into the IAM Conditions business here, as that would overly complicate things, and would probably cause more confusion than it's worth.

[LeeHughsVariant]

I am currently facing this issue. Is there any update on this?

[kmcquade]

@LeeHughsVariant I believe this would need a separate section in the template. I can add it as mentioned here: #287 (comment). But I don't have the time for that at the moment. Might be able to do that next week, but I can't promise anything. Happy to take any PRs on this issue.

[knastase]

Attempted to address this in This PR modifying your option #2 slightly but I think it works. For example, this will create three SID namespaces, one for each assume role type and you can specify as many ARNs as you want. It also works with a single STS action and single ARN.

sts:
  assume-role:
    - arn:aws:iam::123456789012:role/demo
    - arn:aws:iam::123456789012:role/demo2
  assume-role-with-saml:
    - arn:aws:iam::123456789012:role/demo3
  assume-role-with-web-identity:
    - 'arn:aws:iam::123456789012:role/demo'

Produces:

{
    "Sid": "AssumeRole",
    "Effect": "Allow",
    "Action": [
        "sts:AssumeRole"
    ],
    "Resource": [
        "arn:aws:iam::123456789012:role/demo",
        "arn:aws:iam::123456789012:role/demo2"
    ]
},
{
    "Sid": "AssumeRoleWithSAML",
    "Effect": "Allow",
    "Action": [
        "sts:AssumeRoleWithSAML"
    ],
    "Resource": [
        "arn:aws:iam::123456789012:role/demo3"
    ]
},
{
    "Sid": "AssumeRoleWithWebIdentity",
    "Effect": "Allow",
    "Action": [
        "sts:AssumeRoleWithWebIdentity"
    ],
    "Resource": [
        "arn:aws:iam::123456789012:role/demo"
    ]
}

[kmcquade]

Fixed by #386