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.

Sign up for GitHub

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

Jump to bottom

terraform import doesn't handle aws_security_group_rule descriptions properly #8866

Closed
asnell opened this issue Jun 4, 2019 · 2 comments
Closed

terraform import doesn't handle aws_security_group_rule descriptions properly #8866

asnell opened this issue Jun 4, 2019 · 2 comments
Labels
service/ec2 Issues and PRs that pertain to the ec2 service. stale Old or inactive issues managed by automation, if no further action taken these will get closed.

Comments

@asnell
Copy link
Contributor

asnell commented Jun 4, 2019

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

Terraform v0.12.1
+ provider.aws v2.13.0

(also tested with v0.11.14)

Affected Resource(s)

  • aws_security_group_rule

Expected Behavior

When importing aws_security_group resources into Terraform, aws_security_group_rule objects are also created as discussed in #6652 - whether this is desirable or not is out of scope here :)

However, if two (or more) rules within the security group have the same port/protocol combination, differences in rule descriptions between each rule will be lost.

Actual Behavior

Terraform import seems to consolidate rules with the same port/protocol combination into a single rule with a list of CIDRs, and pick one of the rule descriptions, discarding the others. If you look at aws ec2 describe-security-groups output (see step 1 below), it does seem like the two rules have been effectively condensed down into a single rule - however, the ability to resolve different descriptions for each CIDR has been retained.

Once imported into Terraform, it becomes impossible to manage state as reflected in the AWS console without destroying/recreating rules on the first run of terraform apply

Note that if you work only with aws_security_group objects, everything works just fine - but this is suboptimal when managing SGs with lots of rules.

Also note that if TF creates the SGs and rules in the first place, everything also works as expected.

Steps to Reproduce

  1. Create a security group in AWS with two ingress rules having the same port/protocol, but different CIDR and description values:
$ aws ec2 describe-security-groups --group-ids sg-XXXXXXXXXXXX
{
    "SecurityGroups": [
        {
            "IpPermissionsEgress": [
                {
                    "IpProtocol": "-1",
                    "PrefixListIds": [],
                    "IpRanges": [
                        {
                            "CidrIp": "0.0.0.0/0"
                        }
                    ],
                    "UserIdGroupPairs": [],
                    "Ipv6Ranges": []
                }
            ],
            "Description": "Test TF create of rules with different descriptions",
            "IpPermissions": [
                {
                    "PrefixListIds": [],
                    "FromPort": 333,
                    "IpRanges": [
                        {
                            "Description": "Desc 1",
                            "CidrIp": "10.0.0.0/24"
                        },
                        {
                            "Description": "Desc 2",
                            "CidrIp": "10.10.0.0/24"
                        }
                    ],
                    "ToPort": 333,
                    "IpProtocol": "tcp",
                    "UserIdGroupPairs": [],
                    "Ipv6Ranges": []
                }
            ],
            "GroupName": "terraform-20190604194041775000000001",
            "VpcId": "vpc-xxxxxxxx",
            "OwnerId": "XXXXXXXXXXXX",
            "GroupId": "sg-XXXXXXXXXXXX"
        }
    ]
}
  1. Create a stub file to allow importing:
$ cat asnell_test_sg_1.tf
resource "aws_security_group" "asnell_test_sg_1" {

}
  1. Import the security group into Terraform state:
$ terraform import aws_security_group.asnell_test_sg_1 sg-XXXXXXXXXXXX
Acquiring state lock. This may take a few moments...
aws_security_group.asnell_test_sg_1: Importing from ID "sg-XXXXXXXXXXXX"...
aws_security_group.asnell_test_sg_1: Import complete!
  Imported aws_security_group
  Imported aws_security_group_rule
  Imported aws_security_group_rule
aws_security_group_rule.asnell_test_sg_1-1: Refreshing state... [id=sgrule-XXXXXXXXXXXX]
aws_security_group.asnell_test_sg_1: Refreshing state... [id=sg-XXXXXXXXXXXX]
aws_security_group_rule.asnell_test_sg_1: Refreshing state... [id=sgrule-XXXXXXXXXXXX]
  1. Observe that the state reflects only two rules rather than the three (one default egress and two explicit ingress) that are shown in the AWS console:
$ terraform state list
aws_security_group.asnell_test_sg_1
aws_security_group_rule.asnell_test_sg_1
aws_security_group_rule.asnell_test_sg_1-1
  1. Inspect the first rule and note that while the port, protocol, and CIDR blocks reflect accurately the state of reality, the description ("Desc 2") of the second CIDR block has been lost:
$ terraform state show aws_security_group_rule.asnell_test_sg_1
# aws_security_group_rule.asnell_test_sg_1:
resource "aws_security_group_rule" "asnell_test_sg_1" {
    cidr_blocks       = [
        "10.0.0.0/24",
        "10.10.0.0/24",
    ]
    description       = "Desc 1"
    from_port         = 333
    id                = "sgrule-XXXXXXXXXXXX"
    ipv6_cidr_blocks  = []
    prefix_list_ids   = []
    protocol          = "tcp"
    security_group_id = "sg-XXXXXXXXXXXX"
    self              = false
    to_port           = 333
    type              = "ingress"
}
@aeschright aeschright added the needs-triage Waiting for first response or review from a maintainer. label Jun 19, 2019
@aeschright aeschright added the service/ec2 Issues and PRs that pertain to the ec2 service. label Jul 3, 2019
@github-actions
Copy link

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!

@github-actions github-actions bot added the stale Old or inactive issues managed by automation, if no further action taken these will get closed. label Jun 22, 2021
@github-actions
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 23, 2021
@breathingdust breathingdust removed the needs-triage Waiting for first response or review from a maintainer. label Sep 17, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
service/ec2 Issues and PRs that pertain to the ec2 service. stale Old or inactive issues managed by automation, if no further action taken these will get closed.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@aeschright @breathingdust @asnell