Imagine following situation:
provider "aws" {
access_key = "dadadadadadadadadada"
secret_key = "abcdefghijklmnopqrstuvwxyz0123456789"
region = "eu-west-1"
}
resource "aws_vpc" "default" {
cidr_block = "10.12.0.0/16"
}
module "sg_web" {
source = "github.com/terraform-community-modules/tf_aws_sg/sg_web"
security_group_name = "bollocks-web"
aws_access_key = "${provider.aws.access_key}"
aws_secret_key = "${provider.aws.secret_key}"
aws_region = "${provider.aws.region}"
vpc_id = "${aws_vpc.default.id}"
source_cidr_block = "0.0.0.0/0"
}
Error configuring: 1 error(s) occurred:
* Resource 'provider.aws' not found for variable 'provider.aws.access_key'
The use case basically forces me to turn access_key, secret_key, region into variables which could be quite inconvenient especially when credentials are loaded from a config file or ENV vars (so it's basically impossible to get these easily into TF variables).
Totally agreed that we should do this. This is made a bit trickier by #451.
Merged #4068 in here, which adds the request for computed attributes on providers as well, specifically AWS AccountID.
Ran into this when wishing for the ability to discover the AWS region that was loaded automatically from the .aws/credentials file.
Sorry for the long silence here!
Since this was originally opened we've added the concept of data sources, with this use-case being one of the things they are intended to solve.
Instead of exposing directly the provider arguments, we can instead provide data sources to explicitly expose certain aspects of provider configuration (some of which might be computed based on other attributes or environment variables) with explicit configuration, such as with the aws_caller_identity data source that gives access to information about the AWS IAM principal that Terraform is acting as.
This doesn't directly address all of the use-cases shown in @radeksimko's original examples here, but it gives us the building block necessary to do so. If people have additional use-cases they'd like to support around getting data from the provider I'd encourage opening new issues for these so we can discuss each on its own merits and implications.
Since we have the building block in place for this now, I'm going to close this as part of our effort to close out some older issues that have been neglected.
My use case:
provider "aws" {
region = "us-east-1"
version = ">= 2.0"
}
provider "aws" {
alias = "eu1"
region = "eu-west-1"
version = ">= 2.0"
}
Configuring global dynamodb tables:
resource "aws_dynamodb_global_table" "main" {
// ...
replica {
region_name = providers.aws.region
}
replica {
region_name = providers.aws.eu1.region
}
}
But I already see the issue with aliases and provider attributes.
Hi @zygimantas,
You can get the current region of a provider using the aws_region data source:
data "aws_region" "default" {}
data "aws_region" "eu1" {
provider = aws.eu1
}
resource "aws_dynamodb_global_table" "main" {
// ...
replica {
region_name = data.aws_region.default.name
}
replica {
region_name = data.aws_region.eu1.name
}
}
As I mentioned in my previous comment, we'd prefer to discuss any additional use-cases in new, separate issues, because this is an old, closed issue and we aren't always able to follow discussion on closed issues. Any new use-case here should be filed as a request with the provider it relates to, since it will be met by adding a new data source to that provider, not by making changes to Terraform Core.
Most helpful comment
Ran into this when wishing for the ability to discover the AWS region that was loaded automatically from the
.aws/credentialsfile.