CKV2_AWS_5 false-positives

[acdha]

It's not clear what the intention of this rule was since the documentation is mostly empty but it's triggering incorrectly:

https://docs.bridgecrew.io/docs/ensure-that-security-groups-are-attached-to-ec2-instances-or-elastic-network-interfaces-enis

I think there are a number of valid conditions which can trigger this:

• Security groups using the listed group as an ingress or egress target
• Security groups being passed as variables to a module
• Security groups being used for non-EC2 resources such as ECS

This may be fixed in #1186

[eric-kinsa]

@acdha I don't believe it was fixed in that PR you linked. I started getting several CKV2_AWS_5 false positives on security groups that clearly attached to ENI's and using the version with that code change.

[schosterbarak]

hi @eric-kinsa can you give a code snapshot we can use to test this one?

[acdha]

Not sure if #1186 shipped in 2.0.165 but if it did, I'm still seeing this for security groups which are assigned to ECS services:

resource "aws_security_group" "search" {
  name        = "${local.deployment_id}-search"
  description = "${local.deployment_id} Search"
  vpc_id      = module.vpc.vpc_id

  tags = {
    "Name" = "${local.deployment_id} Search",
  }
}

(That group is used by an ECS service)

I also see this for a group used for VPC endpoints which allows ingress from various CIDR ranges and is configured for the endpoint services (SES and EFS).

[eric-kinsa]

Sorry for the late reply. Here's a couple that come up that I verified are attached to an ENI:

Both are these are created within a module.

Attached to a ClientVPN Endpoint resource:

resource "aws_security_group" "vpn_sg" {
  vpc_id = aws_vpc.main.id
  name   = "vpn-sg"

  tags = {
    Name        = "vpn"
    environment = "vpn"
    terraform   = "true"
  }
}

RDSNetworkInterface

resource "aws_security_group" "postgres" {
  name        = "${var.app}-postgres-${var.env}"
  description = "Allow db traffic for ${var.app} in ${var.env}"
  vpc_id      = data.aws_vpc.main.id

  ingress {
    from_port = 0
    to_port   = 0
    protocol  = "-1"
    self      = true
  }
  tags = {
    environment = var.env
    Name        = "${var.app}-postgres-${var.env}"
    terraform   = "true"
  }
}

[etscheid-devk]

Hi, yes I see this also if the SG is attached to RDS, VPC Endpoints, Redshift,... Here a working example that throws a false positive for the CKV2_AWS-5:

`resource "aws_vpc" "this" { cidr_block = "10.0.0.0/16" }

resource "aws_db_instance" "default" { allocated_storage = 10 engine = "mysql" engine_version = "5.7" instance_class = "db.t3.micro" name = "mydb" username = "foo" password = "foobarbaz" parameter_group_name = "default.mysql5.7" skip_final_snapshot = true vpc_security_group_ids = [aws_security_group.this.id] }

resource "aws_security_group" "this" { name = "this" vpc_id = aws_vpc.this.id }`

[yuriy-murdza-tm]

Also, this issue is present when use terraform concat function:

resource "aws_security_group" "instance" { name = local.security_group_name description = "Security Group for ${var.name_prefix}" vpc_id = data.aws_vpc.vpc.id lifecycle { create_before_destroy = true } }

#autoscaling_module security_group_ids = concat([aws_security_group.instance.id], var.additional_security_group_ids)

Thanks you.

[ericdeflaminis]

I started seeing this today on LB resources out of the blue, same code and versions. Not sure if it's related but definitely a false positive on my end. A simplified example below:

###Load Balancer
resource "aws_lb" "alb" {
  name               = "${var.application}-${var.tier}-alb"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.app.id]
  subnets            = data.aws_subnet_ids.public_subs.ids
  idle_timeout       = "60"
  tags = local.common_tags
}

