Creating and updating Route53 in another account?

[Turbo Fredriksson]

I've been splitting up my environment from everything in one account (the root/billing account) to individual

accounts for each of my environments.

Thanx to people here, I've been using "terraform_remote_state" to "export and import" the values between

the different parts. Works marvellously!

I've successfully created my "base/core" environment. That's the one with my authentication/authorization,

my Lambda functions, RDS instances, ElastiCache, SNS, SQS and all my Route53 zones.

But now I'm creating my test environment in another account. It needs to create a zone of it's own. And I

need to associate that zone with the VPCs in the other environments. It's this environments reverse

zone, so all instances in all VPCs need to be able to reverse lookup it's instances.

I'm seeing two solutions to this:

    1. I create the zone in this account.

    2. I create it in the "base/core" account.

It seems that TF is creating the zone in this account (point one). I'd prefer to create it in the "base/core" account,

that way I have all of the zones in one place, but I'm not at all "married" to the idea.

But either way, the problem I'm having is to associate VPCs in another ("remote" or "foreign" ?) account with this

zone.

     * aws_route53_zone_association.test2core-jenkins: NotAuthorizedException: The VPC: vpc-aabbccdd has not authorized to associate with your hosted zone.

    * aws_route53_record.test-fc2: AccessDenied: User: arn:aws:iam::ACCOUNT_ID_TEST_ENV:user/turbo is not authorized to access this resource

That is, the 'provider' I'm using in this directory/environment don't have access to associate a foreign VPC

with the zone created in this account nor updating the "main" (forward) zone in the "base/core" account.

For S3 I "simply" added a policy on the bucket(s) to allow access from a foreign account. But it seems you

can't do that for Route53.

    http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/access-control-overview.html#access-control-manage-access-intro

    Resource-Based Policies

    Other services, such as Amazon S3, also support attaching permissions policies to resources. For example,

    you can attach a policy to an S3 bucket to manage access permissions to that bucket. Amazon Route 53

    doesn't support attaching policies to resources.

They talk about creating an IAM role for this, but I can I select an IAM role to use just for "one" job (or for some

resources), not all of it in TF?

There is a "assume_role" for the AWS provider and I thought about that before I started - have an account in

the "root/billing" account and a role with appropriate access to the "sub accounts" but couldn't get that to work

properly.

But I'm guessing that would be use for ALL resources anyway, not just for the Route53 ones, right?

Am I possibly overthinking this? Any suggestions on how to solve this?

PS. I seem to have the exact same problem with VPC peering connections, but that might be a discussion for

       another day.

[Andrew Hodgson]

Hi,

You need to peer the VPCs in order to associate the Route53 zone from one VPC to another, so probably worth getting the VPC peering sorted first.

Andrew.

Sent from my iPhone

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/terraform/issues
IRC: #terraform-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Terraform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to terraform-too...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/terraform-tool/6f027f23-2c1d-4ed8-8cd9-8d77a14e5799%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Turbo Fredriksson]

On 5 Mar 2017, at 13:14, Andrew Hodgson <and...@hodgsonfamily.org> wrote:

> You need to peer the VPCs in order to associate the Route53 zone from one VPC to another, so probably worth getting the VPC peering sorted first.

Ok, thanx.