Storage Account listKey API counts as write operation

[sylr]

Hi,

We came to notice calls to /subscriptions/<subscription>/resourceGroups/<group>/providers/Microsoft.Storage/storageAccounts/<storage>/listKeys?api-version=2018-07-01 returns a decremented x-ms-ratelimit-remaining-subscription-writes header leading to understand that this API is categorized as a WRITE operations where we believe it should be a READ one.

Is that a bug ?

Regards.

[mmyyrroonn]

@sylr Thanks for opening this issue! I'm sorry I need some time to investigate this one. I will share any update with you here.

[mmyyrroonn]

@stankovski would you please also check this issue?

[tombuildsstuff]

to add some additional context from our side: this behaviour means that when a ReadOnly lock is applied to the storage account, it's not possible to read those keys, since that's a Write operation

[sergey-shandar]

@XiaoningLiu @JasonYang-MSFT @vinjiang - Can you please take a look at this issue?

[blueww]

@huizlAzure
Would you please help to look at the issue on server behavior Storage Account listKey API?

[sylr]

Hi,

Could we have an update about this issue ?

Regards.

[musicislife08]

also looking for an update as we would like to use readonly management locks with terraform and this is preventing that

[sylr]

@huizlAzure @blueww @myronfanqiu can we have a status on this ?

[mmyyrroonn]

@huizlAzure Hello. Any update?

[blueww]

@sylr，@musicislife08, @myronfanqiu
We have contact SRP and ARM team for this issue.
They are still discussion this issue. Will update when get result.

[zhusijia26]

@blueww any update on this issue? Or could you please assign this to the right person (who is looking into it)?

[blueww]

Per the latest information I get, this is from ARM.

there is two level of throttling: the ARM level and the SRP level. x-ms-ratelimit-remaining-subscription-writes comes from ARM throttling.

There's a mail to ARM team, and I just ping it for responds.

BTW, this is not a swagger bug, but a server issue.

[kartikshah9]

@blueww request an update on this. If we need to consider re-assigning to a different team please initiate the thread and re-assign

[zhusijia26]

@blueww please provide an update on this issue.

[blueww]

@zhusijia26
I have ping ARM team again for this.
Will update this issue when get any update from them.

[blueww]

@zhusijia26
Following is the message I get from SRP/ARM team.
In a word, this is by design for security.

ListKeys retrieves secrets of the Storage Account therefore, it is modeled as a Write action by design for your account’s security, as Write operation requires higher privileged RBAC permissions. That said, we have taken actions to raise throttling limit for ListKeys to a much higher value. Please let us know if this resolves your issues.

[blueww]

@zhusijia26
As this is by design, I will close this issue.
Feel free to contact us if you need further assistance.

[tombuildsstuff]

@blueww sorry to push here - but the original issue here is that this design is not what users expect - presumably this should be a Read operation with a separate permission to retrieve this, rather than a Write operation? As it stands there's no means of retrieving the Storage Account Key via the API when there's a Write Lock on the storage account, since this counts as a Write operation?

As such could we re-open this issue and confirm with the ARM team if they plan to fix this?

Thanks!

[blueww]

@tombuildsstuff
When you get the storage account key, you can do write operation on storage objects (like container,blob ...). So for security reason, user with only read access, can't list storage account key.

Actually, we have discussed this with ARM team, and currently there's no plan to change this.

[tombuildsstuff]

@blueww there’s a difference between Data Plane and Resource Manager operations. When there’s a write lock on the storage account this only affects Resource Manager operations - and not the Data Plane API.

However if you’re unable to get the Storage Account Key from the Resource Manager API due to the Write Lock you’ll be unable to upload content via the Data Plane API. An error is returned from the Storage Resource Manager API’s when trying to list the keys once a Write lock has been added to the storage account regardless of the users permissions.

It’s worth noting there’s entirely valid use-cases for a user/service principal having read-only access to the Resource Manager API to obtain one of the Primary/Secondary Storage Account Keys to be able to access the Data Plane API’s. Unfortunately this is required due to the flawed rollout of AzureAD authentication for the Storage API’s - where the new storage roles haven’t been backported to existing contributor/owner role assignments and instead only apply to new role assignments.

This ultimately means that we’ve had many users spend large amounts of time debugging AzureAD permissions with two users in the same role - and still be unclear about why these accounts have different permissions. Unfortunately this means that AzureAD authentication isn’t usable as the primary authentication mechanism for the Storage API’s at this time.

As such - can we please get this issue reopened and re-reach out to the ARM team here?

Thanks!