Replies: 1 comment 7 replies
-
|
Hi @nitrocode ! You can ignore misconfigurations by resource parameters https://aquasecurity.github.io/trivy/v0.54/docs/scanner/misconfiguration/#ignoring-by-attributes |
Beta Was this translation helpful? Give feedback.
-
|
Oh I see. I understood what you meant before but I was unsure of how to tie it back to a unique set of inputs coming from my tfvars. This seems to work for me because s3 bucket names are global so if I use an ignore inline code exclusion for the name, then I can stack them. # ue1-dev-my-dev-bucket.tfvars
name = "my-dev-bucket"
kms_master_key_arn = ""variable "kms_master_key_arn" {}
variable "name" {}
#trivy:ignore:avd-aws-0132[name=my-dev-bucket]
#trivy:ignore:avd-aws-0132[name=my-xyz-bucket]
module "s3_bucket" {
source = "cloudposse/s3-bucket/aws"
name = var.name
enabled = true
s3_object_ownership = "BucketOwnerEnforced"
versioning_enabled = true
logging = [{
bucket_name = "app"
prefix = "logs/"
}]
kms_master_key_arn = var.kms_master_key_arn
}This works for me and is far easier than a custom rego policy combined with custom data. Thanks a lot! |
Beta Was this translation helpful? Give feedback.
-
|
One last thing, if I did want to use an ignore rego file to ignore based on an attribute, is that possible? I'd prefer to avoid inline comments all together if possible by using an ignore file such as this. trivy config --tf-vars=ue1-dev-my-dev-bucket.tfvars --ignore-policy ./ignore/policy.rego --config-policy policy --config-data data/ --trace --debug . -f jsonpackage trivy
import data.lib.trivy
default ignore = false
ignore {
input.name == "my-dev-bucket"
input.ID == "AVD-AWS-0132"
}The above doesn't seem to work because the tfvars inputs aren't available in the outputted json file. Maybe if the attributes of the module/resource definition were exposed to the json then I could reproduce what I'm doing in the inline comment within the rego. ignore {
input.module.s3_bucket.name == "my-dev-bucket"
input.ID == "AVD-AWS-0132"
}Is there a way to make the tfvar input or module attributes available to the ignore file ? Maybe with custom data? I tried with custom data too and couldn't figure it out with this use case Or maybe with the trivy ignore file? |
Beta Was this translation helpful? Give feedback.
-
|
This looks promising to me because it should be able to ignore based on the attribute/argument of the module in a separate ignore file instead of modifying the terraform code. |
Beta Was this translation helpful? Give feedback.
-
|
cc: @nikpivkin @simar7 what do you folks think? Even with the upcoming #7180 in the upcoming v0.55.0, I think the custom ignore rego policy would still come in handy provided that the inputs are available to the rego. |
Beta Was this translation helpful? Give feedback.
-
|
We will get back to you on this. |
Beta Was this translation helpful? Give feedback.
-
Description
I use workspaces to reuse terraform root directories
For example, the terraform code to provision an s3 bucket is located here
I setup workspaces such as this
My
ue1-dev-my-bucket2.tfvarscontainsMy
ue1-prod-my-bucket3.tfvarscontainsThen I run trivy for ue1-prod and no issues.
When I run trivy for ue1-dev, I have one issue.
How do I only suppress this issue for
ue1-dev-my-bucket2.tfvarsand notue1-prod-my-bucket3.tfvars?I can technically do this but this will suppress for both my tfvars files.
I cannot add the comment in beside the input directly to the tfvars file. It seems it has to be in before the module definition.
e.g.
I looked into filtering using the ignore file which would essentially be the same thing as the module definition inline comment.
https://aquasecurity.github.io/trivy/test/docs/configuration/filtering/#by-finding-ids
I looked into filtering by open policy agent
https://aquasecurity.github.io/trivy/test/docs/configuration/filtering/#by-open-policy-agent
This has some promise but looking at the json output, I don't see any way to ignore based on the inputs. Do I have the ability to see which individual inputs were passed in to the outputted json?
Here is my output json
{ "SchemaVersion": 2, "CreatedAt": "2024-08-29T18:19:07.025472-05:00", "ArtifactName": ".", "ArtifactType": "filesystem", "Metadata": { "ImageConfig": { "architecture": "", "created": "0001-01-01T00:00:00Z", "os": "", "rootfs": { "type": "", "diff_ids": null }, "config": {} } }, "Results": [ { "Target": ".", "Class": "config", "Type": "terraform", "MisconfSummary": { "Successes": 3, "Failures": 0, "Exceptions": 0 } }, { "Target": "cloudposse/s3-bucket/aws/cloudposse/iam-s3-user/aws/cloudposse/iam-system-user/aws/main.tf", "Class": "config", "Type": "terraform", "MisconfSummary": { "Successes": 1, "Failures": 0, "Exceptions": 0 } }, { "Target": "cloudposse/s3-bucket/aws/main.tf", "Class": "config", "Type": "terraform", "MisconfSummary": { "Successes": 8, "Failures": 1, "Exceptions": 0 }, "Misconfigurations": [ { "Type": "Terraform Security Check", "ID": "AVD-AWS-0132", "AVDID": "AVD-AWS-0132", "Title": "S3 encryption should use Customer Managed Keys", "Description": "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.", "Message": "Bucket does not encrypt data with a customer managed key.", "Query": "data..", "Resolution": "Enable encryption using customer managed keys", "Severity": "HIGH", "PrimaryURL": "https://avd.aquasec.com/misconfig/avd-aws-0132", "References": [ "https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-encryption.html", "https://avd.aquasec.com/misconfig/avd-aws-0132" ], "Status": "FAIL", "Layer": {}, "CauseMetadata": { "Resource": "module.s3_bucket", "Provider": "AWS", "Service": "s3", "StartLine": 80, "EndLine": 94, "Code": { "Lines": [ { "Number": 80, "Content": "resource \"aws_s3_bucket_server_side_encryption_configuration\" \"default\" {", "IsCause": true, "Annotation": "", "Truncated": false, "Highlighted": "\u001b[0m\u001b[38;5;33mresource\u001b[0m \u001b[38;5;37m\"aws_s3_bucket_server_side_encryption_configuration\"\u001b[0m \u001b[38;5;37m\"default\"\u001b[0m {", "FirstCause": true, "LastCause": false }, { "Number": 81, "Content": " count = local.enabled ? 1 : 0", "IsCause": true, "Annotation": "", "Truncated": false, "Highlighted": " \u001b[38;5;245mcount\u001b[0m = local.enabled \u001b[38;5;245m?\u001b[0m \u001b[38;5;37m1\u001b[0m \u001b[38;5;245m:\u001b[0m \u001b[38;5;37m0", "FirstCause": false, "LastCause": false }, { "Number": 82, "Content": "", "IsCause": true, "Annotation": "", "Truncated": false, "Highlighted": "\u001b[0m", "FirstCause": false, "LastCause": false }, { "Number": 83, "Content": " bucket = local.bucket_id", "IsCause": true, "Annotation": "", "Truncated": false, "Highlighted": " \u001b[38;5;245mbucket\u001b[0m = local.bucket_id", "FirstCause": false, "LastCause": false }, { "Number": 84, "Content": " expected_bucket_owner = var.expected_bucket_owner", "IsCause": true, "Annotation": "", "Truncated": false, "Highlighted": " \u001b[38;5;245mexpected_bucket_owner\u001b[0m = \u001b[38;5;33mvar\u001b[0m.expected_bucket_owner", "FirstCause": false, "LastCause": false }, { "Number": 85, "Content": "", "IsCause": true, "Annotation": "", "Truncated": false, "FirstCause": false, "LastCause": false }, { "Number": 86, "Content": " rule {", "IsCause": true, "Annotation": "", "Truncated": false, "Highlighted": " rule {", "FirstCause": false, "LastCause": false }, { "Number": 87, "Content": " bucket_key_enabled = var.bucket_key_enabled", "IsCause": true, "Annotation": "", "Truncated": false, "Highlighted": " \u001b[38;5;245mbucket_key_enabled\u001b[0m = \u001b[38;5;33mvar\u001b[0m.bucket_key_enabled", "FirstCause": false, "LastCause": false }, { "Number": 88, "Content": "", "IsCause": true, "Annotation": "", "Truncated": false, "FirstCause": false, "LastCause": true }, { "Number": 89, "Content": "", "IsCause": false, "Annotation": "", "Truncated": true, "FirstCause": false, "LastCause": false } ] }, "Occurrences": [ { "Resource": "module.s3_bucket", "Filename": "main.tf", "Location": { "StartLine": 3, "EndLine": 20 } } ] } } ] } ] }Desired Behavior
It would be nice to suppress/ignore directly in my tfvars files per input that triggers the issue
Or use a rego policy with the context of each individual tfvars, including tfvars file, to suppress/ignore
Actual Behavior
I only have 2 options
Reproduction Steps
See above
Target
AWS
Scanner
Misconfiguration
Output Format
JSON
Mode
Standalone
Debug Output
Operating System
maxOS Sonoma
Version
Checklist
trivy clean --allreferences
Beta Was this translation helpful? Give feedback.
All reactions