Some workloads operate in a very restricted network context, and need to communicate with AWS APIs. Sometimes, that includes cross-region access. Consider the following scenario:
workload running in us-east-1, and uses AssumeRoleWithWebIdentity
workload needs to write an S3 object to a bucket in eu-central-1, and has network access to a PrivateLink endpoint in eu-central-1 over a VPC peering connection
workload does not have access to the global STS endpoint nor the eu-central-1 STS endpoint
We can configure one aspect of this behavior to work as desired, namely with AWS_STS_REGIONAL_ENDPOINTS=regional environment variable. This makes us use the regional endpoint. However, the default credential provider chain for SDKs still inherits the region from the configured client, meaning that we try to communicate with STS in eu-central-1 if we configure the S3 client to talk to that region.
The Service-specific endpoints feature looked like it would solve this problem: I could force supported SDKs to use only the local endpoint by configuring it through environment variables! This even works for the AssumeRoleWithWebIdentity call itself: since that request isn't signed, it doesn't matter that the STS client is configured to use a different region than the one we're sending the actual assume role request to. However, for STS requests that are signed, and where we're not explicitly passing in an endpoint URL, the signatures end up not matching:
An error occurred (SignatureDoesNotMatch) when calling the GetCallerIdentity operation: Credential should be scoped to a valid region.
So, a request (not sure if feature or bug): provide a way to explicitly override the region used for a specific service, or at least for STS since that's the backbone of practically all other AWS requests. Alternately, if there's an easy way to do this today, I'd love to hear about it (and maybe get it explicitly documented)!
Some workloads operate in a very restricted network context, and need to communicate with AWS APIs. Sometimes, that includes cross-region access. Consider the following scenario:
us-east-1, and usesAssumeRoleWithWebIdentityeu-central-1, and has network access to a PrivateLink endpoint ineu-central-1over a VPC peering connectioneu-central-1STS endpointWe can configure one aspect of this behavior to work as desired, namely with
AWS_STS_REGIONAL_ENDPOINTS=regionalenvironment variable. This makes us use the regional endpoint. However, the default credential provider chain for SDKs still inherits the region from the configured client, meaning that we try to communicate with STS ineu-central-1if we configure the S3 client to talk to that region.The Service-specific endpoints feature looked like it would solve this problem: I could force supported SDKs to use only the local endpoint by configuring it through environment variables! This even works for the
AssumeRoleWithWebIdentitycall itself: since that request isn't signed, it doesn't matter that the STS client is configured to use a different region than the one we're sending the actual assume role request to. However, for STS requests that are signed, and where we're not explicitly passing in an endpoint URL, the signatures end up not matching:So, a request (not sure if feature or bug): provide a way to explicitly override the region used for a specific service, or at least for STS since that's the backbone of practically all other AWS requests. Alternately, if there's an easy way to do this today, I'd love to hear about it (and maybe get it explicitly documented)!
References: