Summary

The website content discusses troubleshooting an AWS "not authorized to perform: sts:AssumeRole" error, emphasizing the importance of error handling and fixing automation to prevent recurring mistakes.

Abstract

The author shares a personal experience with a common AWS error related to assuming roles with an external ID. The error message, "not authorized to perform: sts:AssumeRole," can be misleading, as it may not directly indicate a typo in the AWS configuration file, which was the case for the author. They mistakenly typed "externalid" instead of "external_id." The article suggests that the AWS CLI should provide more informative error messages for such configuration issues. The author also reflects on the broader implications of thoughtful error handling as a security measure and the importance of taking the time to correct automation processes to save time in the future. Additional causes for the error are listed, including missing MFA ARN, incorrect trust policy, absence of an external ID, lack of STS:AssumeRole permission, regional restrictions, and other typographical errors in configuration values. The author advises checking CloudTrail for user actions in the account where the user exists and in the region configured for the AWS CLI.

Opinions

The author believes that AWS should improve error messaging for invalid configuration values in the AWS config or credentials file to help users identify and fix typos more efficiently.
They express frustration with repeatedly making the same mistake due to a typo in their automation setup, emphasizing the need for diligent error handling.
The author suggests that a more descriptive error message would not compromise security but would guide users in resolving configuration issues.
They advocate for the importance of fixing automation to prevent future occurrences of the same problem, which can save time and reduce errors.
The author values the role of thoughtful error handling as a critical component of security defenses.
They encourage readers to take the time to correct their automation processes, highlighting the long-term benefits of such an investment.

not authorized to perform: sts:AssumeRole on resource

Problem assuming a role using external ID

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Check out my series on Automating Cybersecurity Metrics | Code.

🔒 Related Stories: Bugs | AWS Security | Secure Code

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Have you ever made the same mistake multiple times and spent way too long on it and kicked yourself in the end? That’s what this error does to me. I think it’s because I have automated the process to set this up but I have a typo somewhere. I always add a note to go back and fix it but then I forget.

The solution to this problem is very simple.

In my case, I typed “externalid” in the aws config file instead of “external_id”.

Now, it is interesting that the error message is not more helpful but in the case of the remote account, that might be a good thing — so as not to give a remote attacker information about what they are doing wrong if they *missing* an external ID when one is required.

However, it seems like a malformed keyword in the aws config file should throw an error from the CLI telling you that you have added a configuration setting that the AWS CLI does not understand and which one it is. That’s not giving attackers any information. That’s simply telling the user — fix your typo, dude.

Thoughtful Error Handling

Your error handler is one of your most important security defenses

medium.com

In my case, because I know I have had this working so many times already, I presumed the error was a typo in the role, or an external id and sheesh. It’s so simple. AWS, please add an error for invalid config values in the AWS config or credentials file. #awswishlist.

Painful. And dumb that I keep doing it over and over again!

Another moral of this story is, take the time to fix your automation and it will save you time later. :-/

Other things that cause this error:

If the role assumption requires MFA you must have an MFA ARN in your CLI profile configuration.
Your role needs to have a trust policy that allows the remote user to assume the role.
If the external id is missing and is required you also get this error.
If you have not granted your user permission to perform STS:AssumeRole on the role you will get this error.
If you are not allowed to assume the role in the specified region you might get that error.
Typo in any of the config values. Once I had one colon (:) instead of two in the role ARN, for example. Copy and paste whenever possible.

And by the way, the error message shows up in the account where the user exists, not the remote account, in the region configured for the AWS CLI when the command was run. Search for actions by that user in CloudTrail.

Follow for updates.

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab