Skip to content
/

The other day I wanted to configure Application Logging on Blob Storage for a Web App Service and found out this needs a SAS URL. And this is something an ARM template can’t provide for you.
In this post, I will walk you through the necessary PowerShell code to run.

These days it’s normal to deploy and configure all aspects of your Azure Resources using the Azure Resource Manager and the accompanying ARM Templates. But sometimes you walk into a missing feature that’s is not (yet) available in the ARM system.
The other day I wanted to configure Application Logging on Blob Storage for a Web App Service and found out this needs a SAS URL. And this is something an ARM template can’t provide for you.

In this post, I will walk you through the necessary PowerShell code to run. For example, after your ARM template has been deployed. At the end of the post you will find the link to the source code.

The ARM template

In the ARM template, we deploy a Storage Account and a Web App Service.

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "resources": [
        {
            "type": "Microsoft.Storage/storageAccounts",
            "kind": "Storage",
            "name": "loremipsumstore",
            "apiVersion": "2016-01-01",
            "sku": {
                "name": "Standard_LRS"
            },
            "location": "[resourceGroup().location]"
        },
        {
            "type": "Microsoft.Web/serverfarms",
            "kind": "app",
            "name": "LoremIpsumAppService",
            "sku": {
                "name": "B1"
            },
            "apiVersion": "2015-08-01",
            "location": "[resourceGroup().location]",
            "properties": {
            "name": "LoremIpsumAppService",
                "numberOfWorkers": 1
            },
            "resources": [
                {
                    "type": "Microsoft.Web/sites",
                    "kind": "app",
                    "name": "LoremIpsumWebApp",
                    "apiVersion": "2015-08-01",
                    "location": "[resourceGroup().location]",
                    "properties": {
                        "name": "LoremIpsumWebApp"
                    },
                    "dependsOn": [
                        "[resourceId('Microsoft.Web/serverfarms', 'LoremIpsumAppService')]"
                    ]
                }
            ]
        }
    ]
}

The problem

When we configure the Application Logging to Blob Storage using the Azure Portal we see the following properties in the JSON of the Web App Service using the Azure Resource Explorer.

"applicationLogs": {
  "azureBlobStorage": {
    "level": "Verbose",
    "sasUrl": "https://loremipsumstore.blob.core.windows.net/webapp-logs?sv=2015-04-05&sr=c&sig=XXX...XXX&st=2017-05-29T22:00:00Z&se=2217-05-29T22:00:00Z&sp=rwdl",
    "retentionInDays": 30
  }
}

But secretly, the last two properties are stored in the AppSettings. When we look there we see the following 2 keys:

DIAGNOSTICS_AZUREBLOBCONTAINERSASURL    https://loremipsumstore.blob.core.windows.net/webapp-logs?sv=2015-04-05&sr=c&sig=XXX...XXX&st=2017-05-29T22:00:00Z&se=2217-05-29T22:00:00Z&sp=rwdl
DIAGNOSTICS_AZUREBLOBRETENTIONINDAYS    30

Setting AppSettings with an ARM template isn’t that hard. But the URL we need to set can’t be predefined and ARM templates don’t have support for the generation of a SAS URL.

Many ARM template samples do use SAS URLs, but always as a parameter. But how can you supply a parameter to a resource that might not yet exist? That’s the whole point of using the template.

So, the only option is to configure the Web App Service after running the deployment.

The solution

For this solution, we use PowerShell. This makes it easy for running this code in a VSTS or TFS release pipeline. But it can be used in any way you want to configure your environments.

Depending on how you run this script you might need to login first using Login-AzureRmAccount and select the Azure Subscription you want to use using Select-AzureRmSubscription.

The configuration is done in 6 steps.

  1. We get the Storage Account where we want to store the Application Logs.
    $sa = Get-AzureRmStorageAccount -ResourceGroupName "loremipsumresourcegroup"
                                    -Name "loremipsumstore"

  2. We make sure there is a container to store the logs. Because we can run the script multiple times, we ignore the error if the container already exists.
    New-AzureStorageContainer -Context $sa.Context
                              -Name "webapp-logs"
                              -ErrorAction Ignore

  3. Next, we generate the SAS token for the container. We use the same settings Microsoft uses when creating the link using the Azure Portal.
    $sasToken = New-AzureStorageContainerSASToken -Context $sa.Context
                                                  -Name "webapp-logs"
                                                  -FullUri
                                                  -Permission rwdl
                                                  -StartTime (Get-Date).Date
                                                  -ExpiryTime (Get-Date).Date.AddYears(200)

  4. We want to update the AppSettings as the configuration is stored there. But when you update the AppSettings, any setting not present in the update will be removed. Therefore, we first want to get all the existing AppSettings.
    $webApp = Get-AzureRmWebApp -ResourceGroupName "loremipsumresourcegroup"
                                -Name "LoremIpsumWebApp"

  5. Strangely the Set-AzureRmWebApp command does not accept the SiteConfig.AppSettings we got from the Get-AzureRmWebApp command. We need to create a Hash Table for this.
    To make sure the Application Settings keep the same order, we define the Hash Table as Ordered.

    $appSettings = [ordered]@{}
    $webapp.SiteConfig.AppSettings | % { $appSettings[$_.Name] = $_.Value }
    $appSettings.DIAGNOSTICS_AZUREBLOBCONTAINERSASURL = [string]$sasToken
  6. Now we can update the App Service using the Set-AzureRmWebApp command.
    Set-AzureRmWebApp -ResourceGroupName "loremipsumresourcegroup"
                      -Name "LoremIpsumWebApp"
                      -AppSettings $appSettings

Source code

The complete source code is available as GitHub Gist: Configure­AppService­ApplicationLog­To­BlobStorage.ps1 for reference.

/

When I recently was configuring an Azure AD application I couldn’t assign the delegated permissions for an Azure SQL Database. It did cost me a full day to find out the Azure Portal user interface has an unexpected user interaction when it comes to selecting APIs.

In this post, I’ll explain how you can find all APIs available for your application.

When I recently was configuring an Azure AD application I couldn’t assign the delegated permissions for an Azure SQL Database. It did cost me a full day to find out the Azure Portal user interface has an unexpected user interaction when it comes to selecting APIs.

In this post, I’ll explain how you can find all APIs available for your application.

The problem

When we want to integrate an application with Azure AD we need to register an app.
In my case I want to let a user access an Azure SQL Database using delegation. So, the database connection will be created impersonating the user account, not a generic service account.

To grant delegation permissions to an API we go to the Required permissions section of the Azure AD app:
Required permissions menu item

When we’ve created a new app there is not much showing yet, other than the default Azure AD delegated permission to sign in as the user:
Required permissions pane with default entry

We click on the Add button and choose the Select an API option:

Select an API menu item

Here we get a list of APIs to choose from. But our Azure SQL Database is not listed.
There is a search function, but entering SQL, like my colleague did, didn’t list any results.

This is where I started to search online if other people encountered the same problem. One of the few related posts is by Michael Collier: .
In his post he mentions not having the API listed:

Before you can continue, you need to have followed the prerequisites steps stated at the top of this post. You especially need to be sure you have created an Azure AD contained database user. If you fail to do that, you will not see “Azure SQL Database” in the list (as specified below).

But following all his steps didn’t make the API appear.

After wasting more time not finding any other related posts, adjusting multiple settings, and recreating Azure AD apps, I suddenly found a lead that pointed me in the right direction

The solution

One of the apps I created was named AzureSqlAppTest. Because the list of registered apps is quite long I wanted to use the search function and I entered the word SQL.
To my surprise no results. Entering AzureSQL did show my app.

The search function in the Azure Portal is acting only as a Begins With filter!

Desperately, I tried this trick on the API list as well. Maybe the API search function doesn’t show SQL related APIs because the name doesn’t start with SQL.

Instead of SQL I entered Azure in the search box, and to my amazement: a whole new list of never-before-seen APIs showed up, including our Azure SQL Database:
Select an API pane listing many APIs that where hidden

There are many more APIs available in the Azure Portal, there is just no indication in the UI!

After re-reading Michael Colliers blog post, I found he did mention this at the end of one of the steps:

3. Add a new required permission and select Azure SQL Database as the API. You’ll want to search for “azure” to get “Azure SQL Database” to appear in the list.

Now we can configure our app, and everything will work as expected.

The conclusion

Just because the Azure Portal UI doesn’t give any hint there are many more APIs hidden behind the search function, I wasted a lot of good time.
I hope this post will prevent you from wasting yours, and I hope the Portal UI will improve.

Filed under Azure
Last update:
/

Azure Key Vault is a great resource to store your secrets like passwords, connection strings, certificates, etc. and access them programmatically. A great feature is to add or update your secrets during deployment so you don’t have to manage your secrets manually. In this post, I’ll explain how you can add secrets to an Azure […]