resource "aws_security_group" "app" {
  name        = "${var.application}-${var.tier}-sg"
  description = "Security group for LB"
  vpc_id      = data.aws_vpc.vpc_base.id

  egress {
    from_port   = var.port
    to_port     = var.port
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  tags = local.common_tags
}

[acdha]

I retested this after #1186 and am seeing it on groups attached to ECS, RDS, VPC Endpoints, and EC2 servers. Some of this may be due to my use of modules:

resource "aws_security_group" "moc_servers" {
  name        = "${local.deployment_id}-moc"
  description = "${local.deployment_id} MOC Servers"
  vpc_id      = module.vpc.vpc_id

  tags = {
    "Name" = "${local.deployment_id} MOC Servers",
  }
}
…
module "moc_server" {
  source = "./cis_server/"
  count  = var.moc_server_instance_count
…
  vpc_security_group_ids      = [aws_security_group.moc_servers.id]
}

module "vpc_endpoints" {
  source             = "terraform-aws-modules/vpc/aws//modules/vpc-endpoints"
  vpc_id             = module.vpc.vpc_id
  security_group_ids = [aws_security_group.vpc_endpoints.id]

[coffeecoco]

I see same problem as @acdha when using aws_security_group and a module, it does not seem to work out its attached to the module

[frek818]

I am seeing this issue when using the security group on an RDS database.

resource "aws_rds_cluster" "rds" {
  ...
  vpc_security_group_ids = [ aws_security_group.rds[0].id ]
  ...
}

[MooreDerek]

@schosterbarak This issue is a problem with the documentation on the site being out of date. The link referred to at the start - https://docs.bridgecrew.io/docs/ensure-that-security-groups-are-attached-to-ec2-instances-or-elastic-network-interfaces-enis is no longer valid as the check is now to check that the SG is associated a resource -> https://github.com/bridgecrewio/checkov/blob/master/checkov/terraform/checks/graph_checks/aws/SGAttachedToResource.yaml#L2 IMO, issue can be closed as working as expected, but the website needs to be refreshed. This behaviour was introduced in #1186

[divY42]

Issue is not only about refering to an outdated documentation. I'm still seeing a failure when for e.g. using "terraform-aws-modules/vpc/aws//modules/vpc-endpoints" even though my security group is attached to the VPC endpoint.

According to https://github.com/bridgecrewio/checkov/blob/master/checkov/terraform/checks/graph_checks/aws/SGAttachedToResource.yaml#L2 aws_vpc_endpoint is listed under connected_resource_types.

[acdha]

IMO, issue can be closed as working as expected, but the website needs to be refreshed. This behaviour was introduced in #1186

With the regression introduced in #1186, Checkov becomes extremely noisy with large numbers of false-positives for CKV2_AWS_5. As far as I can tell, this happens any time the security group isn't referenced in the same file it occurs in — for example, I have a project with a top-level security-groups.tf file and module invocations which reference the created groups. Every one of those is flagged even though those groups are referenced in the adjacent main.tf, with the exception of the ones which are referenced by other groups in the same file.

[stale[bot]]

Thanks for contributing to Checkov! We've automatically marked this issue as stale to keep our issues list tidy, because it has not had any activity for 6 months. It will be closed in 14 days if no further activity occurs. Commenting on this issue will remove the stale tag. If you want to talk through the issue or help us understand the priority and context, feel free to add a comment or join us in the Checkov slack channel at https://slack.bridgecrew.io Thanks!

[rrey-aviatrix]

Seeing a CKV2_AWS_5 failure while the sg is referenced in a aws_ec2_client_vpn_endpoint resource in its security_group_ids.

Edit: Using checkov 2.1.240 on Terraform code.

[vinayakapai]

Seeing CKV2_AWS_5 failure when the sg is referenced in aws_ecs_service resource's security_groups.

resource "aws_security_group" "sg_1" {
   ...
}

resource "aws_ecs_service" "ecs_1" {
  ...
  network_configuration {
    ...
    security_groups = [aws_security_group.sg_1.id]
  }
}

Checkcov: 2.2.3

[stale[bot]]

Thanks for contributing to Checkov! We've automatically marked this issue as stale to keep our issues list tidy, because it has not had any activity for 6 months. It will be closed in 14 days if no further activity occurs. Commenting on this issue will remove the stale tag. If you want to talk through the issue or help us understand the priority and context, feel free to add a comment or join us in the Checkov slack channel at https://slack.bridgecrew.io Thanks!

[stale[bot]]

Closing issue due to inactivity. If you feel this is in error, please re-open, or reach out to the community via slack: https://slack.bridgecrew.io Thanks!

[edmundcraske-bjss]

Not sure why this got closed as it clearly hasn't been fixed...

[JamesWoolfenden]

which resource are you seeing it fail for @edmundcraske-bjss

[edmundcraske-bjss]

I'm seeing it when used on aws_codebuild_project, though it might be down to the way that I'm using it to be honest! It just seemed like a load of different ways had been mentioned that this could go wrong and no clear response or fix and the ticket just got closed because nobody touched it in a while. Maybe most of the things mentioned have been fixed now but it's not obvious from looking at the issue 😅

[JamesWoolfenden]

I'm seeing it when used on aws_codebuild_project, though it might be down to the way that I'm using it to be honest! It just seemed like a load of different ways had been mentioned that this could go wrong and no clear response or fix and the ticket just got closed because nobody touched it in a while. Maybe most of the things mentioned have been fixed now but it's not obvious from looking at the issue 😅

That check already supports aws_codebuild_project so its probably something about the usage, maybe your specifing by name rather than resource?

[edmundcraske-bjss]

Definitely referencing as a resource, maybe it's because it's in a concat() function?

[miunsag]

I also have a false positive for ECS service that is clearly attaching the security group. However, as mentioned above, I am using modules, the security part is separated from the ECS part.

[JamesWoolfenden]

I also have a false positive for ECS service that is clearly attaching the security group. However, as mentioned above, I am using modules, the security part is separated from the ECS part.

Without seeing the design of your code, you may have encountered a known limitation.