Setting up a Route53 association with a zone in another account fails

[FransUrbo]

Specifying a provider in the aws_route53_zone_association resource doesn't work [as expected].

Terraform Version

0.8.8

Affected Resource(s)

Please list the resources as a list, for example:

• aws_route53_zone_association

Terraform Configuration Files

provider "aws" {
  region  = "eu-west-1"
  profile = "core"
  alias   = "core"
}

provider "aws" {
  region  = "eu-west-1"
  profile = "test"
}

resource "aws_vpc" "test" {
  # ...
}

resource "aws_instance" "test" {
  # ...
}

resource "aws_route53_zone_association" "test" {
  vpc_id  = "${aws_vpc.test.id}"
  zone_id = "${data.terraform_remote_state.base.zone_id_private}"
  provider      = "aws.core"
}

Steps to Reproduce

1. Create two accounts
2. Setup a aws_vpc in each account
3. Setup an aws_instance in each VPC
4. [possibly setup VPC peering between the VPCs in the two accounts]
5. Setup a Route53 zone in the first account
6. aws_route53_zone_association the VPC in the first account with this zone.
7. Try to aws_route53_zone_association the VPC in the second account with the zone.

[FransUrbo]

I get:

* aws_route53_zone_association.test2core-mgmt: AccessDenied: User: arn:aws:iam::USER_ID:user/turbo is not authorized to perform: route53:AssociateVPCWithHostedZone on resource: arn:aws:route53:::hostedzone/ZONE_ID
        status code: 403, request id: 5e192c68-041d-11e7-90e6-b364fcf332cb        status code: 403, request id: f2e12a23-041b-11e7-abde-378ae1dd8210
* aws_route53_zone_association.test: NotAuthorizedException: The VPC: vpc-0f747a6b has not authorized to associate with your hosted zone.
        status code: 401, request id: 5e184195-041d-11e7-a7d0-2ddfbb551b5a

The data.terraform_remote_state.{base,core} is in the same account, which I specify with the provider aliased as core (same credentials/profile I'm using to create resources in that account).

Thinking about this somewhat, I'm thinking I need two credentials: 1) to update the Route53 zone with the VPC association and 2) (possibly?) one to tell the VPC about this?

[FransUrbo]

http://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html

Note
If you want to associate a VPC that was created by using one AWS account with a private hosted zone that was created by using a different account, the AWS account that created the private hosted zone must first submit a CreateVPCAssociationAuthorization request. Then the account that created the VPC must submit an AssociateVPCWithHostedZone request.

http://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateVPCAssociationAuthorization.html

Authorizes the AWS account that created a specified VPC to submit an AssociateVPCWithHostedZone request to associate the VPC with a specified hosted zone that was created by a different account. To submit a CreateVPCAssociationAuthorization request, you must use the account that created the hosted zone.

[FransUrbo]

So I guess that if provider is set (and differs from the "default"?), then first issue a CreateVPCAssociationAuthorization with that provider, then issue a AssociateVPCWithHostedZone with the "default" provider.

[FransUrbo]

There seems to be more bugs lurking here.

By issuing a create-vpc-association-authorization using the aws command for all VPC IDs in a loop:

aws --profile local_profile --region eu-west-1 route53 create-vpc-association-authorization --vpc VPCRegion=eu-west-1,VPCId=${vpcid} --hosted-zone-id ${hosted_zone}

I then expected this to succeed:

resource "aws_route53_zone_association" "test" {
  vpc_id        = "${aws_vpc.test.id}" # local VPC
  zone_id       = "${data.terraform_remote_state.base.zone_id_private}" # remote zone
  provider      = "aws.core"
}

resource "aws_route53_zone_association" "test2core-mgmt" {
  vpc_id        = "${data.terraform_remote_state.core.management_vpc_id}" # remote VPC
  zone_id       = "${aws_route53_zone.test-rev.id}" # local zone
}

resource "aws_route53_zone_association" "test2core-support" {
  vpc_id        = "${data.terraform_remote_state.core.support_vpc_id}" # remote VPC
  zone_id       = "${aws_route53_zone.test-rev.id}" # local zone
}

resource "aws_route53_zone_association" "test2core-jenkins" {
  vpc_id        = "${data.terraform_remote_state.core.jenkins_vpc_id}" # remote VPC
  zone_id       = "${aws_route53_zone.test-rev.id}" # local zone
}

resource "aws_route53_zone_association" "test2core-access" {
  vpc_id        = "${data.terraform_remote_state.core.access_vpc_id}" # remote VPC
  zone_id       = "${aws_route53_zone.test-rev.id}" # local zone
}

However, it did not. It failed, I had to set a provider entry for each resource, rerun TF, it failed on fewer and I had to do this several time, adding/removing provider entries and eventually I got it to do the associations.

[FransUrbo]

Looking at d6869f6, it's a good start I guess.

However, because the CreateVPCAssociationAuthorization needs to be done slightly before (testing with running the aws shell command to do the same before running Terraform show it's a few seconds!!) running AssociateVPCWithHostedZone, there needs to be a dependency between the aws_route53_vpc_association_authorization and aws_route53_zone_association.

A harder one than depends_on.

[FransUrbo]

Duplicate of #10208.

[opetch]

I've created the following module which by no means solves this issue but provides me with an alternative in the meantime, I hope this is fixed in the future, I might even take a look at the go code myself if I have time.
https://github.com/opetch/terraform-aws-cli-resource

[bevanbennett]

Just as a note... when dealing with cross-account aws_route53_zone_association resources:

• To CREATE the association the resource provider needs to point to the owner of the VPC
  After creation terraform will generate the following error:
  aws_route53_zone_association.allowlocal: AccessDenied: User: arn:aws:iam::111111111111111:user/terraform_user is not authorized to access this resource
  status code: 403, request id: REDACTED
• To VERIFY the association the resource provider needs to be switched to the owner of the ZONE
  This should not effect the ability to run create-vpc-association-authorization, which needs to be executed as the owner of the ZONE. Our current process is:

1. manually run create-vpc-association-authorization from the CLI
2. temporarily edit the aws_route53_zone_association resource to swap provider to the VPC owner
3. Run TF. Ignore the error.
4. Undo the provider swap and verify plan is clean

[Deleted user]

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.