Skip to content
/

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:
/

When I start on a project that uses Azure resources, one of the first things I do is build the infrastructure and automate the deployment using VSTS or TFS.
In this post I‘ll explain how you can extend Azure Web Apps with Virtual Applications and Virtual Directories using ARM templates.

When I start on a project that uses Azure resources, one of the first things I do is build the infrastructure and automate the deployment using VSTS or TFS. The definition of the infrastructure is defined using ARM templates.
When you search online you will find plenty of examples on how to create and use ARM templates. But when you move beyond the basics you’ll find out the documentation is lacking.

In this post, I’ll explain how you can extend Azure Web Apps with Virtual Applications and Virtual Directories using ARM templates.

I won’t be covering on reasons why you would want to use Virtual Applications or Directories. If you’re interested in more background on these, you can read .

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

The Web App definition

We start with a basic site template, for brevity I skipped the app service definition.
The resources property is an empty collection by default.

{
  "type": "Microsoft.Web/sites",
  "kind": "app",
  "name": "LoremIpsumWebApp",
  "apiVersion": "2015-08-01",
  "location": "[resourceGroup().location]",
  "resources": [],
  "dependsOn": [
    "[resourceId('Microsoft.Web/serverfarms', 'LoremIpsumAppService')]"
  ]
}

Adding the Configuration resource

Configuration of the Web App properties is done with a resource with the type of Microsoft.Web/sites/config.

The name of the resource starts with the name of the parent Web App extended with /web.

In the property properties, you can configure several configuration properties like Virtual Applications, enabling Always On or disabling PHP.

A Web App always contains a root application.

{
  "type": "Microsoft.Web/sites/config",
  "name": "LoremIpsumWebApp/web",
  "apiVersion": "2015-08-01",
  "dependsOn": [
    "[resourceId('Microsoft.Web/sites', 'LoremIpsumWebApp')]"
  ],
  "properties": {
    "phpVersion": "",
    "alwaysOn": "true",
    "virtualApplications": [
      {
        "virtualPath": "/",
        "physicalPath": "site\\wwwroot",
        "virtualDirectories": null
      }
    ]
  }
}

We add the new config resource as a child resource to the Web App:

{
  "type": "Microsoft.Web/sites",
  ...
  "resources": [
    {
      "type": "Microsoft.Web/sites/config",
      ...
    }
  ],
  ...
}

Other properties trimmed for brevity.

Adding Virtual Applications

We can add a Virtual Application by adding it to the virtualApplications array.
There are 2 required properties:

  • The virtualPath is the relative path to the root URL of the website.
  • The physicalPath is the (relative) path on disk where the files for this application are stored.
{
  "virtualPath": "/DolorSitAmet",
  "physicalPath": "site\\dolor-sit-amet",
  "virtualDirectories": null
}

Adding Virtual Directories

Virtual Directories are always a part of a Virtual Application.

A Virtual Directory has the same two required properties that are needed for a Virtual Application: virtualPath and physicalPath.

{
  "virtualPath": "/Images",
  "physicalPath": "site\\path-to\\images"
}

This object is added to the Virtual Application:

{
  "virtualPath": "/DolorSitAmet",
  "physicalPath": "site\\dolor-sit-amet",
  "virtualDirectories": [
    {
      "virtualPath": "/Images",
      "physicalPath": "site\\path-to\\images"
    }
  ]
}

Now you can deploy the ARM template to your Azure Resource Group and then configure a Web Deploy to your brand new Virtual Application!

Source code

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

Filed under Azure
Last update:
/

The other day I needed to get the URLs for all pages in my blog for some PowerShell scripting I wanted to do. Like most websites this blog has a sitemap and I wanted to use that as a source.
As I couldn’t find any existing PowerShell scripts on the web that I could use, I just wrote one myself.
Now I like to share this script with you.

The other day I needed to get the URLs for all pages in my blog for some PowerShell scripting I wanted to do. Like most websites this blog has a sitemap and I wanted to use that as a source.
As I couldn’t find any existing PowerShell scripts on the web that I could use, I just wrote one myself.
Now I like to share this script with you.

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

Basic usage

Just execute the script with an URL to an XML Sitemap.

.\ConvertFrom-SiteMap.ps1 -Url https://blog.hompus.nl/sitemap.xml

Which results in something like this:

loc        : https://blog.hompus.nl/
lastmod    : 2017-02-10T23:57:52+00:00
changefreq : daily
priority   : 1.0

loc        : https://blog.hompus.nl/category/azure/
lastmod    : 2017-02-08T17:43:41+00:00
changefreq : weekly
priority   : 0.3

loc        : https://blog.hompus.nl/category/csharp/
lastmod    : 2016-12-14T08:53:46+00:00
changefreq : weekly
priority   : 0.3

Displaying only the first 3 entries

Under the section XML tag definitions the protocol states that the lastmod, changefreq and priority attributes are optional, so they can be missing when querying a different sitemap.

Now you can do basic PowerShell manipulation of the result set like sorting, selecting, filtering and formatting. For example:

.\ConvertFrom-SiteMap.ps1 -Url https://blog.hompus.nl/sitemap.xml 
                                   | Sort-Object priority -Descending 
                                   | Select-Object priority, changefreq, loc -First 5 
                                   | Where-Object { $_.priority -ge 0.3 }
                                   | Format-Table

Outputs:

priority changefreq loc
-------- ---------- ---
1.0      daily      https://blog.hompus.nl/
0.6      weekly     https://blog.hompus.nl/about/
0.6      weekly     https://blog.hompus.nl/archives/
0.3      weekly     https://blog.hompus.nl/category/windows/
0.3      weekly     https://blog.hompus.nl/category/visual-studio/

Ignoring Sitemap Index entries

An sitemap can also be a Sitemap Index File. The file then contains links to other sitemap files.
By default the script will follow these links. If you don’t want this to happen you can set the NoFollow switch.

.\ConvertFrom-SiteMap.ps1 -Url https://blog.hompus.nl/sitemap.xml -NoFollow

Source code

The complete source code is available as a GitHub Gist: ConvertFrom-SiteMap.ps1.