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

egress_with_prefix_list_ids should have attribute prefix_list_ids #312

Open
estahn opened this issue Jan 26, 2024 · 4 comments
Open

egress_with_prefix_list_ids should have attribute prefix_list_ids #312

estahn opened this issue Jan 26, 2024 · 4 comments

Comments

@estahn
Copy link

estahn commented Jan 26, 2024

Description

The usage of prefix lists is fairly confusing as described in #224 and #226. Unfortunately those issues/PRs were closed without feedback. What is the reasoning behind it and would it be possible to change it to something like below?

Current:

  egress_prefix_list_ids = [module.vpc_endpoints.endpoints["s3"].prefix_list_id]
  egress_with_prefix_list_ids = [
    {
      rule        = "all-all"
      description = "Allow access to VPC Endpoint for S3"
    }
  ]

Expected:

  egress_with_prefix_list_ids = [
    {
      rule        = "all-all"
      description = "Allow access to VPC Endpoint for S3"
      prefix_list_ids = [module.vpc_endpoints.endpoints["s3"].prefix_list_id]
    }
  ]

See:

prefix_list_ids = var.egress_prefix_list_ids

Versions

  • Module version [Required]: 5.1.0
  • Terraform version: v1.4.6

Reproduction Code [Required]

Steps to reproduce the behavior:

Expected behavior

  egress_with_prefix_list_ids = [
    {
      rule        = "all-all"
      description = "Allow access to VPC Endpoint for S3"
      prefix_list_ids = [module.vpc_endpoints.endpoints["s3"].prefix_list_id]
    }
  ]

Actual behavior

  egress_prefix_list_ids = [module.vpc_endpoints.endpoints["s3"].prefix_list_id]
  egress_with_prefix_list_ids = [
    {
      rule        = "all-all"
      description = "Allow access to VPC Endpoint for S3"
    }
  ]

Terminal Output Screenshot(s)

Additional context

Copy link

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 github-actions bot added the stale label Feb 26, 2024
@Cafeine42
Copy link

Cafeine42 commented Mar 7, 2024

In the current state, it is impossible to create an SG and give access to both a prefix list and a cidr. The first crushing the second.

module "alb" {
  source  = "terraform-aws-modules/security-group/aws"
  version = "5.1.1"

  name        = "some-alb"
  description = "Allow HTTP inbound traffic"
  vpc_id      = var.vpc_id

  ingress_prefix_list_ids = [data.aws_ec2_managed_prefix_list.cloudfront.id]

  ingress_with_cidr_blocks = [
    {
      description = "Allow HTTP inbound"
      rule        = "https-443-tcp"
      cidr_block  = "1.1.1.1/32"
    },
  ]

  egress_rules       = ["all-all"]
  egress_cidr_blocks = ["0.0.0.0/0"]
}

With this configuration, only one ingress rule is created with prefix list, the cidr is ignored

@github-actions github-actions bot removed the stale label Mar 8, 2024
@pyo-counting
Copy link

pyo-counting commented Mar 24, 2024

I also wanna create a rule for AWS managed prefix list. But, the variable for prefix is now given as *_prefix_list_ids, so it is basically added to every rules.

In the example, this feature appears to be possible, but it is not actually.

prefix_list_ids = join(",", [data.aws_prefix_list.s3.id, data.aws_prefix_list.dynamodb.id])

@mission-coliveros
Copy link

mission-coliveros commented Apr 19, 2024

+1 on this. The prefix_list_ids functionality of this module is hard to work with, and unfortunately I have to break out my prefix list security group rules into individual aws_security_group_rule resource calls.

Ideally, I'd be able to pass in prefix list IDs on a per-rule basis for both ingress and egress rules

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants