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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for creating temporary aws_route53_vpc_association_authorization #25438

Open
onitake opened this issue Jun 17, 2022 · 1 comment
Open
Labels
enhancement Requests to existing resources that expand the functionality or scope. service/route53 Issues and PRs that pertain to the route53 service.

Comments

@onitake
Copy link
Contributor

onitake commented Jun 17, 2022

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

@onitake onitake added the enhancement Requests to existing resources that expand the functionality or scope. label Jun 17, 2022
@github-actions github-actions bot added needs-triage Waiting for first response or review from a maintainer. service/route53 Issues and PRs that pertain to the route53 service. labels Jun 17, 2022
@justinretzolk justinretzolk removed the needs-triage Waiting for first response or review from a maintainer. label Jun 17, 2022
@abvm659
Copy link

abvm659 commented Nov 8, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Requests to existing resources that expand the functionality or scope. service/route53 Issues and PRs that pertain to the route53 service.
Projects
None yet
Development

No branches or pull requests

3 participants