`The provided token is malformed or otherwise invalid`, accessing optional region about aws-cli HOT 7 CLOSED

Hi @peteristhegreat, thanks for reaching out. Could you provide debug logs of this process?

aws --profile other --region ap-east-1 sts get-caller-identity # fails (after clearing token cache)
aws --profile other --region us-east-1 sts get-caller-identity # succeeds
aws --profile other --region ap-east-1 sts get-caller-identity # succeeds

You can get debug logs by adding --debug to your command, and redacting any sensitive information. Thanks!

from aws-cli.

@RyanFitzSimmonsAK Thanks for the reply.
I redacted signatures, account numbers, keys, etc.
sts-debug.log

from aws-cli.

Hi @peteristhegreat, thanks for following up. I was not able to reproduce the issue. After clearing the cache, my first aws sts get-caller-identity call to an opt-in region succeeded. Could you tell me more about the role you are trying to assume? Is this a cross-account role? If so, does that other account have the same opt-in region enabled?

from aws-cli.

Our terraform scripts were unable to function due to this issue, so we added the optional region to our "root" or billing account, and then the issue went away. Now I can clear my cli cache json files and do the sts get-caller-identity and it works on the first try.

So in summary (according to my testing), to use an optional region consistently, the account where your IAM user lives seems to need to have that optional region for that account, too, to easily get the tokens for the cross account calls to the optional region.

@RyanFitzSimmonsAK I don't think I can recreate it easily now since adding the optional region to our root account, but the layout of the accounts and IAM before was something like:

root account (123)

• in us-east-1
• did NOT have optional region ap-east-1 enabled
• had my username as an IAM user

other account (345), in the AWS Organization of 123

• intended to be used in ap-east-1
• did have the optional region ap-east-1 enabled
• had my username arn as a trusted relationship in the policies for a cross account role

from aws-cli.

Glad you have it working now. Requiring the region to be enabled for both accounts feels like intended behavior, and the RegionDisabled error from the API reference would also indicate that, although I'm unsure why you didn't get that error back. Do you have any other questions?

from aws-cli.

No other questions. Thanks for the attention on the issue. I suspect someone else may run across this and now a search engine might find this thread in the future. Needing the optional region is both accounts appears to be the intended design.

Another option could be when you enable an "optional region" in the console or elsewhere, the console could show a recommendation to also "enable the region for accounts where your IAM user lives" to avoid token issues.

Feel free to close the issue.

from aws-cli.

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one. If you wish to keep having a conversation with other community members under this issue feel free to do so.

from aws-cli.