-
Notifications
You must be signed in to change notification settings - Fork 9.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Terraform AWS provider unable to assume role using profile that assumes a role itself #8052
Comments
Similar behaviour with latest version of terraform and the roles defined in ~/.aws/credentials and aws provider config specifying
|
So I have determined why this is occurring. I'm happy to submit a PR to fix this, however feel that the PR would be better suited for the See: |
I believe this is fixed with hashicorp/aws-sdk-go-base#5 PR. It sounds very similar. |
I'm encountering what I believe to be the same issue, using an AWS profile with a
I first noticed this when trying to add a provider which used an
The error I see:
|
Same thing happening to me with a configuration similar to @ianwsperber's except instead of using 2 providers it happens with one provider and an S3 bucket as the backend. Works fine without the backend. |
Please note that #8987, which was just merged and will release in version 2.16.0 of the Terraform AWS Provider later today, included this upstream fix aws/aws-sdk-go#2579, which is listed in the AWS Go SDK CHANGELOG as:
Hopefully this will help here. I also submitted this in Terraform Core to ensure the S3 Backend gets this update as well: hashicorp/terraform#21815 |
Hi folks 👋 This should be resolved in the S3 Backend as of Terraform version 0.12.3 and in the Terraform AWS Provider as of version 2.16.0. I verified this locally via this configuration: provider "aws" {
region = "us-east-2"
version = "2.17.0"
}
data "aws_caller_identity" "current" {}
output "caller_arn" {
value = "${data.aws_caller_identity.current.arn}"
} This setup of AWS credentials and configuration files locally: $ cat ~/.aws/config
[profile tf-acc-assume-role]
role_arn = arn:aws:iam::--OMITTED--:role/tf-acc-assume-role
source_profile = tf-acc
[profile tf-acc-assume-role-2]
role_arn = arn:aws:iam::--OMITTED--:role/tf-acc-assume-role-2
source_profile = tf-acc-assume-role
$ cat ~/.aws/credentials
[tf-acc]
aws_access_key_id = --OMITTED--
aws_secret_access_key = --OMITTED-- And running: $ export AWS_SDK_LOAD_CONFIG=1
$ export AWS_PROFILE=tf-acc-assume-role-2
$ terraform apply
data.aws_caller_identity.current: Refreshing state...
Apply complete! Resources: 0 added, 0 changed, 0 destroyed.
Outputs:
caller_arn = arn:aws:sts::--OMITTED--:assumed-role/tf-acc-assume-role-2/1562206728701794000 For future bug reports or feature requests relating to provider authentication, even if they look similar to the error messages reported here, please submit new GitHub issues following the bug report and feature request issue templates for further triage. These types of issues tend to be very environment specific. 👍 |
@bflad Unfortunately I'm still encountering this issue. Note that my validation method was slightly different. I am using a profile with only a single layer of assumed roles (
Error
I believe this is more similar to the use case for the original comment than that you provided. Could we reopen the issue? |
@ianwsperber, did you set |
@rekahsoft I did! I've included details below. Was your original problem fixed by this release? It closely resembles my own, so if it fixed yours I'd expect it to fix mine :/
I've quadruple checked my config files are setup correctly
Moreover |
This is failing for me as well with Terraform v0.12.5 and provider 2.20.0. These are roles that work fine with TF 0.11. Both of these scenarios fail for me:
Interestingly in my case, the Terraform plan works fine. It's only the apply that fails. This is especially odd because the remote state backend is configured to assume the same role, and that part seems to be working since Terraform can read the remote state during the plan. |
@timoguin did you ever find how to fix this? I’m running Terraform via CI/CD and credentials are set via environment variables as well. |
@shots-crazy No, I've not figured it out. I'm running all my 0.12 Terraform by manually assuming roles into each account after establishing an MFA session with aws-vault. Before 0.12, Terraform would use those credentials from the environment variables to actually assume the role defined in the Our CI/CD system is completely broken by this. This is the error I get trying to apply plans:
|
@timoguin I am getting the same error when running via CI/CD |
Has anyone been able to try @YakDriver's solution? I promised to try it out but have been too busy to do this work :/ If we can validate that works hopefully the TF team can iterate on a fix more quickly: hashicorp/aws-sdk-go-base#5 (comment) |
I have tried @YakDriver 's solution, but it does not seem to work for me
I followed YakDriver's instructions posted above to do the build with the addition of:
|
@bflad Still encountering this issue, can we reopen it? |
Still broken |
It's worth noting that, in my case, the S3 backend is configured to assume the same role as the provider is. It reads the remote state just fine. It can run a plan just fine. It's only the apply it fails on. My configuration is simply having I also tried building everything with the patched aws-sdk-go. I had the same unsuccessful result as @jgartrel. |
Use this tool https://github.com/remind101/assume-role |
Two big issues remain. Also, I suggest moving this conversation to hashicorp/aws-sdk-go-base#4, which is still open. 1 - Testing frameworkCredentials being key to everything, the maintainers are hesitant to move forward without automated regression tests. The code in question is very old, moved from place to place. Even still, everyone knows what to expect. They don't want to fix a 3% issue and break 97%. Help creating regression tests would be welcome. 2 - Fixing all the issuesMy fix seems to have fixed some but not all of the issues. We need to figure out what else remains. The feedback on this issue is very helpful in that regard. |
@rekahsoft If you have a minute, can you contribute this to my collection of credential tests? I'm trying to get an easily reproducible set of problems together: https://github.com/YakDriver/terraform-cred-tests |
@YakDriver will do. Sorry for the latent response, been on vacation. I'm back next week and will send a PR to your repo. Thanks for putting this together. |
I have credentails in env variables,
I could verify that while executing module setup the role is org_admin under account C (using caller identity) but I see cloudtrail under Account A that it failed to assume role org_admin under Account C. Should it not try to assume role from Account B to Account C. Why is provider still trying to Assume from it from account A -> Account C when provider was created under setup module which was invoked with provider B_org_admin. Questions
|
From what I'm reading, this ticket is outstanding and we're not able to assume roles from a primary provider using an alias? Why is the ticket closed? I'm getting a similar issue. Output:
My code:
|
Some project owners have a policy of closing tickets when they are too hard to fix so that it doesn't run up their median time for opened tickets |
Actually this worked for me. I used a better strategy although this is not documented anywhere. My learning is remove the Access and Secret key credentials from the environment variables.if not remove the TF does not behave as expected. Set the config and credentials environment variables. AWS_SHARED_CREDENTIALS_FILE – Specifies the location of the file that the AWS CLI uses to store access keys. The default path is ~/.aws/credentials). AWS_CONFIG_FILE – Specifies the location of the file that the AWS CLI uses to store configuration profiles. The default path is ~/.aws/config). AWS_SDK_LOAD_CONFIG="true" Instead of assuming roles as stated above set them under config. You can go any level in assuming role and all you have to do is set the profile in providers definition and use it as alias(if required). e.g config [profile AnAccount] provider "aws" { provider "aws" { #How to use it This logic works perfectly. |
Hi folks, the fix @YakDriver described above is scheduled to be released with v2.32.0 next week. If you upgrade and the problem you had is still happening, please open a new issue so we can address the errors separately. Thanks! |
In my case the problem with role assumption was talking to AWS at all because the docker container (alpine) didn't have the certificate installed (I noticed it because Terraform version checker call failed as well) - this doesn't show up even in trace logs. Installing |
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks! |
When using a a chain of aws cli profiles, one of which assumes a role, the aws provider fails to assume roles, as there are no credentials in
~/.aws/credentials
for the corresponding profile. That is, given 2 profiles,A
andR
where:A
is an IAM user and thus credentials for this profile exist within~/.aws/credentials
R
is a role assumed using the profileA
. Note this means there are no credentials available for this profile in~/.aws/credentials
Finally, there exists a role
T
which can be assumed byR
.When using terraform with the profile
R
, the aws provider is unable to assume roleT
. However, when using the awscli, this works with the following configuration:All of the following calls succeed and use the correct role/identity, implying that the
A
profile can assume the rolearn:aws:iam::xxxxxxxxxxxx:role/Role-A
via the profileR
which can then assume the rolearn:aws:iam::xxxxxxxxxxxx:role/Role-T
via the profileT
.This issue can be worked around by using the profile
A
after allowing it to assume the roleT
, however this greatly increases our maintenance overhead and is not acceptable.Community Note
Terraform Version
Affected Resource(s)
Unable to provision resources as role cannot be assumed by the aws provider.
Terraform Configuration Files
Debug Output
I'm not providing debug output as it contains private information, however here are a few small snippets that seem relevant:
Panic Output
N/A
Expected Behavior
Terraform aws provider assumes the role
arn:aws:iam::xxxxxxxxxxxx:role/Role-T
using the profileR
.Actual Behavior
Terraform fails to assume the role, failing with the following error message:
Steps to Reproduce
When using terraform, the role with arn
arn:aws:iam::xxxxxxxxxxxx:role/Role-T
cannot be assumed by the provider:Important Factoids
N/A
References
The text was updated successfully, but these errors were encountered: