Allow AssumeRole from an assumed (SSO-generated) role? [Solved]

0

This was mostly pilot error; I had the wrong role name!

For future reference, this is the trust policy that worked for us:

"AssumeRolePolicyDocument": {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowLambdaService",
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    },
    {
      "Sid": "AllowTrustedARNs",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::222222222222:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_Admin_0123456"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
},

Below is the original question for context.


We have a single-org, multi-account setup. We're using IAM Identity Center SSO on our organizational management account, and we've successfully used it to replace most CLI and web access to our AWS resources.

How can we configure a normal IAM Role to trust (i.e., allow sts:AssumeRole from) anyone that can authenticate into an SSO-generated role (on a "leaf" account, not on the org account)?

For example, let's say our org account is 111111111111 and our leaf account is 222222222222.

The org account has a PermissionSet named 'Admin'. User alice@example.com is assigned to that permission set for the leaf account.

As soon as the org account has any assignments against the leaf account, the SSO system uses the PermissionSet (on the org account) to create a Role (on the leaf account). In this case, let's say that it creates arn:aws:iam::222222222222:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_Admin_0123456.

When Alice wants to connect to the leaf account, she goes through AWS SSO and ends up with a temporary session within that role; sts get-caller-identity returns something like:

{
    "UserId": "AROA....:alice@example.com",
    "Account": "222222222222",
    "Arn": "arn:aws:sts::222222222222:assumed-role/AWSReservedSSO_Admin_0123456/alice@example.com"
}

We would like to allow Alice to assume a standard IAM role on account 222222222222, e.g., arn:aws:iam::222222222222:role/my-lambda-execution-role.

But we're unable to find any way to express this in the trust relationship for the local role. Even if IAM accepts my syntax, Alice always receives:

$ aws sts assume-role \
    --role-arn 'arn:aws:iam::222222222222:role/my-lambda-execution-role' \
    --role-session-name 'mock_lambda'

An error occurred (AccessDenied) when calling the AssumeRole operation: 
User: arn:aws:sts::222222222222:assumed-role/AWSReservedSSO_Admin_0123456/alice@example.com 
is not authorized to perform: 
sts:AssumeRole on resource: arn:aws:iam::222222222222:role/my-lambda-execution-role

Things we've tried:

  1. Verified that the AWSReservedSSO_Admin_0123456 role is allowed to do sts:AssumeRole (via the IAM Simulator);
  2. Copied the denied user string directly (IAM accepts the change, but Alice still get AccessDenied.)
  3. Tried various permutations of the Role ARN without any success. (Honestly don't recall which of these were rejected outright by IAM, vs those that were accepted but still didn't allow Alice to assume the local role.)
    • role/AWSReservedSSO_Admin_0123456
    • assumed-role/AWSReservedSSO_Admin_0123456
    • assumed-role/AWSReservedSSO_Admin_0123456/alice@example.com)
    • both arn:aws:sts::... and arn:aws:iam:... forms for the ARNs
  4. Tried trusting root along with a Condition to limit incoming roles (similar to this) (accepted, still denied).

Other answers we've found tend to fall into one of a few buckets:

  1. Only ever use one layer of roles: Doesn't seem possible while still providing per-lambda roles.
  2. Configure IAM roles to trust federated users: Seems to duplicate grouping / permissions set on the Identity Center? (Also seems to require specifying individual users even within the federated identity; if so, that's more duplication we'd prefer to avoid.)
  3. Problems with ~/.aws/config: This seems to be working fine, since sts get-caller-identity is happy, and we can do most other CLI things successfully.

Interestingly, we're able to successfully use the following in our EKS authentication map:

    - rolearn: arn:aws:iam::222222222222:role/AWSReservedSSO_Admin_0123456
      username: "sso:admin:{{SessionName}}"
      groups:
        - admin

Thanks in advance for any ideas / suggestions you might have!

1 Answer
0
Accepted Answer

As explained in the (edited) question, I was testing against the wrong role name!

The correct role ARN for the trust relationship is everything up to the last slash. So if the output from sts get-caller-identity shows something like:

"arn:aws:sts::222222222222:assumed-role/AWSReservedSSO_Admin_0123456/alice@example.com"

Then the trust policy should use the truncated ARN:

"arn:aws:sts::222222222222:assumed-role/AWSReservedSSO_Admin_0123456"
answered a year ago
  • Heya Anthony thanks for posting this. I just want to ask if you use SSO to access EKS. The problem we have is for example

        - rolearn: arn:aws:iam::222222222222:role/AWSReservedSSO_Admin_0123456
          username: "sso:admin:{{SessionName}}"
          groups:
            - admin
    

    The suffix 0123456 changes on every update to the sso role so we cannot add it to the EKS aws-auth configmap. To possibly get around this, I'm thinking of role chaining, that is assuming another role so it looks like Assume SSO role --> assume another IAM Role --> then add this role to the aws-auth configmap. Would this approach work? Thanks in advance!

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