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

Manual AWS console additions to security groups are not detected by plan/apply. #220

Closed
hashibot opened this issue Jun 13, 2017 · 4 comments
Labels
bug Addresses a defect in current functionality. service/ec2 Issues and PRs that pertain to the ec2 service.
Milestone

Comments

@hashibot
Copy link

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


Terraform v0.7.0

Affected Resource(s)

aws_security_group
aws_security_group_rule

Actual Behavior

I have an aws security group with no in-line rules in a vpc, and a set of aws security group rules attached to it. Each sg rule can declare multiple IPs per port.

resource "aws_security_group" "mod" {
  name        = "${var.name}"
  description = "${var.description}"

  vpc_id = "${var.vpc_id}"

  lifecycle {
    create_before_destroy = true
  }
}

resource "aws_security_group_rule" "admin_ssh_tcp" {
  type = "ingress"

  cidr_blocks       = ["1.1.1.1/32", "2.2.2.2/32", "3.3.3.3/32"]
  from_port         = 22
  to_port           = 22
  protocol          = "tcp"
  security_group_id = "${aws_security_group.mod.id}"
}

If I go into the AWS console and manually remove or edit a line (ie remove the 1.1.1.1/32:22 line, or change it to 4.4.4.4/32:80), tf will detect this and attempt to add the line back in. However, because the other lines still exist (ie 2.2.2.2/32:22), it crashes because of duplicates.

* aws_security_group_rule.admin_ssh_tcp: [WARN] A duplicate Security Group rule was found on (sg-redacted). This may be
a side effect of a now-fixed Terraform issue causing two security groups with
identical attributes but different source_security_group_ids to overwrite each
other in the state. See https://github.com/hashicorp/terraform/pull/2376 for more
information and instructions for recovery. Error message: the specified rule "peer: 2.2.2.2/32, TCP, from port: 22, to port: 22, ALLOW" already exists

If I have an aws_security_group_rule with only 1 IP, then removals and changes work fine.

If I add in a completely new rule, such as allow all ports and all IPs in, tf does not detect this at all.

Expected Behavior

I expect tf to detect any changes to a security group - removed rules, changed rules, and added rules. I expect it to then successfully change them to what is declared in the tf config. I believe this is consistent with how tf deals with manual changes that it detects elsewhere.

@hashibot hashibot added the bug Addresses a defect in current functionality. label Jun 13, 2017
@yeungs
Copy link

yeungs commented Aug 8, 2017

I am experience the same problem with Terraform v0.9.11 not detecting manual AWS console updates.

Here are two cases I ran into this.
Create "aws_security_group.foo" and then create "aws_security_group_rule.bar". Attach the "bar" to the "foo". Terraform apply. Then go to AWS console and add a new port rule such as 443, 10.0.0.0/8 in "foo". Terraform plan doesn't show a difference. If you do Terraform apply then you will see 443, 10.0.0.0/8 in the state inside "aws_security_group.foo" section.

The second case is "terraform import". If I do a Terraform import of aws_security_group.whatever then it would create in the state file an "aws_security_group_rule" for each port rule instead of inside "aws_security_group.whatever" . I would have to massage the state file manually and put the rules back into the "aws_security_group.whatever".

@radeksimko radeksimko added the service/ec2 Issues and PRs that pertain to the ec2 service. label Jan 25, 2018
@pmoust
Copy link
Contributor

pmoust commented Apr 13, 2018

This is still the case in current release.
AWS provider only accounts for rules under its control for a given SG id.

The expected behaviour would be to remove any rule not specified in the graph.

I do understand that this would be a breaking change, but it is definitely a bug and not a feature.

Would it be possible to add a strict = true|false (for lack of a better name) parameter in the aws_security_group entity to handle this case?

We could leave strict = false as default to be backwards compatible, and document use of strict = true for sanity.

Thoughts @radeksimko ?

@radeksimko
Copy link
Member

Hi folks,
thanks for reporting this issue. I'm just going to consolidate this debate to a single thread, specifically #3234 which also contains explanation of the current state and suggestion for workaround.

@ghost
Copy link

ghost commented Apr 5, 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 5, 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. service/ec2 Issues and PRs that pertain to the ec2 service.
Projects
None yet
Development

No branches or pull requests

4 participants