Provider error while trying to configure terragrunt in Atlantis CI

[gruntwork-support]

This message was extracted from a discussion that originally took place in Gruntwork Community Slack. Names and URLs have been removed where appropriate

From a customer

Good morning. A basic question, sorry. I get errors using some of your account-baseline modules, due to an aws provider block embedded in the code that does not have any profile information. I assume the credentials should be taken from the root module (where the profile is defined) but it seems this doesn't happen. How would you expect me to pass the right credentials to that child module?

╷
│ Error: error configuring Terraform AWS Provider: no valid credential sources for Terraform AWS Provider found.
│
│ Please see https://registry.terraform.io/providers/hashicorp/aws
│ for more information about providing credentials.
│
│ Error: NoCredentialProviders: no valid providers in chain. Deprecated.
│ 	For verbose messaging see aws.Config.CredentialsChainVerboseErrors
│
│
│   with module.account-baseline-app.module.config.provider["http://registry.terraform.io/hashicorp/aws"].seed,
│   on .terraform/modules/account-baseline-app.config/modules/aws-config-multi-region/main.tf line 25, in provider "aws":
│   25: provider "aws" {

In your module repo: https://github.com/gruntwork-io/terraform-aws-security/blob/master/modules/aws-config-multi-region/main.tf

# Set up a seed provider to query for the list of available regions
provider "aws" {
  alias = "seed"

  region = var.seed_region
}

I am a bit confused since from the documentation it looks like no provider should be defined in a module:

Each resource in the configuration must be associated with one provider configuration. Provider configurations, unlike most other concepts in Terraform, are global to an entire Terraform configuration and can be shared across module boundaries. Provider configurations can be defined only in a root Terraform module.
A module intended to be called by one or more other modules must not contain any provider blocks.

[gruntwork-support]

From a grunt

Ah so with our Landing Zone modules, because there are resources that need to be deployed in every region, we need to define the providers inside the modules so that the user doesn’t have the burden of defining R providers, one for each region.

This is indeed an anti-pattern according to terraform, and we are working on refactoring the multi-region approach to not need this (which is now possible thanks to new features in terraform 0.15).

In general, we recommend using an external tool that handles the AWS credentials and feeds it to the CLI via environment variables (e.g., aws-vault).

If you do wish to use the credentials file with profiles, you should be able to make it work if you set the AWS_PROFILE environment variable

BTW, feel free to ask basic questions as well! It's perfectly reasonable. We're working on a way to make it easier to find answers.

[gruntwork-support]

From a customer

Thanks 🙂

I thought about passing env variables, including profile, but since I run terragrunt in docker locally, I need to find a way, if possible, to do it automatically using what has already been defined in the code as terragrunt variable. Each project has it's own credential's profile and it would be tedious to add manually another parameter to the docker run command.

Since this is a temporary setup, before moving to the Atlantis pipeline, do you know if I will have the same issue using cross account roles? if so this means it will be very hard to use your modules in the pipeline. We have removed all key credentials from the pipeline and centralized the access from a single account using only roles.
Currently, this is how I define the aws provider in each project running in Atlantis:

provider "aws" {
  allowed_account_ids = ["xxxxxx"]
  region = "eu-central-1"
  assume_role {
    role_arn    = "arn:aws:iam::xxxxxxxx:role/AwinTerraformAtlantisInfra"
  }
}

Will this cause the same problem or using a role will create env variables that child module will use?
Thanks!

[gruntwork-support]

From a grunt

There are two options here:

• One is to configure a custom workflow in Atlantis that uses aws-auth to assume the right role for each module. The idea here is to map the directory tree to IAM roles to assume, and in the Atlantis workflow, you would assume the right role by introspecting where you are running from.
• Alternatively, you can consider using terragrunt with Atlantis, and have terragrunt assume the IAM role. This can be done by configuring the iam_role configuration parameter in the terragrunt.hcl: https://terragrunt.gruntwork.io/docs/reference/config-blocks-and-attributes/#iam_role

[gruntwork-support]

From a customer

Yes, I have set up terragrunt custom workflow but I haven't really tested yet. I didn't know about the variable, thanks. I will have a look at the first option too. Not every project runs with terragrunt.