Assert failing if you are using local configuration for testing (i.e: localstack locally)

[ffernandezcast]

I'm using localstack locally to test my terraform code:

This is my provider configuration

provider "aws" {
  access_key                  = "mock_access_key"
  region                      = "eu-west-2"
  s3_force_path_style         = true
  secret_key                  = "mock_secret_key"
  skip_credentials_validation = true
  skip_metadata_api_check     = true
  skip_requesting_account_id  = true

  endpoints {
    apigateway     = "http://localhost:4567"
    cloudformation = "http://localhost:4581"
    cloudwatch     = "http://localhost:4582"
    dynamodb       = "http://localhost:4569"
    es             = "http://localhost:4578"
    firehose       = "http://localhost:4573"
    iam            = "http://localhost:4593"
    kinesis        = "http://localhost:4568"
    lambda         = "http://localhost:4574"
    route53        = "http://localhost:4580"
    redshift       = "http://localhost:4577"
    s3             = "http://localhost:4572"
    secretsmanager = "http://localhost:4584"
    ses            = "http://localhost:4579"
    sns            = "http://localhost:4575"
    sqs            = "http://localhost:4576"
    ssm            = "http://localhost:4583"
    stepfunctions  = "http://localhost:4585"
    sts            = "http://localhost:4592"
  }
}

I.E: I'm using aws.AssertS3BucketExists method

But I constantly receiving an error about the credentials (In my case I have fake one and receive 403). This mean the aws import dependency is not using the terraform provider configuration and continue using the default aws cli config credentials.

I have checked the code and I realized the module https://github.com/gruntwork-io/terratest/blob/master/modules/aws/auth.go doesn't have the option to use local custom services endpoint

[jmoghisi]

PR #1211 and #1264 use custom env variables to drive the configuration of the AWS client. Whilst these are great contributions, they are specific to a particular provider configuration. For example, if above HCL configuration used assume_role for auth or a http_proxy then neither PR would work since the AWS client configuration would deviate from the terraform module.

Instead should the provider HCL for the module under test be parsed using hclparse to derive the AWS client configuration? i.e. the list of endpoints to configure the AWS client with would be derived from the provider HCL configuration. It would be used to derive other client settings too such as Auth, HTTP Proxy, etc.

This approach may have some other benefits:

• keep the provider HCL as the source of truth.
• could be extended to support other providers such as GCP / not be AWS specific.
• not require duplicating the configuration in env vars.
• more extensible as it would not require adding more env vars for each customization (of each provider).
• prevent tests deviating from provider HCL under test.

@denis256 / @brikis98 I'm happy to work on this and raise a PR if you agree this would be a better approach.

[james00012]

inactive for the past 2 years. Closing this issue as there's no more interest. Feel free to reopen this if we still need this.