Setting security groups ingress protocol to "ALL" (-1) results in reapplication

[jaxxstorm]

An example ingress rule:

ingress {
  from_port = 0
   to_port = 0
   protocol = -1
   cidr_blocks = ["172.16.4.0/22"]
  }

ingress.#:                            "17" => "18"
<snip>
 ingress.1551838722.cidr_blocks.#:     "0" => "1"
  ingress.1551838722.cidr_blocks.0:     "" => "172.16.4.0/22"
  ingress.1551838722.from_port:         "" => "0"
  ingress.1551838722.protocol:          "" => "-1"
  ingress.1551838722.security_groups.#: "0" => "0"
  ingress.1551838722.self:              "" => "0"
  ingress.1551838722.to_port:           "" => "0"

This will apply successfully, and create the rule with ALL protocols as per AWS abilities.

However, when the next terraform plan is created, the it wants to change value:

ingress.1551838722.cidr_blocks.#:     "0" => "1"
  ingress.1551838722.cidr_blocks.0:     "" => "172.16.4.0/22"
  ingress.1551838722.from_port:         "" => "0"
  ingress.1551838722.protocol:          "" => "-1"
  ingress.1551838722.security_groups.#: "0" => "0"
  ingress.1551838722.self:              "" => "0"
  ingress.1551838722.to_port:           "" => "0"

Interestingly, if you only have one such ALL/ALL rule, this doesn't happen. Add a second, and it happens each time.

[jaxxstorm]

any love for this one?

[tysonmote]

FWIW, I can also replicate this with:

resource "aws_security_group" "test" {
  name = "test"
  description = "test"
  vpc_id = "${aws_vpc.foo.id}"

  ingress {
    from_port = 22
    to_port = 22
    protocol = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port = 0
    to_port = 65535
    protocol = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Applying that results in this message each time:

aws_security_group.test: Modifying...
  egress.532441254.cidr_blocks.#:     "0" => "1"
  egress.532441254.cidr_blocks.0:     "" => "0.0.0.0/0"
  egress.532441254.from_port:         "" => "0"
  egress.532441254.protocol:          "" => "-1"
  egress.532441254.security_groups.#: "0" => "0"
  egress.532441254.self:              "" => "0"
  egress.532441254.to_port:           "" => "65535"
aws_security_group.test: Modifications complete

[bobtfish]

+1 on ingress rules

My example: https://github.com/bobtfish/tf_aws_mesos/blob/f60226137351c52daa3c0d42e26bb466caeb8819/firewall.tf#L5

[catsby]

@tysontate is that the same issue? The OP is regarding ingress rules.

[catsby]

The main issue I'm seeing here is using -1 for protocol and specifying either a to or from port.

Reading the docs here:

• http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html#vpc-security-groups

Using the "ALL" protocol option then opens all ports, so our state file gets a to and from port of 0. Follow up plans then want to change this.

[catsby]

The egress example gives me a separate error regarding allow all rules:

* Error authorizing security group egress rules: InvalidPermission.Duplicate: the specified rule "peer: 0.0.0.0/0, ALL, ALLOW" already exists

Which makes sense, because AWS automatically adds an ALLOW ALL egress rule to each security group created. We may remove that with #1765

[ctiwald]

I'm trying to build a fix for the -1 thing now. Will update here if I'm successful.

[catsby]

Thanks @ctiwald

[ctiwald]

There are two classes of problem here: When passing "-1" to AWS, it drops the port declarations on the floor, meaning the Read result will never match the configuration. I have a fix for that.

There's another problem on egress: that default ALL 0.0.0.0/0 rule forces a new hash on read, which the config won't necessarily have locally. I'm not quite sure how to solve that, but #1765 should fix it if it's merged.

[catsby]

The original issue reported here, with ingress, has been resolved and I can't reproduce in master now. I'll follow up with @ctiwald 's pull requests and issues over there.

The egress allow all rule issue:

* Error authorizing security group egress rules: InvalidPermission.Duplicate: the specified rule "peer: 0.0.0.0/0, ALL, ALLOW" already exists

has also been resolved.

Thanks!

[pratibhadeepti]

Hi all is there any way of auto remediation of ports like if I am the admin and I open few ports according to my need now if someone else got my account credentials and try to change the ports which I don't want anyone to do so is there any way if someone trys to change the ports or source is either he is not able to do so or automatic it should role back

[mildwonkey]

@pratibhadeepti that's a great question, but more of a security/process issue.

One think you can do is run terraform regularly to bring your configurations back in line, though if someone got ahold of your account credentials you will have much bigger issues than just validating ports.

HashiCorp just published a blog post that talks about this topic:
https://www.hashicorp.com/blog/detecting-and-managing-drift-with-terraform

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