Add support for creating temporary aws_route53_vpc_association_authorization

onitake commented 2 years ago

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

AWS recommends deleting Route53 VPC association authorizations after the DNS zone has been associated with the VPC, but this is difficult to do with Terraform's resource management model.

While there's not apparent or immediate danger to keeping the authorization around, it still bears a potential security risk when the VPC ID gets reused later. It might also cause an issue when the association is deleted unilaterally and reassociation should be prevented.

New or Affected Resource(s)

aws_route53_vpc_association_authorization

Potential Terraform Configuration

This is what's currently required, with the authorization being left over:

resource "aws_route53_vpc_association_authorization" "local" {
  provider = aws.local_account
  vpc_id  = aws_vpc.central.id
  zone_id = aws_route53_zone.local.id
}

resource "aws_route53_zone_association" "central" {
  provider = aws.central_account
  vpc_id  = aws_vpc.central.id
  zone_id = aws_route53_zone.local.id
}

aws.local_account is a provider config for the AWS account that contains the private DNS zone. aws_route53_zone.local.id is the ID of the zone. aws.central_account is a provider config for the AWS account that contains the VPC where the private zone should be associated. aws_vpc.central.id is the ID of the VPC.

By consolidating the two API calls into one resource, it may be possible to immediately delete the authorization after creating the association:

resource "aws_route53_zone_association" "central" {
  provider = aws.central_account
  vpc_id  = aws_vpc.central.id
  zone_id = aws_route53_zone.local.id
  authorization {
    auto_authorize = true
    authorization_provider = aws.local_account
  }
}

References

https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zone-private-associate-vpcs-different-accounts.html (step 3)

abvm659 commented 2 years ago

It is actually pure error to keep authorization, the first is a security and the second is a hard to workaround fact that there is a hard limit for number of authorizations you can have (100).

The only way how to make it somehow working if you reach the limit is to use null_resource to get current list of vpcs (problematic if you are creating also vpcs at the same run) .. and create a set of vpcs that are newly being added in the run and use this set in aws_route53_vpc_association_authorization and following aws_route53_zone_association (this one needs to have full list of vpcs). Tricky to implement and fairly stupid.

Other way what we did before was, that we handled full authorization/deauthorization and association in null_resources .. which was probably better than use terraform for this, since it was at least kind of more visible what is going on.

Not sure though how temporary authorization would look like from terraform perspective - it somehow goes against the principle of idempotent creations and destructions of resources. The only inteligent way would be to create new resource that will handle zone association for non local vpcs, which would handle authorization and deauthorization during the creation of the association. Thinking about it, it only makes sense to do it like that.

github-actions[bot] commented 2 weeks ago

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!

hashicorp / terraform-provider-aws