You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
the IAM Assume Role -function seems to have broken in this commit: 7e9a5dc
It looks like moving the AWS_PARTITION-variable inside the getWhoami -function seems to have broken it for some reason. With the commit applied, trying to assume a role leads to this error:
./prowler -g cislevel1 -A 01234567890 -R ExampleRole -M json
An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::01234567890:user/example-user is not authorized to perform: sts:AssumeRole on resource: arn::iam::01234567890:role/ExampleRole
As you can see, the 'aws' -partition in the assumed role ARN is left empty, so it looks like the variable is not set properly. Slicing the partition from the CALLER_ARN -variable still works, so that hasn't changed.
A quick fix for this that worked, at least for me, was moving the CALLER_ARN, USER_ID and AWS_PARTITION -variables outside the getWhoami -function. This way the partition variable gets set correctly.
The text was updated successfully, but these errors were encountered:
Hi,
the IAM Assume Role -function seems to have broken in this commit: 7e9a5dc
It looks like moving the AWS_PARTITION-variable inside the getWhoami -function seems to have broken it for some reason. With the commit applied, trying to assume a role leads to this error:
As you can see, the 'aws' -partition in the assumed role ARN is left empty, so it looks like the variable is not set properly. Slicing the partition from the CALLER_ARN -variable still works, so that hasn't changed.
A quick fix for this that worked, at least for me, was moving the CALLER_ARN, USER_ID and AWS_PARTITION -variables outside the getWhoami -function. This way the partition variable gets set correctly.
The text was updated successfully, but these errors were encountered: