Security- `manage_default_security_group = true` REMOVES default security group rules

[luarx]

Description

From version v4.0.0, these variables are true by default:

manage_default_security_group now defaults to true
manage_default_route_table now defaults to true
manage_default_network_acl now defaults to true

I have observed that when manage_default_security_group is true, it removes default inbound/outbound rules which probably are important.

Versions

• Module version [Required]: v4.0.2

• Terraform version: v1.5.7

Reproduction Code [Required]

Steps to reproduce the behavior:
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "4.0.2"

  name                 = "garbanzos-vpc"
  cidr                 = "10.0.0.0/16"
  azs                  = slice(data.aws_availability_zones.available.names, 0, 2)
  private_subnets      = ["10.0.0.0/18", "10.0.64.0/18"]
  public_subnets       = ["10.0.192.0/22", "10.0.196.0/22"]
  enable_nat_gateway   = true
  single_nat_gateway   = false 
  enable_dns_hostnames = true
}

Are you using workspaces? No Have you cleared the local cache (see Notice section above)? Yes

Expected behavior

Preserve the default VPC Security group rules

Actual behavior

It removes default Security group rules The security group is empty

Additional context

AWS sets those rules because of security reasons, so I would consider that it is a good idea to maintain them as described here https://docs.aws.amazon.com/vpc/latest/userguide/default-security-group.html

[bryantbiggs]

AWS sets those rules because of security reasons

I don't believe that is true - I think they set them in order to provide a "good" default behavior for those that are not using custom security groups. But the recommendation would be to use a custom security group per application/resource/etc. to scope the access accordingly

It is common practice in most organizations to strip the rules from the default security group to enforce this behavior

[luarx]

I don't believe that is true - I think they set them in order to provide a "good" default behavior for those that are not using custom security groups. But the recommendation would be to use a custom security group per application/resource/etc. to scope the access accordingly

@bryantbiggs I totally agree with this point, the best situation is to use custom security groups so that it can be specific for the infra purpose.

It is common practice in most organizations to strip the rules from the default security group to enforce this behavior

In that case, I would add that to enforce this behaviour, it will help if the security group is mandatory to be able to create a VPC, so if users do not define it, VPC will not be created. It is the only way that everybody is aware that a security group should be defined, and finally if users do not want to create it, at least they should "confirm" in a check box that they know the consecuences...

On the other hand, what I am exposing here is more about one default behaviour that has changed from the v4 version of the module and it affects indeed the default behaviour of an AWS security group... let me share some points to explain my opinion better, there are mainly 2 use cases:

• People that were using already previous versions of the module
  • Althought the changelog says manage_default_security_group now defaults to true, they will not be aware that the default rules of the default security group will be deleted because:
    • In the changelog it is not considered a "Breaking change" nor it does not describe the deletion of default rules. In fact, it wouldn't have been awared if I didn't check manually the security group by chance. So it is normal that they consider "manage_default_security_group" as self-explainatory because it does not say manage_default_security_group_from_scratch 😞
    • When running terraform apply command, it does not show that the default rules are removed because it is a new resource creation, not a change.
  • In consecuence, they will be less protected if they do not have create custom security groups created.
• People that start using this module from v5 version
  • They probably will not take a look to the changelog and will start to use the last version
  • This means that they will trust on this module behaviour, so do not suspect that the default rules will be removed.
  • In consecuence, they will be less protected if they do not have create custom security groups created.

It is a fact that modules are used to simplify how some resources are managed. They can be used from proficient and non-proficient users, and in general it is difficult to be an expert regarding how to configure all the resources correctly. From my experience when I use a module I trust on module creators elections and I am confident because if there are some vulnerabilities or misconfigurations they will add the right changes than if I configure all the module components by myself, so it is a time release.

Coming back to your answer, I like that this module because it allows to configure a bunch of network resources in a easy way (even custom security groups!). And because of being easy to use, we should consider that there are users that follow tutorials and they even do not know that there is default security group that has some rules and luckily they are protected (well, more than that because AWS considered already those users and for that reason creates the default rules). A similar situation would be when we talk about "NAT" in a network, it provides a non-intended "security" protection (in this case it is real that nobody designed it to protect) because of the way that it works as private PCs do not have a public reachable IP, some users do not have a firewall but at least it is better than nothing... 😄

If my explanation sounds reasonable, I propose some possible solutions:

1. Restore the defautl behaviour ->manage_default_security_group = false
2. Maintain the current behaviour manage_default_security_group = true but conserving the default rules of the security group

[github-actions[bot]]

This issue has been automatically marked as stale because it has been open 30 days with no activity. Remove stale label or comment or this issue will be closed in 10 days

[github-actions[bot]]

This issue was automatically closed because of stale in 10 days

[luarx]

Wdyt @bryantbiggs?

[github-actions[bot]]

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.