3
votes

In our CI/CD pipeline im trying to automate the creation of SAS tokens for containers used by other systems. Each SAS token "points" to a Shared Access Policy.

My first thought was to add this to our PowerShell post deployment script so we can add the creation of new containers (including SAS tokens and shared access policies) to the script as we expand. Everything works and I get both he policy and the SAS token generated but I got stuck on one thing that differs from when I generate a SAS token via the Azure portal. I hope that someone can shed some light on the discrepancy.

PowerShell script (run as part of deploy pipeline in VSTS)

Select-AzureRmSubscription -SubscriptionId $useSubscription
Set-AzureRmContext -SubscriptionId $useSubscription

$accountKeys = Get-AzureRmStorageAccountKey -ResourceGroupName $useResourceGroupName -Name $storageAccountName
$storageContext = New-AzureStorageContext -StorageAccountName $storageAccountName -StorageAccountKey $accountKeys[0].Value 
$expiryTime = (get-date).AddYears(1)
$permission = "rwl"

New-AzureStorageContainerStoredAccessPolicy -Context $storageContext -Container "test-container" -Policy "testPolicy" -ExpiryTime $expiryTime -Permission $permission

$sasToken = New-AzureStorageContainerSASToken  -Name "test-container" -Policy "testPolicy" -Context $storageContext
$sasToken = $sasToken.substring(1)

Write-Host "SAS token (ref shared access policy): $sasToken"

$sasToken2 = New-AzureStorageContainerSASToken -Context $storageContext -Container tibp-userprofiles -Permission rwl
Write-Host 'SAS token: ' $($sasToken2)

The output is currently:

SAS token (ref shared access policy): sv=2015-04-05&sr=c&si=tibpsaptest2&sig=rkzN3ocRZUrz5ub2IcVPKGIARvw3%2B2rh1G3yKmnSXhA%3D
SAS token:  ?sv=2015-04-05&sr=c&sig=9kMVFE7U61P1ikK27ylXqXiIkSaj71OImdM88RrtJfs%3D&se=2017-05-22T08%3A40%3A39Z&sp=rwl

My question is why is sv set to 2015-04-05 using Pwershell cmdlet and not the newest version 2016-05-31? I get the same result for sv if I generate a clean SAS token (not backed by a shared access policy).

If I generate a SAS token using the Azure Portal (using the same storage account and container) i get sv set to the newest version (2016-05-31).

The output using Azure Portal:

?sv=2016-05-31&ss=b&srt=sco&sp=rwl&se=2017-05-22T17:36:58Z&st=2017-05-22T09:36:58Z&spr=https&sig=UTibTnwmwYl3k3iIYj63VbYItL5eV4K4t6PEZ7ihi3E%3D

The CI/CD pipline is run using VSTS and I use a standard Azure PowerShell task to run the script.

Azure PowerShell version in VSTS

1

1 Answers

2
votes

You could use the following cmdlet to generate SAS token, the result is same with Portal.

$now=get-date

New-AzureStorageContainerSASToken -Name <container name> -Context $storageContext -Permission rwl -StartTime $now.AddHours(-1) -ExpiryTime $now.AddMonths(1)

My test result is below

?sv=2015-04-05&sr=c&sig=tMG2TwiAGXkDqwFbj7%2BRjI52qXUKU9NDI%2BmkxMY%2BjtM%3D&st=2017-05-22T00%3A41%3A50Z&se=2017-06-22T01%3A41%3A50Z&sp=rwl

You could check they are same except API version ?sv=2015-04-05. More information about SAS please refer to this link.

Update:

I know the reason, Azure Portal uses the latest API version to generate SAS token, but your local Azure PowerShell does not use the latest version.

You could use the following cmdlet to check your Azure PowerShell version.

Get-Module -ListAvailable -Name Azure -Refresh

On the latest version(for now 4.01) use the latest API version. You could download the mis installer from the link.

PS C:\Users\v-shshui> New-AzureStorageContainerSASToken -Name vhds -Context $storageContext -Permission rwl -StartTime $now.AddHours(-1) -ExpiryTime $now.AddMonths(1)
?sv=2016-05-31&sr=c&sig=zdrwTEEmvTn6rjoJPVWOdQYzggrvygTHGoBsOBYgzuI%3D&st=2017-05-22T07%3A56%3A21Z&se=2017-06-22T08%3A56%3A21Z&sp=rwl