Why StorageQueue resource type requires a SAS Token

[salehabbas]

Greetings,

Hope you are doing well! I came by configuring Promitor to monitor some Azure Storage Queues. The documentation indicates that I have to set a SAS Token for the metric declaration in order for it to work. I have a question that I would appreciate your help with please.

Why StorageQueue resource type requires a SAS Token? I am monitoring the Storage Accounts using the Promitor Service Principal with the right RBAC assigned it and I was thinking it will work for the Storage Queue. Am I missing something?

Thanks in advance!

Regards,
Saleh Abbas

[tomkerkhove]

That's a valid question, unfortunately, Azure Monitor does not provide the required metrics.

The only metrics you can get is the message count for all queues, but not individual queues as per https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-supported#microsoftstoragestorageaccountsqueueservices

That's why we use the Azure Storage SDK to get the information.

[tomkerkhove]

In all honestly, this was originally added as a workaround until the metrics in Azure Monitor would be sufficient.

Since this is still not the case, it's time to improve it a bit. Unfortunately the SDK we are using does not allow for AD authentication, but I could add authentication through storage account keys - Would that be possible? Then you don't have to refresh them.

[salehabbas]

Thanks @tomkerkhove for your explanation! Sorry if I was not clear about it. Let me share with you my thought again. There are multiple ways to authorize requests to Azure Storage (and its services like Blobs, Files, Queues and Tables). These are:

1. Shared access signature (SAS)
2. Azure Active Directory (Azure AD)

My question is: Why do you depend on the SAS token method that expires every 7 days (the encryption key expires) and not using the Azure AD (The service principal we already use in Promitor (PROMITOR_AUTH_APPID & PROMITOR_AUTH_APPKEY))?

I can try to work on a PR if you want me to show and example. Please let me know if I am mistaken in something. Thanks again for your answer!

[tomkerkhove]

Because the SDK that we use does not support it, but there is a 3rd option which is by using the storage account key which I could easily add. It's still a separate secret, but it does not expire.

I have opened #1768 to migrate to the new SDK which will be able to give the AD-based auth as well.

[salehabbas]

Aha! Gotcha! Thanks a lot @tomkerkhove! Appreciated. I would wait for the the migration of the SDK to monitor Queues as I would not prefer to use the Storage Accounts Keys for monitoring as if they got compromised, it is a big problem :)

[tomkerkhove]

That is what I figured :D