Get-AzStorageContainer Cannot Return "PublicAccess" attribute if using AD-based context

[JoelCBennett]

Get-AzStorageContainer command utilizes a -context to authenticate and retrieve values for a storage account. The 'PublicAccess' attribute only returns values if the -context supplied uses a storage account key. If the context utilizes AD credentials it fails to return any values.

See below:

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

[dingmeng-xue]

Storage team, please help to look into this issue.

[blueww]

@JoelCBennett
Thanks for raising this question!

This is by design.
Storage account key credential is needed to get container 'PublicAccess'.
To get container 'PublicAccess' in dataplane, need use rest API "Get Container ACL" And it's Not available via OAuth.
see https://docs.microsoft.com/en-us/rest/api/storageservices/authorize-with-azure-active-directory#permissions-for-calling-blob-and-queue-data-operations

[JoelCBennett]

@blueww I don't see that in the documentation of the commands you referenced, and if true, I would argue that this is a confusing design choice. Using my Azure AD credential, I can view this attribute in the portal, so why not with powershell?

As background, I'm writing a powershelgl-based script to find containers set to 'PublicAccess' allowed. With this restriction, I have to loop through each storage account, retrieve the keys, then pump them into a new context (multiplied by 1000X, or how many individual storage accounts + containers you have).

If the AD credential worked as expected, this would make the query incredibly more concise.

[blueww]

@JoelCBennett
If you open the link in my before comment, you should can see following .

Get Container ACL	Not available via OAuth
Set Container ACL	Not available via OAuth

If you log on AD account has credential to see container public access in portal, then it should has management plane access to the Blob container, then you can use management plane cmdlet Get-AzRmStorageContainer to get Blob Container, and can see the blob Public access. See detail for the cmdlet in https://docs.microsoft.com/en-us/powershell/module/az.storage/get-azrmstoragecontainer?view=azps-4.3.0

And for "loop through each storage account, retrieve the keys, then pump them into a new context", it should not be so complex in Powershell, you can use the cmdlet Get-AzStorageAccountKey to get the account key, or just pipeline the list out account to dataplane cmdlet like following, Powershell will help to get the key and generate the key based storage context and list container.

$accounts = Get-AzStorageAccount
foreach($a in $accounts)
{
    $containers = $a | Get-AzStorageContainer
    # TODO: handle container objects
}

[JoelCBennett]

@blueww Reviewing the link you provided, I mis-interpreted the "Get Container ACL" as the "Access Control (IAM)" permission-set, but following the links I see what you mean.

I would still argue that this is a non-optimal design choice, as it complicates & restricts the retrieval of storage account values, and would lobby for revision.

I did end up writing a powershell to work around the limitation, however automation accounts hit runtime limits/unknown failures when looping through multiple subscriptions/storage accounts, and storage key retrieval/looping is a contributing factor.

#enumerate subscriptions
$Subscriptions = Get-AzSubscription

foreach ($sub in $Subscriptions) {
Get-AzSubscription -SubscriptionName $sub.Name | Set-AzContext
$SAs = Get-AzStorageAccount

foreach ($SA in $SAs) {
    #Write-Host $SA.storageaccountname
    #Grab the storage account key
    $key = Get-AzStorageAccountKey -ResourceGroupName $SA.ResourceGroupName -StorageAccountName $SA.StorageAccountName | Where-Object {$_.KeyName -eq "key1"}
    #establish Storage Context using returned SAs
    $storageContext = New-AzStorageContext -StorageAccountName $SA.storageaccountname -StorageAccountKey $key.value
    #Construct line to put in parameter
    $containers +=Get-AzStorageContainer -context $storageContext | Select Name, PublicAccess, @{l="Account";e={$SA.storageaccountname}} 
}

}

$containers | Ft

[blueww]

@JoelCBennett

1. Oauth authentication can't get/set container ACL, Azure Powershell might not be the best person to explain it. If you concern it, would you like to open an issue in Portal, and the related team will help to answer it.
   

2. For the script, would you please share the detail error, or we don't know how to help you. Anyway, by review the script, there might be some potential issue:

• I see you go through all subscriptions/accounts, and list all containers and save to a single variable. Not sure how many containers in all you subscriptions, but if there are many, this might will have problem, like OOM. I would suggest do this chunk by chunk, like list part of the containers (like an account), handle them (like save to file), clean up the variable, and list following part of containers.
• If there are many containers (like 10k+) in a storage account, the single list container cmdlet might will have problem to list all containers with single request. If so, please utilize "-ContinuationToken" "-MaxCount" to list containers chunk by chunk. You can refer Example delete corrupted tokencache #4 in Get-AzStorageBlob, to see how to utlize the 2 parameters

BTW, you don't need to get account key and create the $storageContext, you can use the script in my before answer to just pipeline the account object to get container.

[JoelCBennett]

@blueww Thank you for the feedback. Regarding #1, I would offer that allowing oauth to pull the ACL would result in less confusion and more concise code. If Powershell GitHub isn't the place for that feedback, happy to pass that on via a different channel.

I am still digging into why Automation fails half the time when run the powershell query...again, I suspect that it is due to total runtime for our environment (~120 storage accounts and perhaps 300 containers). Automation does not report verbose errors, so digging in with that team. Breaking the query up to query individual subscriptions works consistently, however that does betray the whole point (automating a scan of the environment for security vulnerabilities).