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

Wide Open ipv6 Egress Being Created #130

Closed
ghost opened this issue Jun 28, 2019 · 6 comments · Fixed by #148
Closed

Wide Open ipv6 Egress Being Created #130

ghost opened this issue Jun 28, 2019 · 6 comments · Fixed by #148

Comments

@ghost
Copy link

ghost commented Jun 28, 2019

Module: v3.0.1 Terraform: 0.12.3


I am creating a load balancer security group that does the following:

  • Allows HTTPS ingress from a list of CIDR ranges.
  • Allows HTTPS egress to a specific security group.

When I run the below, the ingress rules are fine. However, egress also creates a wide open IPv6 rule along with the proper one referencing a security group:

module "ext_alb_sg" {
  source              = "terraform-aws-modules/security-group/aws"
  name                = "prod-ph-ext-alb-sg"
  vpc_id              = data.terraform_remote_state.vpc.outputs.vpc.id
  ingress_rules       = ["https-443-tcp"]
  ingress_cidr_blocks = var.regional_accelerator_cidrs

  computed_egress_with_source_security_group_id = [
    {
      from_port                = 443
      to_port                  = 443
      protocol                 = "tcp"
      source_security_group_id = module.tomcat_sg.this_security_group_id
    }
  ]

  number_of_computed_egress_with_source_security_group_id = 1
}

The above creates egress like:

Type Protocol Port Range Destination Description
HTTPS TCP 443 ::/0 Egress Rule
HTTPS TCP 443 sg-1234567890 Egress Rule

I'm not sure where the ::/0 wide open rule comes from. If I delete it, it'll recreate.

Thanks,
Tom

@ghost
Copy link
Author

ghost commented Jun 28, 2019

I believe I may have found the issue. Line 525 of main.tf sets an IPv6 CIDR Block range that seems to default to ::/0 in the aws_security_group_rule.computed_egress_with_source_security_group_id resource. I don't think this should be there as the goal here is to make a rule with an SG not CIDR.

I cloned the repository, pointed at the module locally, commented out that line and tried again. All works fine now. I notice this defined at aws_security_group_rule.ingress_with_source_security_group_id as well so am thinking that may have the same issue. It looks like egress_ipv6_cidr_blocks defaults to ::/0

variable "egress_ipv6_cidr_blocks" {
  description = "List of IPv6 CIDR ranges to use on all egress rules"
  type        = list(string)
  default     = ["::/0"]        // <== Not sure that should be there.
}

I'm not sure it is possible to set a TF list to null (I tried but it still used the default), or empty [] ... gets an error. So, the variable defaults to wide open, then may be improperly called in the resources that involve source security groups.

Hope some of that helps.

@JamieGruener
Copy link

I just ran into this exact problem. The main reason I'm looking at this plugin is to create server/client Security Group pairs, but if all my egress gets full IPv6 access, that's kind of frustrating. It seems like a simple fix. Any workarounds available? (Other than pulling down the source and using it locally, I mean.)

@ghost
Copy link
Author

ghost commented Oct 10, 2019

I was going to fork, modify and run the code locally.. but it just seemed a messy solution. I ended up using the built-in resources in TF in place of this module. I define all ingress & egress rules via associated aws_security_group_rule resources (i.e. don't use the array approach in aws_security_group). That combined with some homegrown modules for repeatable patterns has worked just fine. Honestly, I'm not sure how much time/effort/lines of code this module saves versus just using the native resources.

@ricardojdsilva87
Copy link

I'm having the same issue on the egress_with_source_security_group_id, the IPV6 range is always added with the needed SG on 2 separated lines

@antonbabenko
Copy link
Member

This has been fixed in #148 and v3.6.0 has been just released.

@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 Nov 16, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
3 participants