Skip to content
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

Skipping the need for AWS creds seems to have broken in 3.51.0 #20287

Closed
alikhajeh1 opened this issue Jul 23, 2021 · 6 comments · Fixed by #20357
Closed

Skipping the need for AWS creds seems to have broken in 3.51.0 #20287

alikhajeh1 opened this issue Jul 23, 2021 · 6 comments · Fixed by #20357
Labels
bug Addresses a defect in current functionality. regression Pertains to a degraded workflow resulting from an upstream patch or internal enhancement. service/ec2 Issues and PRs that pertain to the ec2 service.
Milestone

Comments

@alikhajeh1
Copy link

I think prior to this change, the skip_credentials_validation=true and skip_requesting_account_id=true worked as expected. However, in 3.51.0, I'm seeing "error reading Instance Launch Template Id Tag: AuthFailure: AWS was not able to validate the provided access credentials" even when launch_template is not used (see following before/after examples). I was under the assumption that the 5 different skip_ arguments could be used to turn-off the need for AWS creds during testing (we have integration tests in https://github.com/infracost/infracost that started to fail this morning).

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform CLI and Terraform AWS Provider Version

Terraform v1.0.2 on darwin_amd64

  • provider registry.terraform.io/hashicorp/aws v3.50.0
  • provider registry.terraform.io/hashicorp/cloudinit v2.2.0
  • provider registry.terraform.io/hashicorp/kubernetes v2.3.2
  • provider registry.terraform.io/hashicorp/local v2.1.0
  • provider registry.terraform.io/hashicorp/random v3.1.0
  • provider registry.terraform.io/terraform-aws-modules/http v2.4.1

Affected Resource(s)

  • aws_instance

Terraform Configuration Files

3.50.0 behavior

With this example, terraform plan worked ok:


terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = "3.50.0"
    }
  }
}

provider "aws" {
  region                      = "us-east-1"
  skip_credentials_validation = true
  skip_requesting_account_id  = true
  access_key                  = "mock_access_key"
  secret_key                  = "mock_secret_key"
}

resource "aws_instance" "web_app" {
  ami           = "ami-12312312"
  instance_type = "m5.4xlarge"
}

3.51.0 behavior, where terraform plan fails

terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = "3.51.0"
    }
  }
}

provider "aws" {
  region                      = "us-east-1"
  skip_credentials_validation = true
  skip_requesting_account_id  = true
  access_key                  = "mock_access_key"
  secret_key                  = "mock_secret_key"
}

resource "aws_instance" "web_app" {
  ami           = "ami-12312312"
  instance_type = "m5.4xlarge"
}

terraform plan produces this error:

│ Error: 1 error occurred:
│ 	* error reading Instance Launch Template Id Tag: AuthFailure: AWS was not able to validate the provided access credentials
│ 	status code: 401, request id: 123123-123123-123123-123-123123
│   with aws_instance.web_app,
│   on main.tf line 18, in resource "aws_instance" "web_app":
│   18: resource "aws_instance" "web_app" {

Expected Behavior

terraform plan should have worked as it did in 3.50.0

Actual Behavior

terraform plan failed with "error reading Instance Launch Template Id Tag: AuthFailure: AWS was not able to validate the provided access credentials".

Steps to Reproduce

  1. Create a new TF project with main.tf and the previously mentioned examples.
  2. Run terraform init followed by terraform apply and notice how it works ok on 3.50.0 but not on 3.51.0

Important Factoids

References

@github-actions github-actions bot added needs-triage Waiting for first response or review from a maintainer. service/ec2 Issues and PRs that pertain to the ec2 service. labels Jul 23, 2021
alikhajeh1 added a commit to infracost/infracost that referenced this issue Jul 23, 2021
@ewbankkit ewbankkit added bug Addresses a defect in current functionality. regression Pertains to a degraded workflow resulting from an upstream patch or internal enhancement. and removed needs-triage Waiting for first response or review from a maintainer. labels Jul 23, 2021
alikhajeh1 added a commit to infracost/infracost that referenced this issue Jul 23, 2021
alikhajeh1 added a commit to infracost/infracost that referenced this issue Jul 23, 2021
alikhajeh1 added a commit to infracost/infracost that referenced this issue Jul 23, 2021
It broke due to hashicorp/terraform-provider-aws#20287

Locking it in the test helper as well as the aws_instance is needed to ensure that running that specific test in dev works ok too.
alikhajeh1 added a commit to infracost/infracost that referenced this issue Jul 23, 2021
It broke due to hashicorp/terraform-provider-aws#20287

Locking it in the test helper as well as the aws_instance is needed to ensure that running that specific test in dev works ok too.
alikhajeh1 added a commit to infracost/example-terraform that referenced this issue Jul 26, 2021
@gordonbondon
Copy link
Contributor

Sorry, I did not expect my change to cause this. Currently reading instance tags is the only way to find out whether a launch template was used for its creation.

This is used only in CustomizedDiff and Read, and I would not expect these to run during terraform plan with an empty state.

Can you please run terraform in trace mode (with TF_LOG=TRACE env) and upload logs somewhere, so we can find out where this is happening?

@alikhajeh1
Copy link
Author

Thanks @gordonbondon - plz see trace_logs.txt for the 3.51.0 behavior, where terraform plan fails example in the GH issue description.

@gordonbondon
Copy link
Contributor

Attempt at fixing this here #20357, please check if it works for you.

@alikhajeh1
Copy link
Author

@gordonbondon thanks! I tested that PR and it works ok with the example in the GH issue description.

@github-actions github-actions bot added this to the v3.53.0 milestone Aug 4, 2021
@github-actions
Copy link

github-actions bot commented Aug 5, 2021

This functionality has been released in v3.53.0 of the Terraform AWS Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!

@github-actions
Copy link

github-actions bot commented Sep 5, 2021

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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 5, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Addresses a defect in current functionality. regression Pertains to a degraded workflow resulting from an upstream patch or internal enhancement. service/ec2 Issues and PRs that pertain to the ec2 service.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants