Get-AzRoleAssignment returns assignment for soft deleted storage containers

[ztrhgf]

Description

Follow the steps below to simulate this issue

• create a new Storage Account Container named SSS
• assign role RRR to group GGG
• remove this Container
• create again a new Storage Account Container named SSS
• list assigned roles via Get-AzRoleAssignment

You will receive various inherited role assignments but also assignments for role RRR and group GGG which are actually assigned at the deleted container, not this one newly created!

Issue script & Debug output

Get-AzRoleAssignment

Environment data

Name                           Value
----                           -----
PSVersion                      7.4.2
PSEdition                      Core
GitCommitId                    7.4.2
OS                             Microsoft Windows 10.0.19045
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0, 5.0, 5.1, 6.0, 7.0}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Module versions

ModuleType Version    PreRelease Name                                ExportedCommands
---------- -------    ---------- ----                                ----------------
Script     2.15.0                Az.Accounts                         {Add-AzEnvironment, Clear-AzConfig, Clear-AzContext, Clear-AzDefault, Connect-AzAc…
Script     6.4.1                 Az.Resources                        {Export-AzResourceGroup, Export-AzTemplateSpec, Get-AzDenyAssignment, Get-AzDeploy…
Script     3.0.0                 Az.Storage                          {Add-AzRmStorageContainerLegalHold, Add-AzStorageAccountManagementPolicyAction, Ad

Error output

No error

[microsoft-github-policy-service]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @kenieva, @AshishGargMicrosoft.

[isra-fel]

Thanks for reporting @ztrhgf let me loop in the RBAC (role based access control) team
Also cc @blueww although I guess this is not specific to Storage Account

[microsoft-github-policy-service]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @kenieva, @AshishGargMicrosoft.

[blueww]

This looks like a server side behavior, instead of Azure Powershell issue.
It might be better to raise a help ticket to get support from server side.

Besides that, I don't see Storage Powershell cmdlets related with this issue.
Feel free to give the detail of the action needed from Powershell Storage side.

[ztrhgf]

This looks like a server side behavior, instead of Azure Powershell issue. It might be better to raise a help ticket to get support from server side.

Besides that, I don't see Storage Powershell cmdlets related with this issue. Feel free to give the detail of the action needed from Powershell Storage side.

I've no idea (and I don't care) whether this is cmdlet issue or what. I am just saying that the behavior of this particular cmdlet is unexpected to say it politely :)

I also don't know whether this applies to other Azure resources besides Storage Account.

Anyway I had to create a custom function that calls the same API as Azure GUI a.k.a. GET request on "https://management.azure.com/$scope/providers/Microsoft.Authorization/roleAssignments?`$filter=atScope()&api-version=2020-04-01-preview"

[blueww]

@ztrhgf

We work on Powershell (client side), not on Azure server side, so we might not be the best person to help you for server issue.
To get the help more efficiently for server issue, please raise a help ticket in Azure Portal with: https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request#go-to-help--support-from-the-global-header

Besides that, I would suggest sharing more details of this issue in the help ticket (and here), like:

1. details repro script (hide credential)
2. When you assign the role RRR to group GGG, which scope do you use?
3. Why do you think "role RRR and group GGG which are actually assigned at the deleted container, not this one newly created"? Please give the actually result and the expect result.

It's a little confuse, since normally when do token validation, will validate the container name (path), but not care about the container creation time. So the old/new container with same name should be equally in token validation.

However, the issue looks not related with storage cmdlets, but role assignment cmdlets, this is not owned by storage team. @isra-fel Would you please help to follow up if any support of role assignment cmdlets needed for this issue?