Add an aws_network_acl_rule resource

[timothykimball]

Related to #953:

As you can only have one network acl associated with a given subnet, you need to declare all rules associated with a subnet in one aws_network_acl resource.

But if you have multiple ports, this leads to long, verbose declarations. As with aws_security_group and aws_security_group_rule, would it no be easier to also have an aws_network_acl_rule?

The API is there to do this in AWS: http://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/ApiReference-cmd-CreateNetworkAclEntry.html

This would allow me to convert:

resource "aws_network_acl" "acl" {
    vpc_id = "${var.vpc_id}"
    subnet_ids = ["${split(",",module.subnets.ids)}"]
    egress {
        protocol = "tcp"
        rule_no = 1
        action = "allow"
        cidr_block = "${element(split(",",var.app_cidr_blocks), 0)}"
        from_port = "443"
        to_port = "443"
    }

    ingress {
        protocol = "tcp"
        rule_no = 1
        action = "allow"
        cidr_block =  "${element(split(",",var.app_cidr_blocks), 0)}"
        from_port = "443"
        to_port = "443"
    }

    egress {
        protocol = "tcp"
        rule_no = 1
        action = "allow"
        cidr_block = "${element(split(",",var.app_cidr_blocks), 1)}"
        from_port = "443"
        to_port = "443"
    }

    ingress {
        protocol = "tcp"
        rule_no = 1
        action = "allow"
        cidr_block =  "${element(split(",",var.app_cidr_blocks), 1)}"
        from_port = "443"
        to_port = "443"
    }


    egress {
        protocol = "tcp"
        rule_no = 2
        action = "allow"
        cidr_block = "${element(split(",",var.bastion_cidr_blocks),0)}"
        from_port = "22"
        to_port = "22"
    }

    ingress {
        protocol = "tcp"
        rule_no = 2
        action = "allow"
        cidr_block =  "${element(split(",",var.bastion_cidr_blocks), 0)}"
        from_port = 22
        to_port = 22
    }

   egress {
        protocol = "tcp"
        rule_no = 2
        action = "allow"
        cidr_block = "${element(split(",",var.bastion_cidr_blocks), 1)}"
        from_port = "22"
        to_port = "22"
    }

    ingress {
        protocol = "tcp"
        rule_no = 2
        action = "allow"
        cidr_block =  "${element(split(",",var.bastion_cidr_blocks),1)}"
        from_port = 22
        to_port = 22
    }

}

to the much more concise set of modules:

resource "aws_network_acl" "acl" {
    vpc_id = "${var.vpc_id}"
    subnet_ids = ["${split(",",module.subnets.ids)}"]   
}

module "https_acl_rule"  {
    source = "acl_rule"
    vpc_id = "${var.vpc_id}"
    port = 443
    src_blocks = "${var.app_cidr_blocks}"
    acl_id = "${aws_network_acl.acl.id}"
    rule_base  = 10
}

module "https_acl_rule"  {
    source = "acl_rule"
    vpc_id = "${var.vpc_id}"
    port = 22
    src_blocks = "${var.app_cidr_blocks}"
    acl_id = "${aws_network_acl.acl.id}"
    rule_base  = 20
}

acl_rule

resource "aws_security_group_rule" "rule"  {
     network_acl_id = "${var.acl_id}"
     egress {
        protocol = "tcp"
        rule_no = ${var.rule_base + count.index }
        action = "allow"
        cidr_block = "${element(split(",",var.cidr_blocks), count.index)}"
        from_port =  "${var.port}"
        to_port =  "${var.port}"
    }

    ingress {
        protocol = "tcp"
        rule_no = "${var.rule_no + count.index}"
        action = "allow"
        cidr_block =  "${element(split(",",var.cidr_blocks),count.index)}"
        from_port = "${var.port}"
        to_port =  "${var.port}"
    }
    count="${split(",",var.cidr_blocks}}"
}

[willmcg]

Similar to the conversation that was going on regarding security groups with rules,

My use case makes heavy use of overrides to give me a poor man's inheritance from a simple infrastructure base template to a more complex derived template. In many cases the network ACLs specified in the base template need to be overridden with new rules in the derived template so I simply override the aws_network_acl and re-specify any base rules I want to keep and add new rules as necessary. This is working really well for me even though there is some repetition of rules in the derived templates that would be eliminated with an aws_network_acl_rule resource.

How the aws_network_acl_rule resources are associated to the aws_network_acl resources is the part that is critical for me. I would like to see something like a aws_network_acl_rule_association that would allow me to group a set of independent top level rule resources into a set that are associated with an aws_network_acl resource rather than have the rules themselves declare the association.

The benefit is that you can have generic top level rule resources that can be re-used and attached to different network ACLs as well as not breaking my current use case...

The breakage I worry about is where I currently override the aws_network_acl and remove some rules from the base aws_network_acl resource and add some new rules for the derived version. In the case where top level rule resources are directly declaring their ACL association I can no longer remove rules in the overridden network ACL. With an association resource I can simply define a new association for the derived network ACL resource that associated the rules I want and also get all the benefits of not having to repeat rule definitions all over the place.

This would also work for the case where you want to associate a rule with an externally managed network ACL by just having the association specify the rules and the target network ACL ID.

[willmcg]

Of course re-usable network ACL rules do present the problem of rule numbering and ordering which matter for network ACLs. Perhaps the association resource could specify the rule numbers in the list of rules... or the rule numbers could be auto-magically generated based on the order they are specified in the association list?

[phinze]

Done in #4286! 😀

[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.