Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using multiple AWS credentials across modules failing #1461

Closed
jtopper opened this issue Apr 9, 2015 · 5 comments
Closed

Using multiple AWS credentials across modules failing #1461

jtopper opened this issue Apr 9, 2015 · 5 comments
Labels
bug provider/aws waiting-response An issue/pull request is waiting for a response from the community

Comments

@jtopper
Copy link
Contributor

jtopper commented Apr 9, 2015

Following on from my post to #1380 1380

My use case is that I want to use different AWS credentials inside >1 invocation of a module, in order to create resources across multiple Amazon accounts in one run of the tool, and manage ordering between them.

Tested against 166efa1

Reproduction steps:

# test.tf

module "mgmt_vpc" {
    source = "./modules/vpc"
    vpc_cidr = "10.101.0.0/16"
    public_a_cidr  = "10.101.0.0/24"
    private_a_cidr = "10.101.1.0/24"
    public_b_cidr  = "10.101.2.0/24"
    private_b_cidr = "10.101.3.0/24"
    aws_access_key = "${var.aws_access_key_mgmt}"
    aws_secret_key = "${var.aws_secret_key_mgmt}"
    aws_region     = "eu-west-1"
}

module "test_vpc" {
    source = "./modules/vpc"
    vpc_cidr = "10.102.0.0/16"
    public_a_cidr  = "10.102.0.0/24"
    private_a_cidr = "10.102.1.0/24"
    public_b_cidr  = "10.102.2.0/24"
    private_b_cidr = "10.102.3.0/24"
    aws_access_key = "${var.aws_access_key_test}"
    aws_secret_key = "${var.aws_secret_key_test}"
    aws_region     = "eu-west-1"
}
# modules/vpc/module.tf

variable "vpc_cidr"       {}
variable "aws_region"     {}
variable "aws_access_key" {}
variable "aws_secret_key" {}
variable "public_a_cidr"  {}
variable "public_b_cidr"  {}
variable "private_a_cidr" {}
variable "private_b_cidr" {}

provider "aws" {
    access_key = "${var.aws_access_key}"
    secret_key = "${var.aws_secret_key}"
    region     = "${var.aws_region}"
}

resource "aws_vpc" "main" {
    cidr_block = "${var.vpc_cidr}"
}

resource "aws_subnet" "public_a" {
    vpc_id            = "${aws_vpc.main.id}"
    availability_zone = "${var.aws_region}a"
    cidr_block        = "${var.public_a_cidr}"
}

resource "aws_subnet" "private_a" {
    vpc_id            = "${aws_vpc.main.id}"
    availability_zone = "${var.aws_region}a"
    cidr_block        = "${var.private_a_cidr}"
}

resource "aws_subnet" "public_b" {
    vpc_id            = "${aws_vpc.main.id}"
    availability_zone = "${var.aws_region}b"
    cidr_block        = "${var.public_b_cidr}"
}

resource "aws_subnet" "private_b" {
    vpc_id            = "${aws_vpc.main.id}"
    availability_zone = "${var.aws_region}b"
    cidr_block        = "${var.private_b_cidr}"
}

terraform plan all looks fine. On a terraform apply, it blows up with this output: https://gist.github.com/jtopper/6a6a9082ed4968c8c30a

@rhartkopf
Copy link

I can verify this issue with Terraform v0.4.1. My config:

variable "access_key" {}
variable "secret_key" {}
variable "region" {
  default = "us-west-2"
}
provider "aws" {
  access_key = "${var.access_key}"
  secret_key = "${var.secret_key}"
  region = "${var.region}"
}

resource "aws_vpc" "main" {
  cidr_block = "10.84.0.0/16"
  tags {
    Name = "wyse-ccm-aws-us1"
  }
}

resource "aws_subnet" "vpn-inside" {
  vpc_id = "${aws_vpc.main.id}"
  cidr_block = "10.84.255.16/28"
  availability_zone = "${var.region}a"
  tags {
    Name = "${aws_vpc.main.tags.Name}-vpn-inside"
  }
}

resource "aws_subnet" "db" {
  vpc_id = "${aws_vpc.main.id}"
  cidr_block = "10.84.13.0/24"
  availability_zone = "${var.region}a"
  tags {
    Name = "${aws_vpc.main.tags.Name}-db"
  }
}

Output:

aws_vpc.main: Creating...
  cidr_block:                "" => "10.84.0.0/16"
  default_network_acl_id:    "" => "<computed>"
  default_security_group_id: "" => "<computed>"
  enable_dns_hostnames:      "" => "<computed>"
  enable_dns_support:        "" => "<computed>"
  main_route_table_id:       "" => "<computed>"
  tags.#:                    "" => "1"
  tags.Name:                 "" => "wyse-ccm-aws-us1"
aws_vpc.main: Creation complete
aws_subnet.vpn-inside: Creating...
  availability_zone:       "" => "us-west-2a"
  cidr_block:              "" => "10.84.255.16/28"
  map_public_ip_on_launch: "" => "0"
  tags.#:                  "" => "1"
  tags.Name:               "" => "wyse-ccm-aws-us1-vpn-inside"
  vpc_id:                  "" => "vpc-79de651c"
aws_subnet.db: Creating...
  availability_zone:       "" => "us-west-2a"
  cidr_block:              "" => "10.84.13.0/24"
  map_public_ip_on_launch: "" => "0"
  tags.#:                  "" => "1"
  tags.Name:               "" => "wyse-ccm-aws-us1-db"
  vpc_id:                  "" => "vpc-79de651c"
aws_subnet.vpn-inside: Error: 1 error(s) occurred:

* Error creating subnet: could not find credentials configuration.
aws_subnet.db: Error: 1 error(s) occurred:

* Error creating subnet: could not find credentials configuration.
rror applying plan:

2 error(s) occurred:

* 1 error(s) occurred:

* 1 error(s) occurred:

* Error creating subnet: could not find credentials configuration.
* 1 error(s) occurred:

* 1 error(s) occurred:

* Error creating subnet: could not find credentials configuration.

Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.

Any help is appreciated. Thanks!

@rhartkopf
Copy link

Nevermind, fixed in v0.4.2 / #1470.

Thanks!

@catsby
Copy link
Member

catsby commented Apr 13, 2015

@jtopper can you confirm this is fixed in 0.4.2 (or master)?

@catsby catsby added bug waiting-response An issue/pull request is waiting for a response from the community labels Apr 13, 2015
@jtopper
Copy link
Contributor Author

jtopper commented Apr 13, 2015

Looks good to me, thanks!

@jtopper jtopper closed this as completed Apr 13, 2015
@ghost
Copy link

ghost commented May 3, 2020

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@ghost ghost locked and limited conversation to collaborators May 3, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug provider/aws waiting-response An issue/pull request is waiting for a response from the community
Projects
None yet
Development

No branches or pull requests

3 participants