Azure Key Vault is a great resource to store your secrets like passwords, connection strings, certificates, etc. and access them programmatically. A great feature is to add or update your secrets during deployment so you don’t have to manage your secrets manually.

In this post, I’ll explain how you can add secrets to an Azure Key Vault using ARM templates.

At the end of the post you will find the link to the source code.

Creating the Key Vault

First, we create the Key Vault to store all our secrets.
You can add an access policy so you’re able to see and manage the secrets using, for example, the Azure Portal.

To create a Key Vault, we add the following resource to the ARM template:

{
  "type": "Microsoft.KeyVault/vaults",
  "name": "LoremVault",
  "apiVersion": "2015-06-01",
  "location": "[resourceGroup().location]",
  "properties": {
    "sku": {
      "family": "A",
      "name": "Standard"
    },
    "tenantId": "[subscription().tenantId]",
    "accessPolicies": [
      {
        "tenantId": "[subscription().tenantId]",
        "objectId": "CHANGETO-YOUR-USER-GUID-000000000000",
        "permissions": {
          "keys": [ "All" ],
          "secrets": [ "All" ]
        }
      }
    ]
  }
}

Adding a plain text Secret

With the Key Vault in place, we can start adding secrets to it.

We add a resource to the ARM template to describe the secret.
The name must be prefixed with the name of the Key Vault. We also declare that the resource depends on the Key Vault resource. This ensures the Resource Manager doesn’t try to store the secret before the Key Vault is created.

A secret consists of two properties:

  • contentType contains the of the secret
  • value contains the value of the secret
{
  "type": "Microsoft.KeyVault/vaults/secrets",
  "name": "LoremVault/SomeSecret",
  "apiVersion": "2015-06-01",
  "properties": {
    "contentType": "text/plain",
    "value": "ThisIpsemIsSecret"
  },
  "dependsOn": [
    "[resourceId('Microsoft.KeyVault/vaults', 'LoremVault')]"
  ]
}

Adding a certificate as a Secret

This is almost the same a storing a plain text value.
Change the contentType to application/x-pkcs12 and add the certificate as encoded string to the value:

{
  "type": "Microsoft.KeyVault/vaults/secrets",
  "name": "LoremVault/SomeCertificate",
  "apiVersion": "2015-06-01",
  "properties": {
    "contentType": "application/x-pkcs12",
    "value": "MIIV0QIBAzCC...yada...yada...RIJcq3QACAggA"
  },
  "dependsOn": [
    "[resourceId('Microsoft.KeyVault/vaults', 'LoremVault')]"
  ]
}

Besides storing hardcoded values it’s also possible to use parameters, variables, or even the output of other resources as source for the value of your secrets.

Adding a connection string to a Storage Account

Let’s make a Secret resource containing the connection string of an Azure Storage Account.

First, we add a Storage Account resource to the ARM template:

{
  "type": "Microsoft.Storage/storageAccounts",
  "kind": "Storage",
  "name": "loremipsumstore",
  "apiVersion": "2016-01-01",
  "sku": {
    "name": "Standard_LRS"
  },
  "location": "[resourceGroup().location]"
}

Now we add a Secret resource that is depending on the Storage Account and the Key Vault defined earlier.
The value of the secret is set with a connection string containing the first access key of the Storage Account:

{
  "type": "Microsoft.KeyVault/vaults/secrets",
  "name": "LoremVault/ConnectionString",
  "apiVersion": "2015-06-01",
  "properties": {
    "contentType": "text/plain",
    "value": "[concat('DefaultEndpointsProtocol=https;AccountName=loremipsumstore;',
              AccountKey=', listKeys(resourceId('Microsoft.Storage/storageAccounts', 
              'loremipsumstore'), providers('Microsoft.Storage', 'storageAccounts')
              .apiVersions[0]).keys[0].value, ';')]"
  },
  "dependsOn": [
    "[resourceId('Microsoft.KeyVault/vaults', 'LoremVault')]",
    "[resourceId('Microsoft.Storage/storageAccounts', 'loremipsumstore')]"
  ]
}

Thanks to Maarten van Sambeek for sharing this code with me.

Now you have stored your connection string securely without it ever surfacing outside of your deployment. If you use access policies so your application reads the connection string directly from Key Vault, you don't have to store your connection string anywhere where it’s readable like in a web.config file.

Source code

I’ve create a GitHub Gist with the a full working Key Vault deployment template sample for reference.

Filed under Azure
Last update: