Add ability to specify the STS region or endpoint URL in the config file when assuming a role

[ctavplay]

Is your feature request related to a problem? Please describe.
I can't assume a role in one region while issuing a command in another. Specifically, it's when the role being assumed requires the use of a specific VPC endpoint for the STS service, but the API being queried is in a different region and must be done as the role being assumed. Concrete example below.

Describe the solution you'd like
Either enhance the sts_regional_endpoints setting or create a new one with which we can force the use of a specific VPC endpoint or region in ~/.aws/config despite the region being passed to the AWS CLI.

Describe alternatives you've considered
One workaround I've employed is to assume the role in the correct region first, then grab the temporary credentials and set them as environment variables in the call to the next AWS CLI command. This is a bit cumbersome, though.

Additional context
Here's some sample code to try out.

The below AWS CLI config is for use by an ECS task (could just as easily be on EC2--makes no difference) running in a VPC with an STS endpoint in us-east-1. The role is assumed just fine if we direct our queries to us-east-1, e.g., aws --region us-east-1 s3 ls:

[default]
region = us-east-1
sts_regional_endpoints = regional
credential_source = EcsContainer
role_arn = arn:aws:iam::11111111:role/my_role
role_session_name = my_session

Here's the trust relationship for my_role which allows my-ecs-task to assume the role only through the STS VPC endpoint mentioned above.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::22222222:role/my-ecs-task"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "aws:SourceVpce": "vpce-01234deadbeef"
        }
      }
    }
  ]
}

Now if you try to issue a command to any other region, you'll get a 403 saying that my-ecs-task is not allowed to assume my-role. When looking at the debug output, you'll see that the role is being assumed in the region specified by the command-line argument:

$ aws --region us-west-2 s3 ls

The deny is expected. But it would be convenient if we could force the region that the role assumption happens in.

[tim-finnigan]

Thanks @ctavplay for the feature request. This does overlap with that existing feature request linked above (1270) but I will have to discuss with the team if these should be grouped or left as distinct feature requests.

[mcapts]

We follow a similar strategy of using a Condition in our assume role policies (trust relationships) that restrict role assumption to coming from a particular VPC endpoint, to ensure sensitive credentials cannot be obtained outside of specific secure environments. Having this issue solved would be a huge help to our AWS Organization and it's accounts!

[ctavplay]

If this proposal is accepted and implemented, it would address this issue: https://github.com/kdaily/aws-sdk/blob/endpoint-url-configuration-proposal/proposals/configure-endpoint-url.md

[tim-finnigan]

Thanks @ctavplay for following up here. As mentioned in several related issues such as #1270 (comment), we recommend providing feedback directly on that proposal or corresponding issue in our cross-SDK repository in order to help with tracking all of the use cases related to this feature request. I'll go ahead and close this issue but please let us know if you had any additional feedback to share.

[github-actions]

⚠️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.