I am teaching myself to terraform. I have been following the official tutorials and I was stuck for a week.
I succeeded in ‘install terraform’, then I proceed to ‘build infrastructure’. I got this error:
Error: configuring Terraform AWS Provider: validating provider credentials: retrieving caller identity from STS: operation error STS: GetCallerIdentity, https response error StatusCode: 0, RequestID: , request send failed, Post “https://sts.ap-northeast-1.amazonaws.com/”: dial tcp: lookup sts.ap-northeast-1.amazonaws.com on 192.168.2.1:53: server misbehaving
Then I ran the command ‘aws sts get-caller-identity’. I typed ‘terraform plan’ it was a go.
Then I typed ‘terraform apply’ it was a no. Then I typed ‘aws sts get-caller-identity’ and ‘terraform apply’ it was a go. However, it has been creating my ec2 for 18 hours and still going on.
I have also followed 3 youtube tutorials for this step, they are slightly different approaches, but I just couldn’t get anyone to work.
I use a mac air and I am working from a home wifi.
This error message suggests that your system’s DNS server is returning a response that Terraform cannot interpret.
I’ve not seen this error message before so I’m not sure what to suggest to debug it. It might help to try temporarily using a different DNS server and see if that works; if it does then that would confirm that it’s the DNS server’s behavior causing this error and then we can try to figure out what is special about that server that is causing problems for Terraform.
It’s interesting to note that this error is from the hashicorp/aws provider rather than from Terraform Core, and so unless you have some special Terraform CLI configuration you’ve presumably already successfully downloaded that provider using terraform init, and so Terraform CLI itself was apparently able to use your DNS server without problems. I’m not sure why this particular lookup inside the AWS provider would behave differently.
Is 192.168.2.1 a DNS server you would expect to see used for this request, or would you have expected a different DNS server in your current configuration?
i have the same error AWS Provider: validating provider credentials: retrieving caller identity from STS: operation error STS: GetCallerIdentity request status 0. I could terraform init fine but plan errored with the above and when i do apply it times out with the above after 25 tries or when i ctrl-c out of it it gives me the plug in failed with GRPCProvider.ConfigureProvider Call
provider.stdio: received EOF, stopping recv loop: err="rpc error: code = Unavailable
desc = error reading from server: EOF"
i am in aws gov cloud and have reauthenticated with our SAML and also made sure that i could make simple calls to aws with creds which were successful, i reinstalled it i was able to do this yesterday on company VPN, I even recloned and rechecked out the branch. My colleague can get an apply output i have no idea what happend.
192.168.2.1 is my home router’s DNS, I guess there is nothing special about it.
The weird thing I feel is that ‘terraform plan’ produces an error. But if I run ‘aws sts get-caller-identity’ right before ‘terraform plan’, it works, every time.
Also, since I copies the exact code from the official tutorial, the “ami-830c94e3” may be incorrect? maybe I should try a tutorial not creating an EC2 instance.
AWS AMI IDs have two different lengths, because Amazon changed the ID format in EC2 a few years ago to increase the size of the number space. Older AMIs that were created before that change can still have IDs in the old format.
However, I think the AMI ID is not relevant for this error because the AWS provider apparently cannot even complete the authentication step, so it will not reach the step where it would send any values from your resource blocks to the EC2 API.
I would still suggest trying a different DNS server temporarily to see if the DNS server behavior is the cause of the problem, as the error message suggests. If we can confirm that then we can try to understand what your server is doing differently to normal and why that might cause a problem for the AWS provider, even though the AWS CLI apparently works.