terraform plan incorrectly wants to blank a security group ingress description

[mdaniel]

Terraform Version

Terraform v0.10.7
2017/10/23 11:52:51 [DEBUG] found provider "terraform-provider-aws_v1.1.0_x4"

If I knew how to use a master build of this provider, I would report if this has been fixed since 1.1.0

Affected Resource(s)

• aws_security_group (specifically an ingress block)

Terraform Configuration Files

resource "aws_security_group" "jenkins-sg" {
  name        = "jenkins-sg"
  description = "SG for jenkins"
  vpc_id      = "${var.vpc_id}"

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["10.2.0.0/16"]
  }

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    description = "blah blah message"
    cidr_blocks = ["10.5.0.0/16"]
  }

  ingress {
    from_port   = 8080
    to_port     = 8080
    protocol    = "tcp"
    cidr_blocks = ["10.2.0.0/16", "10.4.0.0/16"]
  }

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

  tags {
    Name = "jenkins-sg"
  }
}

Debug Output

I'll be glad to create a gist of the entire run, but I would have to scrub it, so I would only want to do that if this plan output -- which I feel is very clear, when taken with the AWS EC2 api response -- isn't sufficient

In the following output, I moved the 426799852 creation text next to its 1365611918 destruction text to make that relationship more obvious; the 3854841948 "copy" action at the bottom is correct, it's the ingress.1365611918.description change that is wrong -- the EC2 IpRange "10.2.0.0/16" has no description to begin with, and thus does not need it blanked

  ~ module.jenkins.aws_security_group.jenkins-sg
      ingress.1365611918.cidr_blocks.#:      "1" => "0"
      ingress.1365611918.cidr_blocks.0:      "10.2.0.0/16" => ""
      ingress.1365611918.description:        "blah blah message" => ""
      ingress.1365611918.from_port:          "22" => "0"
      ingress.1365611918.ipv6_cidr_blocks.#: "0" => "0"
      ingress.1365611918.protocol:           "tcp" => ""
      ingress.1365611918.security_groups.#:  "0" => "0"
      ingress.1365611918.self:               "false" => "false"
      ingress.1365611918.to_port:            "22" => "0"

      ingress.426799852.cidr_blocks.#:       "0" => "1"
      ingress.426799852.cidr_blocks.0:       "" => "10.2.0.0/16"
      ingress.426799852.description:         "" => ""
      ingress.426799852.from_port:           "" => "22"
      ingress.426799852.ipv6_cidr_blocks.#:  "0" => "0"
      ingress.426799852.protocol:            "" => "tcp"
      ingress.426799852.security_groups.#:   "0" => "0"
      ingress.426799852.self:                "" => "false"
      ingress.426799852.to_port:             "" => "22"

      ingress.1706960236.cidr_blocks.#:      "2" => "2"
      ingress.1706960236.cidr_blocks.0:      "10.2.0.0/16" => "10.2.0.0/16"
      ingress.1706960236.cidr_blocks.1:      "10.4.0.0/16" => "10.4.0.0/16"
      ingress.1706960236.description:        "" => ""
      ingress.1706960236.from_port:          "8080" => "8080"
      ingress.1706960236.ipv6_cidr_blocks.#: "0" => "0"
      ingress.1706960236.protocol:           "tcp" => "tcp"
      ingress.1706960236.security_groups.#:  "0" => "0"
      ingress.1706960236.self:               "false" => "false"
      ingress.1706960236.to_port:            "8080" => "8080"

      ingress.3854841948.cidr_blocks.#:      "1" => "1"
      ingress.3854841948.cidr_blocks.0:      "10.5.0.0/16" => "10.5.0.0/16"
      ingress.3854841948.description:        "blah blah message" => "blah blah message"
      ingress.3854841948.from_port:          "22" => "22"
      ingress.3854841948.ipv6_cidr_blocks.#: "0" => "0"
      ingress.3854841948.protocol:           "tcp" => "tcp"
      ingress.3854841948.security_groups.#:  "0" => "0"
      ingress.3854841948.self:               "false" => "false"
      ingress.3854841948.to_port:            "22" => "22"

Expected Behavior

The plan output should have indicated no changes required

Actual Behavior

The plan output proposed modifying the security group, specifically its ingress block

Steps to Reproduce

