Support dns=private with terraform

[justinsb]

We explicitly disallow this, because we don't (I don't) know how to tell terraform to use but not delete a zone. But this should not be that hard to fix!

[ivanalonzo]

@justinsb any thoughts on when this may get addressed? I'd like to vote this up 👍

[jrnt30]

I think one way to approach this would be the use of a Data Source, which is essentially a dynamic lookup. Instead of KOPS generated TF "owning" the Hosted Zone, it would instead look it up.

I hacked on this a little bit (which as the notes say is not functional), however it took a similar approach to the resources.

If this seems like something useful/interesting to you, I could take a deeper look into all the places that the DNS Zone is used/inferred.

[a-chernykh]

I am having the same problem here. My Route53 zone is private and kops fails to resolve it at the time when it creates a new cluster. I agree that using data source is the right approach to discover private zone in Terraform. This is how our re-usable Terraform module looks like (we've created it based on output provided by kops):

data "aws_route53_zone" "main" {
  name = "${var.domain}"
  private_zone = true
}

# Main Route53 zone is a private zone which means it should be associated with kubernetes VPC
resource "aws_route53_zone_association" "secondary" {
  zone_id = "${data.aws_route53_zone.main.zone_id}"
  vpc_id = "${aws_vpc.kubernetes.id}"
}

resource "aws_route53_record" "api-kubernetes" {
  name = "api.${var.name}.${var.domain}"
  type = "A"

  alias = {
    name                   = "${aws_elb.api-kubernetes.dns_name}"
    zone_id                = "${aws_elb.api-kubernetes.zone_id}"
    evaluate_target_health = false
  }

  zone_id = "${data.aws_route53_zone.main.zone_id}"
}

I can wrap up a PR if it makes sense.