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

aws_security_group_rule fails to be applied to aws_security_group #5532

Closed
xsb opened this Issue Mar 9, 2016 · 4 comments

Comments

Projects
None yet
3 participants
@xsb

xsb commented Mar 9, 2016

I'm not sure if this is a bug or it's me not understanding the AWS provider documentation.

I can't create two EC2-Classic Security Groups that depend on each other. The desired scenario is:

  • sgDoraemon (accepts TCP traffic on port 8080 from sgNobita)
  • sgNobita (accepts TCP traffic on port 8081 from sgDoraemon)

This is my .tf file:

resource "aws_security_group" "doraemon" {
  name = "sgDoraemon"
}

resource "aws_security_group" "nobita" {
  name = "sgNobita"
}

resource "aws_security_group_rule" "doraemon_from_nobita" {
  type                     = "ingress"
  from_port                = 8080
  to_port                  = 8080
  protocol                 = "tcp"
  security_group_id        = "${aws_security_group.doraemon.id}"
  source_security_group_id = "${aws_security_group.nobita.id}"
}

resource "aws_security_group_rule" "nobita_from_doraemon" {
  type                     = "ingress"
  from_port                = 8081
  to_port                  = 8081
  protocol                 = "tcp"
  security_group_id        = "${aws_security_group.nobita.id}"
  source_security_group_id = "${aws_security_group.doraemon.id}"
}

This is the output of terraform plan

+ aws_security_group.doraemon
    description: "" => "Managed by Terraform"
    egress.#:    "" => "<computed>"
    ingress.#:   "" => "<computed>"
    name:        "" => "sgDoraemon"
    owner_id:    "" => "<computed>"
    vpc_id:      "" => "<computed>"

+ aws_security_group.nobita
    description: "" => "Managed by Terraform"
    egress.#:    "" => "<computed>"
    ingress.#:   "" => "<computed>"
    name:        "" => "sgNobita"
    owner_id:    "" => "<computed>"
    vpc_id:      "" => "<computed>"

+ aws_security_group_rule.doraemon_from_nobita
    from_port:                "" => "8080"
    protocol:                 "" => "tcp"
    security_group_id:        "" => "${aws_security_group.doraemon.id}"
    self:                     "" => "0"
    source_security_group_id: "" => "${aws_security_group.nobita.id}"
    to_port:                  "" => "8080"
    type:                     "" => "ingress"

+ aws_security_group_rule.nobita_from_doraemon
    from_port:                "" => "8081"
    protocol:                 "" => "tcp"
    security_group_id:        "" => "${aws_security_group.nobita.id}"
    self:                     "" => "0"
    source_security_group_id: "" => "${aws_security_group.doraemon.id}"
    to_port:                  "" => "8081"
    type:                     "" => "ingress"


Plan: 4 to add, 0 to change, 0 to destroy.

And this is what I get when running terraform apply

aws_security_group.nobita: Creating...
  description: "" => "Managed by Terraform"
  egress.#:    "" => "<computed>"
  ingress.#:   "" => "<computed>"
  name:        "" => "sgNobita"
  owner_id:    "" => "<computed>"
  vpc_id:      "" => "<computed>"
aws_security_group.doraemon: Creating...
  description: "" => "Managed by Terraform"
  egress.#:    "" => "<computed>"
  ingress.#:   "" => "<computed>"
  name:        "" => "sgDoraemon"
  owner_id:    "" => "<computed>"
  vpc_id:      "" => "<computed>"
aws_security_group.nobita: Creation complete
aws_security_group.doraemon: Creation complete
aws_security_group_rule.nobita_from_doraemon: Creating...
  from_port:                "" => "8081"
  protocol:                 "" => "tcp"
  security_group_id:        "" => "sg-cbecf1a1"
  self:                     "" => "0"
  source_security_group_id: "" => "sg-caecf1a0"
  to_port:                  "" => "8081"
  type:                     "" => "ingress"
aws_security_group_rule.doraemon_from_nobita: Creating...
  from_port:                "" => "8080"
  protocol:                 "" => "tcp"
  security_group_id:        "" => "sg-caecf1a0"
  self:                     "" => "0"
  source_security_group_id: "" => "sg-cbecf1a1"
  to_port:                  "" => "8080"
  type:                     "" => "ingress"
Error applying plan:

2 error(s) occurred:

* aws_security_group_rule.nobita_from_doraemon: Error authorizing security group rule type ingress: InvalidGroup.NotFound: Unable to find group 'sg-caecf1a0'
    status code: 400, request id: 
* aws_security_group_rule.doraemon_from_nobita: Error authorizing security group rule type ingress: InvalidGroup.NotFound: Unable to find group 'sg-cbecf1a1'
    status code: 400, request id:

If I search for the security groups in AWS, I can see that they were created correctly (without the rules of course). If I try to add those rules manually using the same group names shown in the output error, everything works fine.

I'm using aws_security_group_rule to solve the dependency cycle on security groups creation.

@jen20

This comment has been minimized.

Show comment
Hide comment
@jen20

jen20 Mar 9, 2016

Contributor

This looks like a bug to me - I'll try to find an account with ec2-classic to replicate and fix.

Contributor

jen20 commented Mar 9, 2016

This looks like a bug to me - I'll try to find an account with ec2-classic to replicate and fix.

@xsb

This comment has been minimized.

Show comment
Hide comment
@xsb

xsb Mar 10, 2016

#5533 fixes this.

I tested my example code with the changes in #5533 and, if I use SG names instead of IDs in the source_security_group_id field, it works perfectly fine. It previously crashed if I tried names instead of ids.

xsb commented Mar 10, 2016

#5533 fixes this.

I tested my example code with the changes in #5533 and, if I use SG names instead of IDs in the source_security_group_id field, it works perfectly fine. It previously crashed if I tried names instead of ids.

@catsby

This comment has been minimized.

Show comment
Hide comment
@catsby

catsby Mar 10, 2016

Member

Hey @xsb thanks for confirming that #5533 fixes your issue (mostly). I agree that the naming of source_security_group_id is confusing here, it was clearly designed with only VPCs in mind and that's my mistake.

I've opened up #5555 to track that bug. Ideally we'll add source_security_group_name, unless you feel that simply documenting this is OK.

For now, I'm going to close this issue. Sorry for the trouble!

Member

catsby commented Mar 10, 2016

Hey @xsb thanks for confirming that #5533 fixes your issue (mostly). I agree that the naming of source_security_group_id is confusing here, it was clearly designed with only VPCs in mind and that's my mistake.

I've opened up #5555 to track that bug. Ideally we'll add source_security_group_name, unless you feel that simply documenting this is OK.

For now, I'm going to close this issue. Sorry for the trouble!

@catsby catsby closed this Mar 10, 2016

@xsb

This comment has been minimized.

Show comment
Hide comment
@xsb

xsb Mar 10, 2016

Thanks @catsby, I've added my comments on #5555 so the discussion can be followed there

xsb commented Mar 10, 2016

Thanks @catsby, I've added my comments on #5555 so the discussion can be followed there

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment