Open ethpran opened 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.
@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!
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
Describe the bug According to Terraform resource doc for ASG AZs:
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.8Operating System Debian
Steps to reproduce configure Terraform with ASG resource and use
vpc_zone_identifier
instead ofavailability_zones