Datasource for AWS and Fastly IP ranges

[yawn]

This will allow the referencing of IP ranges like so:

provider "aws" {
  region = "eu-west-1"
}

provider "fastly" {
  api_key = "test"
}

data "fastly_ip_ranges" "fastly" {
}

data "aws_ip_ranges" "cloudfront" {
  services = [ "cloudfront" ]
}

data "aws_ip_ranges" "healthchecks" {
  services = [ "route53_healthchecks" ]
}

data "aws_ip_ranges" "european_ec2" {
  services = [ "ec2" ]
  regions = [ "eu-west-1", "eu-central-1" ]
}

resource "aws_security_group" "from_cloudfront" {

  name = "from_cf"

  ingress {
    from_port = "443"
    to_port = "443"
    protocol = "tcp"
    cidr_blocks = [ "${data.aws_ip_ranges.cloudfront.cidr_blocks}" ]
  }

  tags {
    CreateDate = "${data.aws_ip_ranges.cloudfront.create_date}"
    SyncToken = "${data.aws_ip_ranges.cloudfront.sync_token}"
  }

}

resource "aws_security_group" "from_europe" {

  name = "from_europe"

  ingress {
    from_port = "443"
    to_port = "443"
    protocol = "tcp"
    cidr_blocks = [ "${data.aws_ip_ranges.european_ec2.cidr_blocks}" ]
  }

  tags {
    CreateDate = "${data.aws_ip_ranges.european_ec2.create_date}"
    SyncToken = "${data.aws_ip_ranges.european_ec2.sync_token}"
  }

}

resource "aws_security_group" "from_fastly" {

  name = "from_fastly"

  ingress {
    from_port = "443"
    to_port = "443"
    protocol = "tcp"
    cidr_blocks = [ "${data.fastly_ip_ranges.fastly.cidr_blocks}" ]
  }

}

resource "aws_security_group" "from_r53" {

  name = "from_r53"

  ingress {
    from_port = "443"
    to_port = "443"
    protocol = "tcp"
    cidr_blocks = [ "${data.aws_ip_ranges.healthchecks.cidr_blocks}" ]
  }

  tags {
    CreateDate = "${data.aws_ip_ranges.healthchecks.create_date}"
    SyncToken = "${data.aws_ip_ranges.healthchecks.sync_token}"
  }

}

If you like this contribution, I'll

• add documentation
• add tests
• rename blocks to cidr_blocks

The main.tf referenced above should already be applyable.

[phinze]

@yawn this is very cool!! We'll definitely pull this in when the docs and tests are good to go. Thanks for your work on this! 👍 💟

[apparentlymart]

Agreed that this is awesome. Thanks so much for this!

Perhaps we could rename the blocks attribute on each of these to cidr_blocks for consistency with the way we've named this attribute elsewhere, and to make it super-obvious that these blocks are presented in CIDR notation.

[yawn]

Not a problem (the renaming to cidr_blocks).

One more question: I'm leaning towards making it an error if the selected filters yield no blocks in the case of the AWS IP ranges but I'm sure if that fits the principle of least surprise (in the context of Terraform). Any opinions regarding this?

[apparentlymart]

@yawn for several data sources we've been making it an error if the filters are over- or under-constrained. In this case, where the result is a list anyway, that seems less obviously correct since an empty list is a valid result.

However, I think I agree that returning no blocks at all, and then in turn e.g. creating a security group that has no blocks, is likely an indication of user error rather than a useful result, so I'm leaning towards agreeing about that being an error at least until we discover there's a use-case for it.

[yawn]

• Failure on empty results done in 2caae49
• Documentation added in 67bf13f

Test will come later.

Feel free to review, especially the SetId selection in 67b4b4c and e21203a about which I'm unsure. What's the semantics of ID's for data sources?

[apparentlymart]

Right now, due to some interactions with some core Terraform code that's common to both data and managed resources, it's required to set an id for a data resource but it doesn't really matter what it's set to... so this should be fine as long as result.SyncToken is guaranteed to never be the empty string.

[yawn]

Should we perhaps declare some constant that manifests this fact (e.g. DefaultDataSourceId) and start to use that? Might be useful since even in the current code the way IDs are derived or generated vary wildly.

[yawn]

Ready for review.

[apparentlymart]

Thanks for this, @yawn. I expect it will be really useful!

[yawn]

Glad to be of service @apparentlymart!

[ghost]

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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.