lacework / terraform-aws-agentless-scanning

Terraform module for configuring an integration with Lacework and AWS for agentless scanning
MIT License
4 stars 9 forks source link

bug: default network ACL not being associated with subnet causes recurring drift in Terraform plan #114

Closed reggora-mmatney closed 1 year ago

reggora-mmatney commented 1 year ago

Describe the bug

It looks like this change https://github.com/lacework/terraform-aws-agentless-scanning/pull/101 released yesterday https://github.com/lacework/terraform-aws-agentless-scanning/releases/tag/v0.14.0 might have introduced a bug that causes a reoccurring drift in the Terraform plan.

The new aws_default_network_acl resource added in https://github.com/lacework/terraform-aws-agentless-scanning/pull/101 adopts the default network ACL, which is expected.

However, the new resource configuration does not include an explicit association with the agentless_scan_public_subnet created here - https://github.com/lacework/terraform-aws-agentless-scanning/blob/2ba767d27d01e493f1a6433bce206644a15b2d52/main.tf#L937-L948

If you refer to the AWS provider documentation - https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/default_network_acl#managing-subnets-in-a-default-network-acl

Because Subnets are by default associated with the Default Network ACL, any non-explicit association will show up as a plan to remove the Subnet

Since the agentless_scan_public_subnet is not explicitly associated with the new default network ACL, it is resulting in a permanent drift in the Terraform state where the implicit association of the subnet is removed on every plan

Steps to reproduce

Update Lacework module to v0.14.0 and run terraform plan. The plan will show a change to remove the subnet id association from the default network ACL resource. When applied, the subnet gets immediately re-associated with the default network ACL by AWS since within a VPC, all subnets must be associated with a network ACL. The subsequent plan then shows the change to remove the subnet id association from the default network ACL resource. Rinse and repeat.

Expected behavior

The plan should not show a change to disassociate the subnet from the default network ACL.

Screenshots

image

Version Information

Additional context

This should be fixed by adding the agentless_scan_public_subnet id to the subnet_ids argument in the default network ACL resource

E.G. something like

resource "aws_default_network_acl" "default" {
  count                  = var.regional && !var.use_existing_vpc ? 1 : 0
  default_network_acl_id = aws_vpc.agentless_scan_vpc[0].default_network_acl_id

  subnet_ids = [aws_subnet.agentless_scan_public_subnet.id]

  egress {
    protocol   = -1
    rule_no    = 100
    action     = "allow"
    cidr_block = "0.0.0.0/0"
    from_port  = 0
    to_port    = 0
  }

  ingress {
    protocol   = 6
    rule_no    = 101
    action     = "allow"
    cidr_block = "0.0.0.0/0"
    from_port  = 1024
    to_port    = 65535
  }
}
theopolis commented 1 year ago

Thanks for the wonderfully detailed bug report, working on this right now.

reggora-mmatney commented 1 year ago

Thanks @theopolis! Can we expect this to be patched in v0.14.1 and is there a rough timeline on when it will be released?

theopolis commented 1 year ago

Thanks for your patience, I know this bug is frustrating, I will schedule a release soon.