1. Create an AWS security group, sg-abcdef
2. In that SG, add an Inbound rule of Type SSH, Protocol TCP, Port Range 22, Source "10.2.0.0/16" with no Description
3. In that SG, add an Inbound rule of Type SSH, Protocol TCP, Port Range 22, Source "10.5.0.0/16" with a Description of "blah blah message"
4. Place the above HCL into blah.tf
5. Correctly configure your AWS provider, etc, etc
6. terraform plan

Important Factoids

There are three interesting observations:

• modifying input .tf
• modifying .tfstate file
• observing the output from ec2 describe-security-groups (which 100% matches the --debug traffic from terraform-provider-aws)

First, I tried manually distinguishing where the description should go by splitting out the with-description ingress from the without-description ingress by creating two separate resource "aws_security_group_rule" "jenkins-sg_10-5_22" but it didn't help (and made the problem much worse)

Then, I thought maybe it was just a .tfstate problem, and updated the attributes block to correctly describe the "description": "blah blah message",, but this also did not help

The output from aws ec2 describe-security-groups --filters 'Name=tag-value,Values=jenkins-sg' demonstrates that AWS itself is rolling up those ingress blocks and pushing the description down onto the actual CIDR IpRange, whereas it seems terraform-provider-aws is erroneously recombining them at some step, resulting in a mismatch with the tfstate (and actual) situation

This is the output from that describe-security-groups and matches (as one might expect) the debug-level <DescribeSecurityGroupsResponse from AWS

{
  "SecurityGroups": [
    {
      "IpPermissionsEgress": [
        {
          "IpProtocol": "-1",
          "PrefixListIds": [],
          "IpRanges": [
            {
              "CidrIp": "0.0.0.0/0"
            }
          ],
          "UserIdGroupPairs": [],
          "Ipv6Ranges": []
        }
      ],
      "Description": "SG for jenkins",
      "Tags": [
        {
          "Value": "jenkins-sg",
          "Key": "Name"
        }
      ],
      "IpPermissions": [
        {
          "PrefixListIds": [],
          "FromPort": 8080,
          "IpRanges": [
            {
              "CidrIp": "10.2.0.0/16"
            },
            {
              "CidrIp": "10.4.0.0/16"
            }
          ],
          "ToPort": 8080,
          "IpProtocol": "tcp",
          "UserIdGroupPairs": [],
          "Ipv6Ranges": []
        },
        {
          "PrefixListIds": [],
          "FromPort": 22,
          "IpRanges": [
            {
              "CidrIp": "10.2.0.0/16"
            },
            {
              "Description": "blah blah message",
              "CidrIp": "10.5.0.0/16"
            }
          ],
          "ToPort": 22,
          "IpProtocol": "tcp",
          "UserIdGroupPairs": [],
          "Ipv6Ranges": []
        }
      ],
      "GroupName": "jenkins-sg",
      "VpcId": "vpc-deadbeef",
      "OwnerId": "XXXXXXXXXXXX",
      "GroupId": "sg-cafebabe"
    }
  ]
}

References

• Provide support for security group rules description. #1940
• data_source_aws_security_group: add description #1943

[magnetik]

Not sure if related and I did not put as much effort as you into this, but using a module that define a lot of aws_security_group_rule with IPs and a description, every time I run plan, the plan is to change every description (but not the IPs):

  ~ module.ns545692.aws_security_group_rule.allow_to_access_gg
      description: "From ovh-eu-61" => "From ovh-na-19"

  ~ module.ns548456.aws_security_group_rule.allow_to_access_gg
      description: "From ovh-eu-61" => "From ovh-na-13"

  ~ module.ns549254.aws_security_group_rule.allow_to_access_gg
      description: "From ovh-eu-61" => "From ovh-na-14" 

[antvak]

I get the same bug. If I try to create two rules with the same port and different description, regardless of the ip, it will always try to update one of the descriptions. If I don't use any descriptions at all, it works fine! I have tried 0.10.6 and 0.10.8, same result!

[bflad]

Hi folks 👋 Sorry this has been a longstanding issue with the AWS provider. The fix for this should be contained in #4416 which will be released with v1.19.0 of the AWS provider, likely middle of next week.

Shout outs to @loivis (and @svanharmelen who submitted an earlier, likely correct PR, which I admittedly should have reviewed and merged sooner: #3628)

Given there were so many various issues surrounding this bug, I will be locking this issue (amongst all the others) to encourage any lingering issues/discussion to be fully described in new issue(s) for consolidation. Thanks for your understanding.