Are multi-resource configurations not detected by c7n-left or am I doing something wrong? #9181
|
AWS has split a ton of its resource configurations out into independent resources and is moving away from inline configs for lots of security settings. Azure is also doing this in their provider in some areas. This means that most security-related settings one might test for with CC are seen as missing, since the parent resource (like an Very simple example below -- am I doing something wrong, or is c7n-left not currently cabable of detecting things like this? resource "aws_s3_bucket" "cloud_buckets" {
for_each = local.cloud_buckets
bucket = each.key
object_lock_enabled = true
}
resource "aws_s3_bucket_server_side_encryption_configuration" "cloud_buckets" {
for_each = local.cloud_buckets
bucket = each.key
rule {
apply_server_side_encryption_by_default {
sse_algorithm = "AES256"
}
}
} |
Replies: 1 comment 1 reply
|
From testing your case, I think under the hood there's a gap specifically when combining these cross-resource references with But the more general question about multi-resource configurations is still a useful thing to cover! That situation was the motivation behind the traverse filter. Your S3 case is a useful example, because you need to be able to catch server-side encryption defaults defined inline or in the separate resource. A policy like this could check both variations: policies:
- name: aws-s3-bucket-sse-defaults
description: >
All S3 buckets should have server-side encryption enabled
by default.
resource: terraform.aws_s3_bucket
filters:
- server_side_encryption_configuration.rule.apply_server_side_encryption_by_default.sse_algorithm: absent
- not:
- type: traverse
resources:
- aws_s3_bucket_server_side_encryption_configuration
attrs:
- key: rule.apply_server_side_encryption_by_default.sse_algorithm
value: presentSo for this Terraform: resource "aws_s3_bucket" "sse_unspecified" {
bucket = "sse_unspecified"
}
resource "aws_s3_bucket" "sse_enabled_inline" {
bucket = "sse_enabled_inline"
server_side_encryption_configuration {
rule {
apply_server_side_encryption_by_default {
sse_algorithm = "AES256"
}
}
}
}
resource "aws_s3_bucket" "sse_enabled_separately" {
bucket = "sse_enabled_separately"
}
resource "aws_s3_bucket_server_side_encryption_configuration" "sse_enabled_separately" {
bucket = aws_s3_bucket.sse_enabled_separately.id
rule {
apply_server_side_encryption_by_default {
sse_algorithm = "AES256"
}
}
}You would get one match/violation: Running 1 policies on 4 resources
aws-s3-bucket-sse-defaults - terraform.aws_s3_bucket
Failed
Reason: All S3 buckets should have server-side encryption enabled by default.
File: main.tf:1-3
1 resource "aws_s3_bucket" "sse_unspecified" {
2 bucket = "sse_unspecified"
3 }
Evaluation complete 0.01 seconds -> 1 Failures
Summary - By Policy
┏━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━┓
┃ Severity ┃ Policy ┃ Result ┃
┡━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━┩
│ unknown │ aws-s3-bucket-sse-defaults │ 1 failed 2 passed │
└──────────┴────────────────────────────┴───────────────────┘
2 compliant of 4 total, 1 resources have 1 policy violations, 1 resources unevaluated |
From testing your case, I think under the hood there's a gap specifically when combining these cross-resource references with
for_eachloops. I've filed a bug for that here.But the more general question about multi-resource configurations is still a useful thing to cover! That situation was the motivation behind the traverse filter. Your S3 case is a useful example, because you need to be able to catch server-side encryption defaults defined inline or in the separate resource. A policy like this could check both variations: