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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

-1 and 'all' are not treated as synonymous layer 4 protocols #400

Closed
hashibot opened this issue Jun 13, 2017 · 2 comments
Closed

-1 and 'all' are not treated as synonymous layer 4 protocols #400

hashibot opened this issue Jun 13, 2017 · 2 comments
Labels
bug Addresses a defect in current functionality.

Comments

@hashibot
Copy link

This issue was originally opened by @cbarbour as hashicorp/terraform#10445. It was migrated here as part of the provider split. The original body of the issue is below.


The various network filtering resources for AWS accept '-1' or 'any' as a protocol value, as does the AWS API. Internally, AWS translates '-1' to 'any', which causes a delta against the Terraform configuration on the next run. This results in needless configuration churn.

The terraform documentation lists '-1' as an acceptable value for aws_network_acl_rules. The obvious workaround is to use 'any' instead.

Terraform Version

Terraform v0.7.13 (OSX 64 bit)

Affected Resource(s)

Please list the resources as a list, for example:

  • aws_network_acl
  • aws_security_group
  • aws_security_group_rule
  • aws_network_acl_rule

Terraform Configuration Files

resource "aws_network_acl_rule" "main_egress" {
    count = "${length(concat(var.permitted_networks, var.trusted_networks))}"
    network_acl_id = "${aws_network_acl.main.id}"
    rule_number = "${100 + count.index}"
    egress = true
    protocol = "-1"
    rule_action = "allow"
    cidr_block = "${element(concat(var.permitted_networks, var.trusted_networks), count.index)}"
}

Output

-/+ module.us_west_2_vpc.aws_network_acl_rule.main_subnets_egress.1
    cidr_block:     "172.20.1.0/24" => "172.20.1.0/24"
    egress:         "true" => "true"
    network_acl_id: "acl-877ccce0" => "acl-877ccce0"
    protocol:       "all" => "-1" (forces new resource)
    rule_action:    "allow" => "allow"
    rule_number:    "401" => "401"

Expected Behavior

Terraform should either reject this input, or treat -1 and any as synonymous.

Actual Behavior

Terraform accepts -1 as a valid value, treats the discovered any as configuration drift, and recreates all rules that use -1 as their protocol.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

  1. Create a network ACL rule or security group with -1 as the protocol.
  2. terraform apply
  3. terraform plan
@hashibot hashibot added the bug Addresses a defect in current functionality. label Jun 13, 2017
@radeksimko
Copy link
Member

Marking as duplicate of hashicorp/terraform#13012

This was resolved in hashicorp/terraform#13049 which was released as part of 0.9.2 (March 28, 2017). The resource should not show up in the diff if protocol = -1 anymore. I just verified using slightly modified example from above:

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_network_acl" "public" {
  vpc_id = "${aws_vpc.main.id}"
}

resource "aws_network_acl_rule" "main_egress" {
    network_acl_id = "${aws_network_acl.public.id}"
    rule_number = 100
    egress = true
    protocol = "-1"
    rule_action = "allow"
    cidr_block = "${aws_vpc.main.cidr_block}"
}

@radeksimko radeksimko marked this as a duplicate of hashicorp/terraform#13012 Aug 2, 2017
@ghost
Copy link

ghost commented Apr 11, 2020

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!

@ghost ghost locked and limited conversation to collaborators Apr 11, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Addresses a defect in current functionality.
Projects
None yet
Development

No branches or pull requests

2 participants