bridgecrewio / checkov

Prevent cloud misconfigurations and find vulnerabilities during build-time in infrastructure as code, container images and open source packages with Checkov by Bridgecrew.
https://www.checkov.io/
Apache License 2.0
7.07k stars 1.11k forks source link

CKV_AWS_26 Terraform plan does not have required parameter during first iteration or plan #5472

Open cloudtriquetra opened 1 year ago

cloudtriquetra commented 1 year ago

Describe the issue

When Terraform plan is being run for first time it does not have the parameter kms_master_key_id present in chile_modules/resource/values. It is available in resource_changes/change/after_unknown. Hence the policy failes.

But when we run terraform plan for 2nd time i.e. after apply the parameter and associated value get updated in chile_modules/resource/values and the policy pass.

Examples

resource "aws_sns_topic" "sns_topic" {
  count                                      = var.create_topic ? 1 : 0
  name                                       = "${local.name_prefix}${var.fifo_topic ? ".fifo" : ""}"
  fifo_topic                                 = var.fifo_topic
  content_based_deduplication                = var.content_based_deduplication
  kms_master_key_id                          = var.sns_kms_key_arn
  tags                                       = var.tag_map
}

Version (please complete the following information):

gruebel commented 1 year ago

hey @arkaprava-jana thanks for reaching out.

This is known limitation, which we don't plan on tackling any time soon. Can't find the issue number, where it was already mentioned in the past.

A TF plan sadly doesn't offer so much information on what precisely will actually change under the after_unknown block and just blindly using it will results in too many false positives/negatives.

Ex.

resource "aws_kms_key" "example" {
  description             = "example"
}

resource "aws_sns_topic" "example" {
  name              = "example"
  kms_master_key_id = aws_kms_key.example.arn
}

This results in following after_unknown block for aws_sns_topic

"after_unknown": {
  "arn": true,
  "id": true,
  "kms_master_key_id": true,
  "name_prefix": true,
  "owner": true,
  "policy": true,
  "signature_version": true,
  "tags_all": true,
  "tracing_config": true
}

This falsely marked name_prefix and tracing_config to have a value after the apply, but they won't exist in the actual state of the resource.

I keep this one open till I find the previous issue.

stale[bot] commented 8 months ago

Thanks for contributing to Checkov! We've automatically marked this issue as stale to keep our issues list tidy, because it has not had any activity for 6 months. It will be closed in 14 days if no further activity occurs. Commenting on this issue will remove the stale tag. If you want to talk through the issue or help us understand the priority and context, feel free to add a comment or join us in the Checkov slack channel at codifiedsecurity.slack.com Thanks!

forstops commented 8 months ago

Hay All I am seeing the same issue on check CKV_AWS_27, Where the plan file converted to json shows "sqs_managed_sse_enabled": true, in the after_unknown section but passes if the code is deployed and checkov is reran

tsmithv11 commented 2 months ago

@cloudtriquetra @forstops we have an experimental feature that does take into account after_unknown. If you use EVAL_TF_PLAN_AFTER_UNKNOWN, such as EVAL_TF_PLAN_AFTER_UNKNOWN=true checkov -f plan.json, it will consider this section as part of the check. Can you give it a shot and provide feedback?

cloudtriquetra commented 2 months ago

@tsmithv11

Unable to use the flag on version 3.2.209

tsmithv11 commented 2 months ago

@cloudtriquetra thanks for giving it a try. Can you add more details for what's not working? Are you seeing errors or not the results you expected?

If the first, can you share details about the error and run it with LOG_LEVEL=debug and share sanitized debug logs?

If the second, can you share a sanitized example plan file?