yorinasub17
commented
4 years ago Is that a bug, or the expected behavior? If the latter - why does it behave differently than the plain terraform?
This is sort of expected behavior. Terragrunt uses those parameters to implement internal machinery to autocreate the S3 bucket if it doesn't exist. What you are observing is how terragrunt is setting up its credentials within the binary when calling the AWS API.
With that said, terragrunt should configure its credentials in a way that you can override that with env vars, like terraform. I suspect this routine isn't doing the right thing.
Are there any way how I can enforce picking credentials from the env vars and still keep profile name explicitly set in the backend.tf?
There is a hacky workaround you can do, which is to introduce an env var to disable the hardcoded profile using some conditional logic based on env vars in terragrunt. Something like (in terragrunt):
remote_state {
backend = "s3"
generate = {
path = "backend.tf"
if_exists = "overwrite"
}
config = {
profile = (
get_env("TERRAGRUNT_DISABLE_PROFILE", "false") == "true"
? null
: "my-profile-dev"
)
bucket = "my-terraform-state"
key = "${path_relative_to_include()}/terraform.tfstate"
region = "us-east-1"
encrypt = true
dynamodb_table = "my-lock-table"
}
}With this, any time you set the env var TERRAGRUNT_DISABLE_PROFILE, you can remove that profile line without editing the config.
legal90
tstraley
rhoboat
Hi, terragrunt maintainers! Thank you very much for creating this tool, bringing "DRY" to terraform is a really handy thing! However, I got an issue when I switched my pure terraform-managed infra stack to terragrunt.
The documentation says that terragrunt follows the "standart AWS SDK flow" for the AWS authentication: https://aws.amazon.com/blogs/security/a-new-and-standardized-way-to-manage-credentials-in-the-aws-sdks/
As I understand, at first it should try to use environment variables
AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY(if they are provided) and only after that it should fall back to other methods, such as profile in files~/.aws/configand~/.aws/credentialsProblem description
My S3 backend includes the
profilestatement. Example:In my CI pipeline I don't have any
~/.aws/configand~/.aws/credentials, so the profile is not available. But I haveAWS_ACCESS_KEY_IDandAWS_SECRET_ACCESS_KEYenv variables exported. However, bothterragrunt initandterragrunt planfails with:It seems that
terragruntforcibly tries to use the specified profile name and doesn't use the provided env variables for S3 backend initialization. If I comment-out theprofileline from the backend config, it works fine.Other findings
The most interesting part is that pure terraform works just fine in this case. I can switch to the generated temp dir (inside
.terragrunt-cache/) and runterraform initfor the backend with profile hardcoded (but not-existing in~/.aws/*). Then it uses the credentials from the env var, without a failure, as expected:Questions
Is that a bug, or the expected behavior? If the latter - why does it behave differently than the plain terraform? Are there any way how I can enforce picking credentials from the env vars and still keep profile name explicitly set in the
backend.tf? We still need it for the manual execution from workstations, where aws credentials are defined in a profile in~/.aws/configand~/.aws/credentials.