-
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 with local AWS services #3608
Comments
Using this with
Not to say that it doesn't exist, but I'm very cautious now after reading this issue. |
This issue has nothing to do with Do you mind sharing your Terraform config |
Provider Config
Test Resource:
terrafrom plan
|
Hmm odd. After replicating your exact configuration in a new dir and running a fresh
I still get the following error:
I'm not sure what is going on here. @aventurella would you mind sharing the OS you are working on? Here is mine:
Next step is probably to find where in the source code this error is being thrown -- I will try do this when I have a spare moment in the next week. Appreciate the help so far :-) |
I don't know if this will help.. but I do have a |
Great. Now can you confirm that the credentials under
Should yield something that looks like the following
My main question here is to see whether dummy credentials work or whether in fact you need a valid AWS IAM for this to work. |
Bingo... I just changed
Additionally, if I suffix the credentials under So it would seem terraform, when given a new url for an AWS resource, still does some preliminary check with the credentials. That would make sense in terms of, you may only have done 1 new url for an AWS service. I don't know why anyone would only do one. Nevermind, I do. I had a client once that had their own S3 implementation, but still could use AWS for other things. |
Thanks @aventurella For everyone else interested in debugging this I have created a test repo with the above setup -- https://github.com/j-groeneveld/terraform-providers-3608. |
@j-groeneveld I was just able to get this working by including
|
@iadknet Terraform doesn't appear to be honoring the |
@Ghazgkull Ah, I realize now why it was working for me. I thought it was because I introduced the You're right, if I remove the s3 backend, and do not inject valid credentials, then |
Yeah, we went through the same mystery phase of "Why is it working for some people but not others???" |
I have been able to work around this by also setting: |
I am not sure if dynamodb-local is supposed to work without sending credentials. I can't get it to work with the aws cli either.
And I think that error is coming from dynamodb-local, not the cli. Also, removing the credentials from
Further, accessing dynamodb-local with different credentials (different AWS account ids I am guessing) gives me different "namespaces" of sorts. I can only list my dynamodb-local table using the aws cli if I use the same |
This issue should probably be resolved as a duplicate of #5584 That issue explains a functional workaround in the latest version of the terraform aws provider. |
Resolved as a duplicate of #5584 |
Historically, we have treated endpoint customization as an optional enhancement when adding service clients to the provider. Over time, the necessity of service endpoint customization has changed including: * FIPS 140-2 compliant endpoints * AWS C2S and SC2S potential usage * AWS Snowball potential usage * Local testing solutions such as LocalStack * Rare incorrect default endpoint information provided by the AWS Go SDK This change enables all existing service clients to support endpoint customization and going forward we can include this support by default. If the AWS Go SDK provides a better customization method in the future or defines environment variable support, we can revisit this in the future. We may also choose to further optimize endpoint handling via new provider configurations (e.g. use all known FIPS 140-2 endpoints). Endpoint service naming is based on existing configuration. Where we do not have a prior configuration, we opt for using the AWS CLI service naming minus any hyphens. We also deprecate our own naming for `kinesis_analytics` and `r53` with `kinesisanalytics` and `route53` respectively for consistency. References: * https://aws.amazon.com/compliance/fips/ * https://aws.amazon.com/federal/us-intelligence-community/ * https://aws.amazon.com/snowball/ * https://docs.aws.amazon.com/cli/latest/index.html * https://localstack.cloud/ * #7735 * #8007 * #7985 * #4967 * #4670 * #3941 * #3888 * #3608
Historically, we have treated endpoint customization as an optional enhancement when adding service clients to the provider. Over time, the necessity of service endpoint customization has changed including: * FIPS 140-2 compliant endpoints * AWS C2S and SC2S potential usage * AWS Snowball potential usage * Local testing solutions such as LocalStack * Rare incorrect default endpoint information provided by the AWS Go SDK This change enables all existing service clients to support endpoint customization and going forward we can include this support by default. If the AWS Go SDK provides a better customization method in the future or defines environment variable support, we can revisit this in the future. We may also choose to further optimize endpoint handling via new provider configurations (e.g. use all known FIPS 140-2 endpoints). Endpoint service naming is based on existing configuration. Where we do not have a prior configuration, we opt for using the AWS CLI service naming minus any hyphens. We also deprecate our own naming for `kinesis_analytics` and `r53` with `kinesisanalytics` and `route53` respectively for consistency. References: * https://aws.amazon.com/compliance/fips/ * https://aws.amazon.com/federal/us-intelligence-community/ * https://aws.amazon.com/snowball/ * https://docs.aws.amazon.com/cli/latest/index.html * https://localstack.cloud/ * hashicorp#7735 * hashicorp#8007 * hashicorp#7985 * hashicorp#4967 * hashicorp#4670 * hashicorp#3941 * hashicorp#3888 * hashicorp#3608
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! |
Hi there,
Terraform Version
Affected Resource(s)
Everything
Terraform Configuration Files
OR
Debug Output
https://gist.github.com/j-groeneveld/b0af35f4f7ab518bbb8cd413b3281e3e
OR
https://gist.github.com/j-groeneveld/43aa1df229e50ef8e06e64028351f2a9
Expected Behavior
Terraform ignores missing credentials and uses the local Dynamo DB endpoint
http://localhost:4569
.Actual Behavior
Terraform complains about
invalid
orincorrect
credentials.Steps to Reproduce
terraform plan
References
Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:
DescribeTimeToLive
andListTagsOfResource
which should be fixed with recent localstack PR #599.I have seen multiple examples of missing or bogus credentials for the aws provider. Perhaps credentials are now required in a new Terraform release but I haven't seen anything explicitly addressing this change in requirement.
The text was updated successfully, but these errors were encountered: