How to address AccessDenied in AssumeRole scenario

0

We upgraded our LZA from 1.4.0 to 1.5.1. While the Accelerator was successfully upgraded, the LZA pipeline in our infrastructure failed. We have zeroed down the root cause of that failure but we have to rollback a stack in AccountNumber1. While attempting to rollback a stack, we came across this error:

Received response status [FAILED] from custom resource. Message returned: AccessDenied: User: arn:aws:sts::ACCOUNTNUMBER1:assumed-role/AWSAccelerator-LoggingSta-CustomSsmGetParameterVal-11JC2UIB25P8W/AWSAccelerator-LoggingSta-CustomSsmGetParameterVal-G1BGpUVtkP66 is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::ACCOUNTNUMBER2:role/AWSAccelerator-CentralBucket-KeyArnParam-Role

The roles have appropriate permissions and trust policy as the Accelerator has created. Any help on resolving this issue will be appreciated. Thanks.

1 Answer
0

Hey RK,

So there are 3 places that a deny could be occurring, here:

  1. The role making the "AssumeRole" call doesn't have the explicit permission, or has been explicitly denied.
  2. The role being assumed doesn't permit "AssumeRole" at all, or specifically from the assuming role.
  3. An SCP is in place on your organisation which prevents this call from being made. If the 2 roles are in 2 separate AWS Organizations, then it could be an SCP in either.

Remember to bear in mind that a deny could be coming from not only an explicit deny statement, but also implicitly - because everything is implicitly denied by default on AWS. You may have a Condition block in a permission policy on the source role which grants access to "AssumeRole", but it could be incorrectly written and thus result in an implicit deny, because no permission is actually been given to it to make the call against the target role. Using the IAM Policy Simulator might be a good shout, here, or even IAM Access Analyzer.

If you're getting an error message in the console, it should also tell you where the deny is coming from - IAM policy, trust relationship, or SCP, which can help you narrow your search.

If all else fails, I would then say that you're going to need to start sharing some JSON from the roles - namely the statement granting access to "AssumeRole", the Trust Relationship allowing the role to be assumed, and any SCP or Permission Boundary that may be associated with either role. If you do add JSON to a comment, please make sure that you redact any account-sensitive/specific information, such as resource unique IDs and account numbers - both typically found in ARNs.

profile pictureAWS
answered 6 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