not authorized to perform: sts:AssumeRole on resource

[windycrypto]

Describe the bug

Context:

* Okta identity provider
* two IAM account environment - main and prod
* both IAM accounts has no IAM users, only roles. after login through Okta, we switch role from main account to prod
* trust and policies config no problem, everything is ok on aws management console
* saml2aws for passing MFA, generating the role credentials for the main account
* in ~/.aws/config the prod profile references the generated profile of the main account by using `source_profile=main`

Now we run aws --profile prod ec2 describe-instances.

Expected Behavior

lists the ec2 instances in the prod accounts

Current Behavior

reports:

An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:sts::<main_account_id>:assumed-role/<role_name>/<session_name> is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::<prod_account_id>:role/<role_name>

But, if I specify the role_session_name option to the same with the error reports one: <session_name>, then the error is gone.

Reproduction Steps

please see the describe

Possible Solution

No response

Additional Information/Context

No response

CLI version used

aws-cli/2.7.21 Python/3.10.6 Darwin/21.3.0 source/arm64 prompt/off

Environment details (OS name and version, etc.)

macos 12.2

[aBurmeseDev]

Hi @cifer76, thanks for reaching out and sorry to hear that you're having an issue.

For AccessDenied errors with cross-account operations, the possible root cause is most likely with permissions for the IAM roles where IAM role(s) don't have a trust policy to grant permission for performed actions. I am not sure what your IAM policies for both accounts look like but I could refer you to this troubleshoot guide.

Hope it helps but please let me know if you're still experiencing the issue.

[windycrypto]

@aBurmeseDev there's no problem when using aws management console so I think the trust policy is properly setup.

please look at my statements above, the error only occurs when I didn't specify the role_session_name of the profile in the ~/.aws/config. While if I omit that field, aws cli returns the AccessDenied error

[aBurmeseDev]

Thank you for the info. I wasn't able to reproduce the same error. Could you perhaps share your config files with sensitive information redacted along with the debug logs by adding --debug to your command?

Here's interesting thing about working with IAM roles: the docs mentioned

When many individuals share a role, auditing becomes more of a challenge. You want to associate each operation invoked with the individual who invoked the action. However, when the individual uses a role, the assumption of the role by the individual is a separate action from the invoking of an operation, and you must manually correlate the two.

You can simplify this by specifying unique role session names when users assume a role. You do this by adding a role_session_name parameter to each named profile in the config file that specifies a role. The role_session_name value is passed to the AssumeRole operation and becomes part of the ARN for the role session.

I also found this similar issue that might be worth checking out.

[aBurmeseDev]

@cifer76 - I just wanted to check in here to see if you're still having the issue as there hasn't been any recent activity on here. Please let us know!

[github-actions[bot]]

Greetings! It looks like this issue hasn’t been active in longer than five days. We encourage you to check if this is still an issue in the latest release. In the absence of more information, we will be closing this issue soon. If you find that this is still a problem, please feel free to provide a comment or upvote with a reaction on the initial post to prevent automatic closure. If the issue is already closed, please feel free to open a new one.

[VXConsulting]

Hello, I have the same issue since a couple of weeks. I am using a cross-account mechanism. Some accounts show an error and some don't show any error.

Kind Regards