[CKV2_AZURE_21] Ensure Storage logging is enabled for Blob service for read requests.

[GunasheelaSatharasi]

Describe the issue Even though the logging enabled for storage account blobs using the module log_analytics_storage_insights, checkov scan has been failing.

Examples

Variables defined: log_analytics_workspace_name = "log-dgb-poc-ea-001"
log_analytics_workspace_resource_group_name = "rg-digitalbanking-demo-ea-001" storage_account_name = "stappdgbpocea001"
storage_account_resource_group_name = "rg-digitalbanking-demo-ea-001"

code: workspace_id = var.log_analytics_workspace.id storage_account_id = var.storage_account.id storage_account_key = data.azurerm_storage_account.storage_account.primary_access_key

Version (please complete the following information):

• Checkov Version latest

Additional context Add any other context about the problem here.

[jota3c]

Having the same issue. At least here the problem seens like that the condition bellow is not detected, even it it exists :

CKV2_AZURE_21:

    - resource_types:
        - azurerm_storage_container
      connected_resource_types:
        - azurerm_storage_account
      operator: exists
      cond_type: connection

Between line 7 and 12 on https://github.com/bridgecrewio/checkov/blob/main/checkov/terraform/checks/graph_checks/azure/StorageLoggingIsEnabledForBlobService.yaml

To isolate those lines I created the same check locally and run condition by condition, all passed except the above.

The graph showing the connection :

[gruebel]

hey @GunasheelaSatharasi thanks for reaching out.

My guess it is related to reference a data block, which this check doesn't consider.

hey @jota3c can you share more, especially how azurerm_storage_container, azurerm_storage_account and azurerm_log_analytics_storage_insights are connected to each other.

[jota3c]

hey @GunasheelaSatharasi thanks for reaching out.

My guess it is related to reference a data block, which this check doesn't consider.

hey @jota3c can you share more, especially how azurerm_storage_container, azurerm_storage_account and azurerm_log_analytics_storage_insights are connected to each other.

Hi @gruebel thanks for you reply.

Seens like the problem at least on my case is really how the resources are connected. If the container uses the returned .name of an resource storage account as value to storage_account_name, the check pass. If you pass the name of the storage account as a fixed string, a variable or data return the checkov wont detect the connection.

Test using the example code from https://docs.paloaltonetworks.com/prisma/prisma-cloud/prisma-cloud-code-security-policy-reference/azure-policies/azure-logging-policies/ensure-storage-logging-is-enabled-for-blob-service-for-read-requests but changing the storage name to a variable on every call :

variable "storname" {
  default = "sometest"
}

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

resource "azurerm_log_analytics_workspace" "analytics_workspace_ok" {
  name                = "exampleworkspace"
  location            = azurerm_resource_group.resource_group_ok.location
  resource_group_name = azurerm_resource_group.resource_group_ok.name
  sku                 = "PerGB2018"
  retention_in_days   = 30
}

resource "azurerm_storage_account" "storage_account_ok" {
  name                     = var.storname
  resource_group_name      = azurerm_resource_group.resource_group_ok.name
  location                 = azurerm_resource_group.resource_group_ok.location
  account_tier             = "Standard"
  account_replication_type = "LRS"
}

resource "azurerm_log_analytics_storage_insights" "analytics_storage_insights_ok" {
  name                = "example-storageinsightconfig"
  resource_group_name = azurerm_resource_group.resource_group_ok.name
  workspace_id        = azurerm_log_analytics_workspace.analytics_workspace_ok.id

  storage_account_id  = azurerm_storage_account.storage_account_ok.id
  storage_account_key = azurerm_storage_account.storage_account_ok.primary_access_key
  blob_container_names= ["blobExample_ok"]
}

resource "azurerm_storage_container" "storage_container_ok" {
  name                   = "my-awesome-content-zip"
  storage_account_name   = var.storname
  container_access_type  = "blob"
}

...
Check: CKV2_AZURE_21: "Ensure Storage logging is enabled for Blob service for read requests"
        FAILED for resource: azurerm_storage_container.storage_container_ok
        File: /main.tf:40-44
        Guide: https://docs.paloaltonetworks.com/content/techdocs/en_US/prisma/prisma-cloud/prisma-cloud-code-security-policy-reference/azure-policies/azure-logging-policies/ensure-storage-logging-is-enabled-for-blob-service-for-read-requests.html

                40 | resource "azurerm_storage_container" "storage_container_ok" {
                41 |   name                   = "my-awesome-content-zip"
                42 |   storage_account_name   = var.storname
                43 |   container_access_type  = "blob"
                44 | }

Changing the :

resource "azurerm_storage_container" "storage_container_ok" {
  name                   = "my-awesome-content-zip"
  storage_account_name   = var.storname
  container_access_type  = "blob"
}

To :

resource "azurerm_storage_container" "storage_container_ok" {
  name                   = "my-awesome-content-zip"
  storage_account_name   = azurerm_storage_account.storage_account_ok.name
  container_access_type  = "blob"
}

Will pass the check.

[s4parke]

I'm not sure the Checkov rule CKV2_AZURE_21 rule does what it says it does.

https://docs.bridgecrew.io/docs/ensure-storage-logging-is-enabled-for-blob-service-for-read-requests Storage Analytics logs contain detailed information about successful and failed requests to a storage service. This information can be used to monitor individual requests and to diagnose issues with a storage service.

Storage Insights ("analytics logs") is a collection of aggregated metrics like the # of successful and failed requests, but not the details of an individual request. These are called "Metrics" and they are already enabled by default for new storage accounts. You can see the storage analytic metrics in the portal by following these instructions.

Data plane logging for a Storage Account Blob/Table/File/Queue Container is able to provide detailed information about successful and failed requests, and is configured via Resource Logs using the azurerm_monitor_diagnostic_setting provider for example. The diagnostic settings can stream Resource logs to a centralized Log Analytics Workspace or Storage Account, for ingestion into a SIEM if needed.

The Microsoft Cloud Security Benchmark baseline control LT-3: Enable logging for security investigation for Storage Accounts can be implemented with a built-in Azure Policy that deploys the diagnostic settings to each container in a Storage Account: b4fe1a3b-0715-4c6c-a5ea-ffc33cf823cb, but since it can be quite costly the recommendation by CIS (8.12) is to only use it for the most sensitive workloads (IG3).

Is that maybe what this rule is intended to check? Note: there are some issues with the AzureRM provider for diagnostic settings that are causing all kinds of validation problems.

[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 codifiedsecurity.slack.com 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: codifiedsecurity.slack.com Thanks!

[akzov]

This rule triggers on azurerm_storage_container which doesn't have any logging options