How to skip all aws provider credentials checks

Terraform Providers AWS
1

I’m using a module which creates kubernetes and aws resources. There’s a flag skipping the aws resources creation which I’m using. All aws resources have count 0. Thus in a way I don’t need an aws provider. If I remove it terraform complains it’s required. But if I leave the provider then it complains:

│ Please see Terraform Registry
│ for more information about providing credentials.
│
│ Error: failed to refresh cached credentials, no EC2 IMDS role found, operation error ec2imds: GetMetadata, access disabled to EC2 IMDS via client option, or
│ “AWS_EC2_METADATA_DISABLED” environment variable

This is an example explaining the code I’m using:

provider "aws" {
  skip_credentials_validation = true
  skip_metadata_api_check     = true
  skip_region_validation      = true
  skip_requesting_account_id  = true
}
resource "aws_s3_bucket" "disabled"{
    count = 0
    bucket = "hello-world"
}

You can reproduce the issue by calling:

docker run --rm -it -w $PWD -v $PWD:$PWD  --platform=linux/amd64 hashicorp/terraform:1.9.8 init
docker run --rm -it -w $PWD -v $PWD:$PWD  --platform=linux/amd64 hashicorp/terraform:1.9.8 plan

Is there something I could do to mock it? I found the mock providers but they can’t be used in this context right (Tests - Provider Mocking | Terraform | HashiCorp Developer) ?

2

I believe this will work as desired as long as a profile is configured (even without valid credentials). For example, either set AWS_PROFILE or use the profile attribute.

provider "aws" {
  skip_credentials_validation = true
  skip_metadata_api_check     = true
  skip_region_validation      = true
  skip_requesting_account_id  = true

  profile = "something-that-exists"
}

resource "aws_s3_bucket" "disabled" {
  count  = 0
  bucket = "hello-world"
}

% echo $AWS_PROFILE # verify nothing else is set in the environment

% terraform plan

No changes. Your infrastructure matches the configuration.

If necessary you could mock out the config and credentials files instead of relying on these to be present in the standard location the AWS SDK expects (~/.aws):

3

The same is true for setting dummy access/secret keys in the provider config - though I’m not sure this translates as well to the contexts in which you actually need to use the AWS provider.

provider "aws" {
  skip_credentials_validation = true
  skip_metadata_api_check     = true
  skip_region_validation      = true
  skip_requesting_account_id  = true

  access_key = "foo"
  secret_key = "bar"
}

resource "aws_s3_bucket" "disabled" {
  count  = 0
  bucket = "hello-world"
}

In short, the provider expects to have some credential source to try (access key, profile, assume role block, etc.), even if eventually all validation of those credentials are skipped.

4

That did it thanks. I’ve not tried with the aws_profile part. Yes no issue that the provider is 100% broken for AWS