Unable to deploy to non-default region when using AssumeRole credentials #268
-
Describe the bugWhen trying to deploy a serverless application to a non-default region (i.e. Expected BehaviorThe lambda code in the zip file should upload and the serverless template should be deployed. Current BehaviorThe output of
and then after compiling and zipping the code, when it attempts to upload the zip file, it errors out with
And exits the deployment. Reproduction Steps
Possible SolutionLooking through the source code for the aws extensions for dotnet, I couldn't see anything obvious. I did see that you use the C# sdk, so the issue may be with it's handling of profiles, but because I found the issue in this lbrary, I decided to raise the bug here. I did check the results of {
"LocationConstraint": "ap-southeast-4"
}Which says to me that the profile and the bucket are set up fine, and given this is the same call that GetBucketRegionAsycn makes, I can only assume that it's some difference between the way the cli handles the profile vs how the C# sdk handles the profile. Additional Information/ContextI am using MFA for my roles, and I'm using this powershell module AWSCredentialsManager to assist with the AssumeRole and MFA details. Targeted .NET platform7.0.201 CLI extension versionEnvironment details (OS name and version, etc.)Windows 10 |
Beta Was this translation helpful? Give feedback.
Replies: 12 comments
-
|
Additional information: |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Whoops, accidentally closed the issue. Sorry... |
Beta Was this translation helpful? Give feedback.
-
|
Hi @scottjbaldwin, Good afternoon. Thanks for reporting the issue. Somehow I'm unable to reproduce the issue. Below are the steps I followed:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<<account-id>>:root"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}You may replace
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"lambda:CreateFunction",
"iam:GetRole",
"lambda:TagResource",
"lambda:ListFunctions",
"apigateway:PUT",
"lambda:GetFunction",
"iam:CreateRole",
"iam:DeleteRole",
"iam:AttachRolePolicy",
"apigateway:DELETE",
"iam:PassRole",
"lambda:AddPermission",
"iam:DetachRolePolicy",
"apigateway:PATCH",
"lambda:DeleteFunction",
"apigateway:POST",
"apigateway:GET"
],
"Resource": "*"
}
]
}
In this case, my
Please review if you are following different steps or if I'm missing anything. Thanks, |
Beta Was this translation helpful? Give feedback.
-
|
@ashishdhingra, |
Beta Was this translation helpful? Give feedback.
-
@scottjbaldwin Could you please elaborate what are you referring to by default region? Is it the region in the |
Beta Was this translation helpful? Give feedback.
-
|
Note, you will have to enable |
Beta Was this translation helpful? Give feedback.
-
|
@ashishdhingra by non-default region, I mean a region that you don't get access to by default in an AWS account, i.e. an opt-in region as per this table https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-regions:~:text=for%20a%20resource-,Available%20Regions,-Your%20account%20determines |
Beta Was this translation helpful? Give feedback.
-
@scottjbaldwin Thanks for the inputs, it really helped. It appears to be reproducible for non-default (required to opt-in region). Executing Executing AWS CLI command {
"LocationConstraint": "ap-southeast-4"
}Also using the So the issue appears to be with the underlying .NET SDK that fails to successfully call |
Beta Was this translation helpful? Give feedback.
-
|
@scottjbaldwin Upon further investigation, Managing AWS STS in an AWS Region mentions that In PowerShell session: In command line (Windows): Also refer AWS STS Regionalized endpoints where it states that AWS recommends using Regional AWS STS endpoints instead of the global endpoint. So, you may set it at Please let me know if it works for you. After your confirmation, I would consider this issue as resolved (since it is the default behavior as per above documentation) and convert this issue into Thanks, |
Beta Was this translation helpful? Give feedback.
-
|
Hey @ashishdhingra, thanks so much for diving into this issue and providing the resolution. I really appreciate your diligence on this one. This does indeed fix the issue, and I am able to deploy my application (although there were still some remaining regional issues, but completely unrelated to this issue). I guess that means I'll need to update my blogpost, as technically it is not so much a bug, as a corner case that people need to be aware of. Totally support this issue being converted into a Again, thanks for your help. |
Beta Was this translation helpful? Give feedback.
-
|
Hello! Reopening this discussion to make it searchable. |
Beta Was this translation helpful? Give feedback.
@scottjbaldwin Upon further investigation, Managing AWS STS in an AWS Region mentions that
Session tokens from the global STS endpoint are valid only in AWS Regions that are enabled by default. While per the mentioned article, you could change the setting in AWS account, the other workaround is to set environment variableAWS_STS_REGIONAL_ENDPOINTSwith valueregionalin the current session. I tested this and it worked.In PowerShell session:
$env:AWS_STS_REGIONAL_ENDPOINTS="regional"In command line (Windows):
set AWS_STS_REGIONAL_ENDPOINTS=regionalAlso refer AWS STS Regionalized endpoints where it states that AWS recommends using Regional AWS STS endpoints instead of the global endpoin…