Skip to content

Inconsistent handling of cidr_blocks in *_with_ipv6_cidr_blocks #352

@rogerfar

Description

@rogerfar

Description

There appears to be inconsistent handling of the cidr_blocks vs ipv6_cidr_blocks attribute when using the *_with_ipv6_cidr_blocks helpers in this module.

Specifically:

  • ingress_with_ipv6_cidr_blocks silently ignores cidr_blocks
  • egress_with_ipv6_cidr_blocks appears to accept cidr_blocks and converts it to ipv6_cidr_blocks

This results in a confusing situation where a misconfigured ingress rule produces:

ipv6_cidr_blocks = []

while the equivalent egress rule still produces:

ipv6_cidr_blocks = ["::/0"]

Terraform does not produce any validation error in either case, so the ingress rule silently becomes a no-op.

  • ✋ I have searched the open/closed issues and my issue is not listed.

Versions

  • Module version: 5.3.1

  • Terraform version:
    Terraform v1.14.6 on windows_amd64

  • Provider version(s): v5.100.0

Reproduction Code

terraform {
  required_version = ">= 1.5"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "us-west-2"

  access_key = "mock"
  secret_key = "mock"

  skip_credentials_validation = true
  skip_metadata_api_check     = true
  skip_requesting_account_id  = true
  skip_region_validation      = true

}

resource "aws_vpc" "test" {
  cidr_block = "10.99.0.0/16"

  tags = {
    Name = "ipv6-repro"
  }
}

/**
  * This will produce a proper security group for ipv6.
  */
module "sg_ipv6_working" {
  source  = "terraform-aws-modules/security-group/aws"
  version = "5.3.1"

  name        = "ipv6-working"
  description = "Working IPv6 ingress + egress"
  vpc_id      = aws_vpc.test.id

  ingress_with_ipv6_cidr_blocks = [
    {
      description      = "HTTP IPv6 ingress"
      rule             = "http-80-tcp"
      ipv6_cidr_blocks = "::/0"
    }
  ]

  egress_with_ipv6_cidr_blocks = [
    {
      description      = "HTTPS IPv6 egress"
      rule             = "https-443-tcp"
      ipv6_cidr_blocks = "::/0"
    }
  ]
}

/**
 * The ingress rule will be ignored here, but the egress is created.
 */
module "sg_ipv6_broken" {
  source  = "terraform-aws-modules/security-group/aws"
  version = "5.3.1"

  name        = "ipv6-broken"
  description = "Broken IPv6 ingress + egress"
  vpc_id      = aws_vpc.test.id

  ingress_with_ipv6_cidr_blocks = [
    {
      description = "HTTP IPv6 ingress broken"
      rule        = "http-80-tcp"
      cidr_blocks = "::/0"
    }
  ]

  egress_with_ipv6_cidr_blocks = [
    {
      description = "HTTPS IPv6 egress not broken (questionmark)"
      rule        = "https-443-tcp"
      cidr_blocks = "::/0"
    }
  ]
}

Expected behavior

If cidr_blocks is provided inside *_with_ipv6_cidr_blocks, one of the following should happen:

  • Terraform throws a validation error, or
  • the module consistently maps cidr_blocksipv6_cidr_blocks.

At minimum the behavior should be consistent between ingress and egress helpers.

Actual behavior

The module behaves inconsistently:

Ingress rule

module.sg_ipv6_broken.aws_security_group_rule.ingress_with_ipv6_cidr_blocks[0]

ipv6_cidr_blocks = []

The IPv6 CIDR is silently dropped.

Egress rule

module.sg_ipv6_broken.aws_security_group_rule.egress_with_ipv6_cidr_blocks[0]

ipv6_cidr_blocks = [
  "::/0"
]

The same configuration does work for egress.

So the same mistake produces two different outcomes depending on ingress vs egress.

Additional context

This caused a issue during deployment because the configuration looked correct and Terraform applied successfully, but the IPv6 ingress rule was silently created with:

ipv6_cidr_blocks = []

which effectively results in no IPv6 access in the security group.

Since the module does not validate the input object keys, this misconfiguration is easy to miss.

Ideally the module should either:

  • validate the object schema so cidr_blocks is rejected for IPv6 helpers, or
  • normalize the fields consistently for both ingress and egress.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions