CKV_AZURE_36 - false positive if single file was checked

[t3mi]

Describe the issue CKV_AZURE_36 triggers a false positive for azurerm_storage_account_network_rules if single file was checked and variable default value is located in a separate file.

Examples

# variables.tf
variable "bypass" {
  default = ["AzureServices"]
}

# main.tf
provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "example" {
  name     = "example-resources"
  location = "West Europe"
}

resource "azurerm_virtual_network" "example" {
  name                = "example-vnet"
  address_space       = ["10.0.0.0/16"]
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
}

resource "azurerm_subnet" "example" {
  name                 = "example-subnet"
  resource_group_name  = azurerm_resource_group.example.name
  virtual_network_name = azurerm_virtual_network.example.name
  address_prefixes     = ["10.0.2.0/24"]
  service_endpoints    = ["Microsoft.Storage"]
}

resource "azurerm_storage_account" "example" {
  # checkov:skip=CKV_AZURE_35:False positive
  name                     = "storageaccountname"
  resource_group_name      = azurerm_resource_group.example.name
  location                 = azurerm_resource_group.example.location
  account_tier             = "Standard"
  account_replication_type = "GRS"
  min_tls_version          = "TLS1_2"

  tags = {
    environment = "staging"
  }
}
resource "azurerm_storage_account_network_rules" "example" {
  storage_account_id = azurerm_storage_account.example.id

  default_action             = "Deny"
  ip_rules                   = ["1.1.1.0/8"]
  virtual_network_subnet_ids = [azurerm_subnet.example.id]
  bypass                     = var.bypass
}

Check only main.tf file with checkov --file /tf/main.tf and observe a false positive.

Version (please complete the following information):

• 2.1.210

[gruebel]

hey @t3mi thanks for reaching out. What is actually your expected result here? You want it to pass or fail?

[t3mi]

Yeah, sorry for not expanded the case. On the second thought, this is kind of a feature request here for a configurable option of how checkov should threat unresolved variables for checks - whether to pass, fail or skip. The reason for that as targets could be different:

1. Module directory - I as a user won't care if some of the variables could be unknown due to module logic and don't want checkov to fail in such situations.
2. Configuration directory - in such case I'm leaning more towards failed checks as an outcome but it may be possible that variables values for such checks could be known only in the terraform apply phase and it that case skip with "variable is unknown" or pass like for the situation#1 would be more preferable option.

[stale[bot]]

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 https://slack.bridgecrew.io Thanks!

[stale[bot]]

Closing issue due to inactivity. If you feel this is in error, please re-open, or reach out to the community via slack: https://slack.bridgecrew.io Thanks!