Feature Request: Add support for CreateVPCAssociationAuthorization AWS API #384
Comments
hashibot
added
enhancement
|
@RyanJarv I don't know if you've looked here since the provider split. Let me know if you want to help get a fix together for this. |
|
Should only require the creation of an authorization resource against a specific zone, with parameter inputs for source vpc id and source vpc region. Would love to see this implemented. EDIT: Just realised how difficult this could end up being to implement. It seems to me that the Zone owner account has to create an authorisation, the VPC owner account then has to perform the association, but then subsequently does not have permission to describe the association. If you manually create an authorisation and then use terraform to create the association; the association will be created but the apply will fail and all subsequent plans and applies will fail because in order to refresh the resource, the zone must be described, but permission is not available to do so. |
|
@josephholsten Hey sorry, yeah that would be awesome I've just been pretty busy and not sure when I'll have time to get back to this. Worth mentioning this actually does work currently for creating authorizations but like @Zordrak pointed out the association resource can't describe route53 zone and fails currently. This is talked about a bit more at If we don't mind the association and authorization resource working together currently this could probably be merged with some added docs and a note on the issue. |
|
Is anyone still interested in trying to get this feature out? |
|
Went ahead and cleaned this up a bit and added documentation in #2005. Last PR was before the repo split. |
|
Awesome! this will be very useful! Thanks for the hard work! |
|
Agreed. Fixing this would be very helpful. In the meantime I have used the AWS CLI to do the Route53 VPC association from a VPC sitting in one AWS account to a Route53 Hosted Zone sitting on different AWS account. Here are the steps: https://aws.amazon.com/premiumsupport/knowledge-center/private-hosted-zone-different-account/ |
|
There's a problem with the way the Route 53 API works when creating the association between a hosted zone created in one AWS account and a VPC created in a second AWS account. This Terraform code (following the steps here, and based on this code) provider "aws" {
// Zone creator's credentials.
}
provider "aws" {
alias = "bar"
// VPC creator's credentials.
access_key = "XXXXXXXXXXXXXXXXXXXX"
secret_key = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
resource "aws_vpc" "foo" {
cidr_block = "10.6.0.0/16"
enable_dns_hostnames = true
enable_dns_support = true
}
resource "aws_route53_zone" "foo" {
name = "example.com"
vpc_id = "${aws_vpc.foo.id}"
}
resource "aws_vpc" "bar" {
provider = "aws.bar"
cidr_block = "10.7.0.0/16"
enable_dns_hostnames = true
enable_dns_support = true
}
resource "aws_route53_zone_association_authorization" "foo" {
zone_id = "${aws_route53_zone.foo.id}"
vpc_id = "${aws_vpc.bar.id}"
}
resource "aws_route53_zone_association" "bar" {
provider = "aws.bar"
zone_id = "${aws_route53_zone_association_authorization.foo.zone_id}"
vpc_id = "${aws_vpc.bar.id}"
}should create VPCs in two different AWS accounts and associate them both with a hosted zone created in the first AWS account. In fact it does exactly that, but an error is reported: and subsequent The problem is with the code that run under the credentials of the associator (i.e. NOT the AWS account that created the hosted zone) that is reading the state of the zone association https://github.com/terraform-providers/terraform-provider-aws/blob/17a320b90f85a7e98e19f2b405d0526b640f4880/aws/resource_aws_route53_zone_association.go#L94-L95 |
|
@ewbankkit Yeah, this is an issue with aws_route53_zone_association and is documented in my PR at https://github.com/terraform-providers/terraform-provider-aws/pull/2005/files#diff-f048cbf19e0fc509e5df5d05254f5bdbR13. This was also the reason I held off on making that PR for a bit, some people where asking for it regardless, so short of a better fix I added a note on the issue (although looking at it now this should be added to the The core of the issue is that you can not enumerate Route53 zones attached to a VPC, so the aws_route53_zone_association resource checks to see if the VPC is attached by using GetHostedZone on the Route53 zone which the account that needs to do the association doesn't usually have access to. |
|
@RyanJarv If it's not a TF coding anti-pattern / no-no I'd be happy with having to specifiy two providers to a resource. I'd expect the authorisation to be created at the same time as the association as the example above does, so the second provider should be available anyway. A second idea I've had, but the answer doesn't seem obvious from the AssociateVPCWithHostedZone API reference, What error/response do you get when trying to associate an already associated VPC to a zone? Is the response suitable to be used in determining whether the VPC is already associated, rather than having to get the list of vpcs from the zone? excuse my naivety if these are obvious no's! 😄 Cheers, |
|
@JoshiiSinfield If I'm reading the above correctly then @ewbankkit has already tried doing this (hence the two From using the aws cli, from memory, I think you do get a different message when the zone has already been associated. |
|
@psyvision Something like this (assuming use of the rest of @ewbankkit's code):: That way you're explicitly giving the zone_association access to the R53 zone to call GetHostedZones. |
|
I think I remember considering something like that at one point,
unsure if I just didn’t think it was possible or wasn’t sure how to
implement it.
If it’s doable though seems like a pretty good work around. But I might
need to take a step back from this PR and would be great if some one is
able to take the lead here.
On Mon, Mar 12, 2018, at 4:19 AM, Josh Sinfiel
@psyvision[1]
Yes he has, except I was on about passing a second provider into the
zone_association resource.>
Something like this (assuming use of the rest of
@ewbankkit[2]'s code)::
resource "aws_route53_zone_association" "bar" { provider = "aws.bar"
r53_zone_provider = "aws" zone_id =
"${aws_route53_zone_association_authorization.foo.zone_id}" vpc_id =
"${aws_vpc.bar.id}" }
> — You are receiving this because you were mentioned. Reply to this
email directly, view it on GitHub[3], or mute the thread[4].>
|
|
Hey all, haven't got around to looking into this again yet but did want to leave this here, turn's out the API issue thing is also a bit of a security problem. I reported this to AWS security about two years ago when I was working on this originally but am unsure of any timeline on fixing it. https://blog.ryanjarv.sh/2019/05/24/backdooring-route53-with-cross-account-dns.html |
|
Hi everyone, we've decided that there isn't a way we're happy to do this currently within the API constraints. Please don't submit new PRs for the resource right now. I'm going to leave the ticket open as an upstream issue to reconsider if something changes. For a workaround, you can use the cli instructions instead: https://aws.amazon.com/premiumsupport/knowledge-center/private-hosted-zone-different-account/ |
aeschright
added
the
upstream
|
Hi, I see that you guys don't want to go forward with this PR because the API does not have a good way of allowing an account to view vpc associations on a route53 zone that it does not own. I think that there are still uses for this resource and see no reason why limitation in associations API should stop you from implementing the authorizations API. All the pieces are there. And who knows, maybe once people get their hands on this, the path to full cross account route53 associations managed by terraform will be more clear. |
|
Hi, I was able to workaround this limitations using multiple data sources and resource. Please let me know if this would be accepted, as then I would need additional time for testing coverage. |
I kinda forget what the issue is exactly every time I look at this post, so probably worth taking whatever I say here with a grain of salt.
This doesn’t sound right, probably best to ignore me. I’ll try to look into this again soon though. Edit: Quick update, I had that backwards I think. So authorization is done by the hosted zone account, association is done by the VPC account. It’s failing because terraform tries to figure out if a zone is associated or not first, but you can’t do that with the API, you don’t have permissions to read the zone. If that information was stored locally then you should be able to do this, but you can’t know the state of your account other then that (I think I keep getting confused about the terraform vs security part of this). So if you take out the read part of the CRUD stuff on the association resource this should work(?) If the resource is ever managed outside of terraform you will run into issues though. Maybe this is OK, I’m not really sure. I think it was mostly decided we didn’t want to do that but maybe this part wasn’t clear before (actually pretty sure this wasn’t obvious before, I need to read this thread though). You mentioned something about passing roles (on my phone so difficult to look rn) in your other post, if you could somehow grant access to read the zone and maybe include it in an example of how this should be used maybe that would work as well. Edit2: The other part of this is AWS recommends removing the authorization after the association is complete. But tbh I’m not really sure I understand the reasoning for doing this, or why you wouldn’t want a VPC to be re-associated. I think it’s probably okay to just make note of it though in the docs, I thought there was discussion somewhere on this in the thread but not seeing it now. Let me know if I missed anything here. |
Are addressing the 403 error I put above? I believe so.
We are strictly speaking about just association of VPC-Account B to private hosted zone-Account A.. i think this is ok.
Without the idea of assuming more than 1 profile/alias within a resource/module (role-ception) this doesn't seem doable with terraform/aws. I question though how the above command works fine though specifying only one profile. Route53 and VPC's don't have the capability of a s3 bucket policy equivalent where you can grant access to IAM users/roles in different accounts. I mainly point to the cli commands that I reference above. Both manual cases for applying and destroying work perfect with just 1 profile being used with each command. I would imagine this translates to the API.. given it only has the inputs I provide.
Meaning it does plenty fine knowing it's already associated. This coming from the profile of the account with the VPC that doesn't have direct access to the private hosted zone in the "route53" account.
This is because after it is associated you no longer need it authorized. I think like you mention this can be noted in the docs.. and probably ignored. |
|
I would like to point out. Seems that this was first reported by @rginev on Nov 17, 2016 (roughly ~3.5 years ago) Since then: hashicorp/terraform#11174 (closed -> ^10208) hashicorp/terraform#12553 (@RyanJarv your PR) #384 (here) There's probably more I missed, I'm just trying to point out that this has been wanted for a while. Both @ewbankkit @FransUrbo seem to have a lot of history with this and might be interested in this still? |
|
I thought a lot about this a while back and my conclusion was that capturing the behaviour of this API in a resource doesn't match the way that the AWS provider works - i.e. the interactions for a single resource are done under the single AWS identity configured in the resource. |
I'm not understanding the issue tbh. Seems that this would only require a single aws identity per resource/api call/cli cmd. Sounds like it follows suit with the commands I posted above. #384 (comment) Would you be able to explain what the issue is exactly? |
|
wanted to bump you on this @ewbankkit and maybe also @RyanJarv |
|
Is anyone aware of any examples in terraform where the read part of CRUD is skipped, leaving other operations to depend only the data in the state file? |
|
I'm running into the same issue and would love to see a solution, or at least some extra documentation that outlines this scenario before more people end up running it and finding this issue. Alternatively, would it be possible to have an IAM policy that would allow the account with the VPC to list hosted zones on the account with the hosted zone as a workaround? |
|
I'm running into this issue as well and I think anyone trying to make use of a private hosted zone across accounts with terraform is going to run into this issue. Managing multiple aws accounts is a very common use case in large companies and is what aws seems to recommend as an architecture within an organization. It's very disappointing to see this go unresolved for years. |
|
just encountering this issue myself. there are ways to address using resolver-endpoints (inbound at phz-provider, outbound at phz-consumer), but those endpoints are charged separately by aws and it would be great to avoid that extra charge with the "direct" phz <-> vpc association alternative. per this knowledge-base article it shows how to accomplish the authorization via cli. i can/will try myself, but figured i would pose the question to the experienced participants in this thread: assuming that the authorization part was done manually in the context of the phz-provider account, would use of aws_route53_zone_association work in the context of the phz-consumer account? |
|
Hi all, I was looking into this again after @miketwenty1 pointed out that you can get the state of the I put something together to test this out in master...RyanJarv:cross-account-hostedzone-association. This is all just a test right now, so any thoughts here are appreciated. In that branch I'm using a cross_account attribute on the So in that branch if
This seems to work ok but at the moment but has the following issues:
I don't think the second is really an issue but wanted to mention it since it was brought up before. Mostly wanted to post this now to see if anyone has any opinions on this behavior in the branch I linked and any thoughts on handling drift. |
Using assumeRole yes, however terraform afik isn't designed to connect to multiple accounts in a single resource. If it was possible to do this without assumeRole this would be more feasible. I wasn't able to figure either of these options out though at least in a way that made sense.
This would not work, for the most part aws_route53_zone_association is the problem. If you want to try the branch in my last post that may work for you (warning: have not done much testing on it). |
|
We have encountered this issue as well. Trying to build an ephemeral organization that has DNS is turning out to be quite the challenge. This... bug? Will become more and more pertinent to businesses that have spawned in the era of IAC as they grow to incorporate multi account architectures, at AWS's recommendation I might add! |
|
I'm also keen to see a clean resolution to this issue and I understand this is a complex one to solve! I've tried using a null_resource to call the CLI and do the association. The problem is that when you create the zone, you can't specify the other account VPC or you get an error, so after everything has run the first time and the VPC is associated with the zone, terraforms seeks to remove the VPC from the hosted zone. It's all pretty ugly to handle at the moment. One semi "clean" way to handle this now is to create a public hosted zone and record which points to the private DNS. Like the resolver-endpoint solution above, it costs more to implement of course depending on choice of domain. For anyone interested the way I ended up implementing was as follows: Effect of the above is I can re-run this terraform and reach the same outcome of the zone being associated with account_b VPC. It's not pretty because on every run it removes the association then re-adds, but it works. You need to have a role with the appropriate permission that the script can assume. |
|
@tdmalone great timing with that post - has someone taken ownership to bring this home after the years of requests and posts :) |
|
Any chance this will get added into the provider anytime soon? The workarounds given uses local exec for aws cli and this is something we are trying very hard to avoid when using Terraform Enterprise. Also we are going into 100+ accounts now - and the less dependencies on externals the better :) |
|
@arnvid Copying an update from Brian on the above PR:
So, this is looking promising for pretty soon! 🎉 |
|
Support for Route 53 cross-account VPC Associations via a new |
|
This has been released in version 3.1.0 of the Terraform AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template for triage. Thanks! |
|
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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks! |
ghost
locked and limited conversation to collaborators
and others
This issue was originally opened by @rginev as hashicorp/terraform#10208. It was migrated here as part of the provider split. The original body of the issue is below.
Hey there,
Terraform does have route53_zone_association resource, but it works for private zones and VPCs in the same AWS account.
If you want to associate a VPC that you created with one AWS account with a private hosted zone that you created with a different account you had to ask AWS support to create authorisation manually.
Now they added an API for this. It would be great to have this implemented in terraform e.g. new resource.
Thanks in advance!
References
The text was updated successfully, but these errors were encountered: