fugue / regula

Regula checks infrastructure as code templates (Terraform, CloudFormation, k8s manifests) for AWS, Azure, Google Cloud, and Kubernetes security and compliance using Open Policy Agent/Rego
https://regula.dev/
Apache License 2.0
960 stars 108 forks source link

[BUG] FG_R00014 is incorrect #285

Open ethpran opened 2 years ago

ethpran commented 2 years ago

Describe the bug According to Terraform resource doc for ASG AZs:

Used for EC2-Classic, attaching a network interface via id from a launch template and default subnets when not specified with vpc_zone_identifier argument. Conflicts with vpc_zone_identifier.

So vpc_zone_identifier is also viable for setting multiple AZs and even preferable because its not for EC2 classic.

How you're running Regula I'm using v2.3.0, build 8bec0ed, built with OPA v0.34.1 and a Terraform plan JSON input that I generated with Terraform v1.0.8

regula run my-modules-dir

Operating System Debian

Steps to reproduce configure Terraform with ASG resource and use vpc_zone_identifier instead of availability_zones

jaspervdj-luminal commented 2 years ago

@ethpran Thanks for reporting this!

I took a quick look and it seems like we are testing for vpc_zone_identifier; but we also test that the corresponding subnets exist, and the latter part can go wrong when we can't infer the link between those resources. This second check is not necessary, so I've created an internal ticket to rectify this -- it should be a fairly simple update.

jaspervdj-luminal commented 2 years ago

@ethpran Sorry it took so long to get back to you -- this bug seems more complex than I originally thought. I've tried replicating it, and I found this approach to work fine:

https://gist.github.com/jaspervdj-luminal/44485c36f73f418ed3308902e7995e83

Note that I put everything in one file explicitly. The rule works by reading the subnets and checking their AZs. This makes me suspect the bug could be caused by the rule not being able to read those AZs.

Perhaps the subnets are passed in through variables? Or maybe there's one subnet using the default AZ? It would be helpful to know a little more there.

As a workaround, we could also assume that any passed in subnets are in different AZs (unless we can tell differently), but I'm not sure if that's the best solution.

Again, my apologies for the late reply!

aduyko commented 1 year ago

Hello,

I'm also running into this issue, in the context of vpc_zone_identifier being a variable consisting of a list of subnet ids that is passed into a Terraform module.

I have also tried configuring something like this:

provider "aws" {
  region = "us-east-1"
}

variable "subnet_ids" {
  type = list(string)
}

data "aws_subnet" "subnets" {
  for_each = toset(var.subnet_ids)
  id = each.value
}

resource "aws_launch_configuration" "foo" {
  name = "test-foo"
  image_id = "ami-0b93ce03dcbcb10f6" # ubuntu focal-20.04 hvm-ssd
  instance_type = "t3.nano"
}

resource "aws_autoscaling_group" "bar" {
  name                      = "test-bar"
  max_size                  = 1
  min_size                  = 0
  desired_capacity          = 0
  launch_configuration      = aws_launch_configuration.foo.name
  vpc_zone_identifier       = [for s in data.aws_subnet.subnets : s.id]
}

But was not having success with this either, with FG_R00014 failing both when scanning the HCL and when scanning a terraform plan generated from the above HCL. Is there a way for the policy to pick up on the data resource? Are issues with FG_R00014 with variables still on your radar to look into, or do you have any suggested workarounds?

Thank you