Search code examples
azurepowershellazure-functionsvnet

PowerShell Azure Function: list Storage A/c blobs = unauthorised

The following PS code works when targeting a storage account that is open to all networks:

Set-AzCurrentStorageAccount -ResourceGroupName $azResourceGroupName  -Name $azStorageAccountName
@files=@()
Get-AzStorageBlob -Container $azContainerName -Prefix 'myfolder' | Select Name | where-object -Property Name -match 'txt' -outvariable files

However when applied via Azure function targeting a storage account that is locked down to private endpoint access it does not.

Error:

The client 'REDACTED1234' with object id 'REDACTED1234' does not have authorization to perform action 'Microsoft.Storage/storageAccounts/read' over scope '/subscriptions/mySub/resourceGroups/my-rg/providers/Microsoft.Storage/storageAccounts/myStorageAccount123' or the scope is invalid. If access was recently granted, please refresh your credentials.

The function app has a system assigned managed identity with contributor and blob storage contributor roles.

profile.ps1 is unchanged:

if ($env:MSI_SECRET) {
    Disable-AzContextAutosave -Scope Process | Out-Null
    Connect-AzAccount -Identity}

The function and storage a/c's sit in a separate Vnets with Vnet peering enabled.

I'm suspicious of the vnet peering but it's not something I have much experience in - any suggestions?

If anyone can point to PS code calling a blob private endpoint I'd be most grateful.

Solution

  • Thanks @felixmc for providing an alternative workaround as a solution for the current context i.e.

    Getting Unauthorized when trying to access Storage account (with private endpoint) via Function App.

    Logic app with public access has option to use firewall that can restrict to IPs etc. Also, logic app can have policy which validates calls to it has valid bearer token.

    Above alternative solution is taken from the GoToGuy Blog article provided by the user @felixmc that Azure Logic Apps can be secured with the help of restricting Inbound IP addresses and also with the Azure Active Directory OAuth Policy process using the Bearer Token where a practical workaround is shown in the same article provided by the author @AndreasMunch.