fix(terraform): Trivy scans local modules #4988
Assignees
Labels
kind/bug
Categorizes issue or PR as related to a bug.
scan/misconfiguration
Issues relating to misconfiguration scanning
Milestone
Comments
nikpivkin
added
kind/bug
|
By the way, Trivy says that he found 3 configuration files, but there are only 2 of them: tree
.
├── main.tf
└── modules
└── s3
└── main.tf |
This is probably why 2023-08-14T16:47:42.303-0600 DEBUG Scanned config file: modules/s3
2023-08-14T16:47:42.303-0600 DEBUG Scanned config file: modules/s3/main.tf
2023-08-14T16:47:42.303-0600 DEBUG Scanned config file: .tree -a
.
├── main.tf
└── modules
└── s3
└── main.tf
3 directories, 2 files |
|
In such case, what output do you expect to see? Two cases can be made:
Another option we can have is main.tf:3
via modules/s3/main.tf:12 |
|
@simar7 I expect to see the same result as when using remote modules, for example from the terraform registry. This rather refers to the module "s3_bucket" {
source = "terraform-aws-modules/s3-bucket/aws"
bucket = "my-s3-bucket"
acl = "private"
control_object_ownership = true
object_ownership = "ObjectWriter"
}Output: trivy config . -d
2023-08-15T09:37:35.684+0700 DEBUG Severities: ["UNKNOWN" "LOW" "MEDIUM" "HIGH" "CRITICAL"]
2023-08-15T09:37:35.693+0700 DEBUG cache dir: /Users/tososomaru/Library/Caches/trivy
2023-08-15T09:37:35.693+0700 DEBUG Module dir: /Users/tososomaru/.trivy/modules
2023-08-15T09:37:35.693+0700 INFO Misconfiguration scanning is enabled
2023-08-15T09:37:35.693+0700 DEBUG Policies successfully loaded from disk
2023-08-15T09:37:35.714+0700 DEBUG Walk the file tree rooted at '.' in parallel
2023-08-15T09:37:35.715+0700 DEBUG Scanning Terraform files for misconfigurations...
2023-08-15T09:37:39.460+0700 DEBUG OS is not detected.
2023-08-15T09:37:39.460+0700 INFO Detected config files: 2
2023-08-15T09:37:39.460+0700 DEBUG Scanned config file: .
2023-08-15T09:37:39.460+0700 DEBUG Scanned config file: git::https:/github.com/terraform-aws-modules/terraform-aws-s3-bucket?ref=v3.14.1/main.tf
git::https:/github.com/terraform-aws-modules/terraform-aws-s3-bucket?ref=v3.14.1/main.tf (terraform)
Tests: 11 (SUCCESSES: 6, FAILURES: 5, EXCEPTIONS: 0)
Failures: 5 (UNKNOWN: 0, LOW: 1, MEDIUM: 2, HIGH: 2, CRITICAL: 0)
HIGH: Bucket does not have encryption enabled
═══════════════════════════════════════════════════════════════════════════════════════════
S3 Buckets should be encrypted to protect the data that is stored within them if access is compromised.
See https://avd.aquasec.com/misconfig/avd-aws-0088
───────────────────────────────────────────────────────────────────────────────────────────
git::https:/github.com/terraform-aws-modules/terraform-aws-s3-bucket?ref=v3.14.1/main.tf:21-30
───────────────────────────────────────────────────────────────────────────────────────────
21 ┌ resource "aws_s3_bucket" "this" {
22 │ count = local.create_bucket ? 1 : 0
23 │
24 │ bucket = var.bucket
25 │ bucket_prefix = var.bucket_prefix
26 │
27 │ force_destroy = var.force_destroy
28 │ object_lock_enabled = var.object_lock_enabled
29 │ tags = var.tags
30 └ }
───────────────────────────────────────────────────────────────────────────────────────────
MEDIUM: Bucket does not have logging enabled
═══════════════════════════════════════════════════════════════════════════════════════════
Buckets should have logging enabled so that access can be audited.
See https://avd.aquasec.com/misconfig/avd-aws-0089
───────────────────────────────────────────────────────────────────────────────────────────
git::https:/github.com/terraform-aws-modules/terraform-aws-s3-bucket?ref=v3.14.1/main.tf:21-30
───────────────────────────────────────────────────────────────────────────────────────────
21 ┌ resource "aws_s3_bucket" "this" {
22 │ count = local.create_bucket ? 1 : 0
23 │
24 │ bucket = var.bucket
25 │ bucket_prefix = var.bucket_prefix
26 │
27 │ force_destroy = var.force_destroy
28 │ object_lock_enabled = var.object_lock_enabled
29 │ tags = var.tags
30 └ }
───────────────────────────────────────────────────────────────────────────────────────────
MEDIUM: Bucket does not have versioning enabled
═══════════════════════════════════════════════════════════════════════════════════════════
Versioning in Amazon S3 is a means of keeping multiple variants of an object in the same bucket.
You can use the S3 Versioning feature to preserve, retrieve, and restore every version of every object stored in your buckets.
With versioning you can recover more easily from both unintended user actions and application failures.
See https://avd.aquasec.com/misconfig/avd-aws-0090
───────────────────────────────────────────────────────────────────────────────────────────
git::https:/github.com/terraform-aws-modules/terraform-aws-s3-bucket?ref=v3.14.1/main.tf:21-30
───────────────────────────────────────────────────────────────────────────────────────────
21 ┌ resource "aws_s3_bucket" "this" {
22 │ count = local.create_bucket ? 1 : 0
23 │
24 │ bucket = var.bucket
25 │ bucket_prefix = var.bucket_prefix
26 │
27 │ force_destroy = var.force_destroy
28 │ object_lock_enabled = var.object_lock_enabled
29 │ tags = var.tags
30 └ }
───────────────────────────────────────────────────────────────────────────────────────────
HIGH: Bucket does not encrypt data with a customer managed key.
═══════════════════════════════════════════════════════════════════════════════════════════
Encryption using AWS keys provides protection for your S3 buckets. To increase control of the encryption and manage factors like rotation use customer managed keys.
See https://avd.aquasec.com/misconfig/avd-aws-0132
───────────────────────────────────────────────────────────────────────────────────────────
git::https:/github.com/terraform-aws-modules/terraform-aws-s3-bucket?ref=v3.14.1/main.tf:21-30
───────────────────────────────────────────────────────────────────────────────────────────
21 ┌ resource "aws_s3_bucket" "this" {
22 │ count = local.create_bucket ? 1 : 0
23 │
24 │ bucket = var.bucket
25 │ bucket_prefix = var.bucket_prefix
26 │
27 │ force_destroy = var.force_destroy
28 │ object_lock_enabled = var.object_lock_enabled
29 │ tags = var.tags
30 └ }
───────────────────────────────────────────────────────────────────────────────────────────
LOW: Bucket has logging disabled
═══════════════════════════════════════════════════════════════════════════════════════════
Ensures S3 bucket logging is enabled for S3 buckets.
See https://avd.aquasec.com/misconfig/n/a
───────────────────────────────────────────────────────────────────────────────────────────
git::https:/github.com/terraform-aws-modules/terraform-aws-s3-bucket?ref=v3.14.1/main.tf:21-30
───────────────────────────────────────────────────────────────────────────────────────────
21 ┌ resource "aws_s3_bucket" "this" {
22 │ count = local.create_bucket ? 1 : 0
23 │
24 │ bucket = var.bucket
25 │ bucket_prefix = var.bucket_prefix
26 │
27 │ force_destroy = var.force_destroy
28 │ object_lock_enabled = var.object_lock_enabled
29 │ tags = var.tags
30 └ }
───────────────────────────────────────────────────────────────────────────────────────────As you can see, there is no duplication. |
|
It's unclear to me what needs to be done here. @nikpivkin can you elaborate? |
|
@simar7 I expect Trivy to not scan child local modules as separate configurations (same behavior as with remote modules). |
|
I don't know why, but this change breaks subfolders in the most strange manner. E.g., if you put the files in the original issue like this:
Executing Executing Executing I would assume all 3 cases to yield the same result. |
|
Hi @kernle32dll ! Could you please share the configuration files? I could not reproduce your problem with the sample files above. |
Okay, I have no idea what I was doing yesterday, but I can't actually replicate the issue now. I do have the issue with my actual terraform project files, but I cannot share them at this point. I will try to condense a version that I can share. |
|
Okay, I have "something". The setup is a bit lengthy, and I am not entirely sure what I am seeing here. But the kicker is for the terraform files to be in a subfolder (
module "s3" {
source = "./modules/s3"
}
module "backup" {
source = "git::https://github.com/terraform-google-modules/terraform-google-vm.git?ref=v10.1.0"
}
variable "s3_object_versioning" {
description = "Enable S3 Object Versioning [Enabled Suspended Disabled]"
type = string
validation {
condition = contains(["Enabled", "Suspended", "Disabled"], var.s3_object_versioning)
error_message = "The Variable s3_object_versioning can only contain [Enabled, Suspended, Disabled]"
}
}
resource "aws_s3_bucket" "s3_bucket" {
bucket = "test.bucket"
}
resource "aws_s3_bucket_versioning" "versioning" {
bucket = aws_s3_bucket.s3_bucket.id
versioning_configuration {
status = var.s3_object_versioning
}
}
First, test with But if we do an terraform init now... ... The output changes. Note how it includes the When using I hope someone can make some sense of this. |
|
Okay, a little addendum. I poked around a bit a defsec, and I know now why this code change triggers the problem but I have no idea about the root cause. So its probably a good idea to move this discussion to a defsec issue, if anyone knows how to formulate an issue from my observation. So, with the above example, what essentially happens is that we end up with a rouge module here, which has a child module with a
My hunch is that this module is somehow referencing itself or something. I spent not enough time with defsec to make sense of this, so this needs to be resolved by someone more clever then me. |
|
Hi @kernle32dll ! This will be fixed after the merger #5245 In the screenshot everything is ok. RootModule is a kind of module container, which has no references from other modules, i.e. it is a self-sufficient application. The childs field contains all the modules in flat form that are declared in this application. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have the following files:
modules/s3/main.tfmain.tfOutput of Trivy:
Some misconfigs are duplicated, since Trivy also scans local modules.
The text was updated successfully, but these errors were encountered: