Information about stoage account key rotation / storage account access key usage unclear

[jikuja]

The page provides following information:

Self-managed key rotation: If you change or rotate the access keys to your storage account, virtual network flow logs stop working. To fix this problem, you must disable and then re-enable virtual network flow logs.

Is that information correct? Documentation should clearly indicate if storage account target must have account key enabled.

Related findings

• microsoft.network/networkwatchers/flowlogs resource accepts storage account id. Template created by portal does not featch and inject SAS token. (Not sure if resource provider does that)
• storage account itself supports Network Watcher as trusted resource: https://learn.microsoft.com/en-us/azure/storage/common/storage-network-security?tabs=azure-portal#trusted-access-for-resources-registered-in-your-subscription

---

Document Details

⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

• ID: f59cf6f3-02e6-8b87-c83e-1342d8efcd5b
• Version Independent ID: 05b139d0-468c-418b-7d3a-3d1757f3d722
• Content: Virtual network flow logs - Azure Network Watcher
• Content Source: articles/network-watcher/vnet-flow-logs-overview.md
• Service: network-watcher
• GitHub Login: @halkazwini
• Microsoft Alias: halkazwini

[TPavanBalaji]

@jikuja Thanks for your feedback! We will investigate and update as appropriate.

[ManoharLakkoju-MSFT]

Hi @jikuja Thank you for bringing this to my attention. The information provided on the page you mentioned is not entirely accurate. While it is true that changing or rotating the access keys to your storage account can cause virtual network flow logs to stop working, it is not necessary to disable and re-enable the logs to fix the issue. Instead, you can simply update the storage account key in the Network Watcher configuration to the new key.

Regarding your related findings, you are correct that the microsoft.network/networkwatchers/flowlogs resource accepts a storage account ID, and the SAS token is not automatically fetched and injected. However, you can manually provide the SAS token in the storageAccountId property of the microsoft.network/networkwatchers/flowlogs resource.

Additionally, you are correct that storage accounts support Network Watcher as a trusted resource. This allows you to restrict access to your storage account to only traffic from trusted Network Watcher resources.

I will make sure to pass along this feedback to the appropriate team to see if we can update the documentation to provide more accurate and clear information. Let me know if you have any other questions or concerns.

[ManoharLakkoju-MSFT]

@halkazwini Can you please check and add your comments on this doc update request as applicable.

[jikuja]

Instead, you can simply update the storage account key in the Network Watcher configuration to the new key.

Regarding your related findings, you are correct that the microsoft.network/networkwatchers/flowlogs resource accepts a storage account ID, and the SAS token is not automatically fetched and injected. However, you can manually provide the SAS token in the storageAccountId property of the microsoft.network/networkwatchers/flowlogs resource.

How to " you can simply update the storage account key in the Network Watcher configuration to the new key"?

---

The major warning gives a hint that storage account account key is required for network watcher to work. At least that was my first impression from the note.

I personally would like to disable account key on all storage accounts. The note is kind if misleading if there is an undocumented way to add storage account with SAS token but "nobody" is actually using that kind of configuration.

Documentation should clearly state if storage account account key is required for Network watcher to work. Storage account documentation gives a hint that access is being granted as soon as exception is turned on.

[ManoharLakkoju-MSFT]

@jikuja Thanks for bringing this to our attention. I'm going to assign this to the document author so they can take a look at it accordingly

[halkazwini]

Hi @jikuja Thank you for your feedback! I'm closing this GitHub issue and creating an internal tracking work item to address it. If you have any additional information you would like to provide, please respond to this issue with any additional details.

Please continue to provide feedback about Azure documentation. We appreciate your contributions to our community. #please-close