Azurerm_storage_account incorrectly flags log configuration

Recently we had SonarCloud begin to scan our azure terraform code, and we are finding that for azurerm_storage_account resources it is incorrectly flagging log configurations

Hi Key,

Welcome to the community and thanks for your feedback.

Obviously there is something wrong in the rule description. We will fix this by adding Azure specific code examples.

Could you please share a code example showing us how the azurerm_monitor_diagnostic_setting resource is configured? It will help us understand why we don’t we raise an issue here.
Please share a text-based code snippet directly in this thread.

Thank you.

Sure thing.

Diagnostic settings for azure storage accounts are actually 4 separate diagnostic settings depending on the service (Blob, Table, Queue, File) plus a main diagnostic setting for the account as a whole

A diagnostic setting for a storage account which would log transactions and enable all diagnostics for all types of storage within the storage account would look like this. You might also have a second set of the below to log directly to a storage account (for long term retention)

resource "azurerm_monitor_diagnostic_setting" "main_log_analytics" {
    name                       = "managed-by-terraform-log-analytics"
    log_analytics_workspace_id = azurerm_log_analytics_workspace.my_workspace.id
    target_resource_id         = azurerm_storage_account.my_storage_account.id

    metric {
        category = "Capacity"
        enabled  = true

        retention_policy {
            days    = 0
            enabled = false
        }
    }
    metric {
        category = "Transaction"
        enabled  = true

        retention_policy {
            days    = 0
            enabled = false
        }
    }
}

resource "azurerm_monitor_diagnostic_setting" "additional_log_analytics" {
    for_each = toset(["blob", "table", "queueServices", "fileServices"])

    name                       = "managed-by-terraform-log-analytics"
    log_analytics_workspace_id = azurerm_log_analytics_workspace.my_workspace.id
    target_resource_id         = "${azurerm_storage_account.my_storage_account.id}/${each.key}/default"

    log {
        category = "StorageDelete"
        enabled  = true

        retention_policy {
            days    = 0
            enabled = false
        }
    }
    log {
        category = "StorageRead"
        enabled  = true

        retention_policy {
            days    = 0
            enabled = false
        }
    }
    log {
        category = "StorageWrite"
        enabled  = true

        retention_policy {
            days    = 0
            enabled = false
        }
    }

    metric {
        category = "Capacity"
        enabled  = true

        retention_policy {
            days    = 0
            enabled = false
        }
    }
    metric {
        category = "Transaction"
        enabled  = true

        retention_policy {
            days    = 0
            enabled = false
        }
    }
}

Hello Ken,

Thank you very much for your feedback. I am the one who wrote the Azure logging rule, so the confusion is my fault!

We did indeed consider checking the azurerm_monitor_diagnostic_setting resource to monitor proper logging, but Sonar-IAC’s internal limitations prevented us from doing so. We are still working on it :slight_smile:

As for your specific case, the check is actually done in the queue_properties block. Since your the storage_account's account_type is either not set or set to something other than BlobStorage, parameters for storage queues are created by default. Storage queues also have logging parameters in this block that we check. In your case it looks like the bloc is missing, it means that queue logging is also missing.

Nevertheless, this problem seems to be a false positive, since it is possible that you do not even intend to use storage queues at all.

May I ask if your code actually creates storage queues that are directly associated with this storage account?

If it is not the case, I need to tweak the functioning of this check because it is a false positive :smiley:

Loris

Hi Loris,

You’re correct, our use case does not use queues at all but your explanation makes sense. We do not create any queues in terraform nor in our application code. I find it interesting these properties exist, I’m not even sure where to set them in the portal. I feel like maybe this is deprecated or obsolete, not really sure. Might be worth checking with the azurerm terraform provider team on their slack (find the link on the provider’s github readme)

Thanks for clarifying.

Hi Ken,

Thank you for your response, perfect. It means I have to change the detection logic, and also the message, to specify that the issue is related to “queue logging” and not the more general “logging”.

Thanks for your feedback!

Loris

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.

Follow-up tickets: