Best Practices for Managing Azure Subscriptions in Windows Azure PowerShell Cmdlets

Windows Azure PowerShell cmdlets makes it nice and easy to get started managing your Windows Azure services. Using the Get-AzurePublishSettingsFile cmdlet you can login into your WAZ subscription and fetch the details you need to manage your cloud services. PowerShell even saves these details locally so you can reuse them again in the future. This is great for personal accounts and small teams getting to know the Windows Azure PowerShell cmdlets. However in larger organisations this can quickly lead to management issues and security risks.

Before we get into the recommended practices, lets take a look at what happens when we use the  Get-AzurePublishSettingsFile cmdlet.

Get-AzurePublishSettingsFile

To run this command you must first download and install the Windows Azure PowerShell cmdlets.

The Get-AzurePublishSettingsFile cmdlet opens your browser and prompts you to log into using your Microsoft Account. If you administer multiple subscriptions, you are prompted to select which Windows Azure Subscription (or associated directory to be more correct) to use.

You will then be prompted to download an xml file with a “.publishsettings” extension that contains subscription details (name and subscription id) as well as a *newly* generated management certificate (saved as base64 encoded string). As part of this process, the management certificate’s public key is also added to the management certificates collection of the selected subscription.

After saving the file to your local machine you need to run the Import-AzurePublishSettingsFile cmdlet to update your Windows Azure PowerShell cmdlet subscription profile.

This cmdlet updates the Windows Azure PowerShell cmdlets profile data stored in your Roaming profile folder, %appdata%/Windows Azure Powershell. It also imports the management certificate into your Personal Certificate store so it is accessible by PowerShell.

Once we have imported the publish settings file successfully we can use PowerShell to view, delete and update the profile data saved locally.

A few important things to note here:

• The file downloaded contains an encoded management certificate that serves as the credentials to administer your Windows Azure subscriptions and services. This needs to be treated accordingly and stored securely. Managing public key infrastructure (PKI) in this way probably doesn’t comply with your organisation’s security policy or at the very least becomes a unmanageable way to control administrator access to your Windows Azure services.
• Not only do we have many management certificates drifting around on local machines, we also get a build up of public key certificates in the Windows Azure Portal. At the time of writing we are allowed 100 certificates per subscription. Identifying certificate ownership is only possible via thumbprint matching with the locally saved certificate details. This makes managing access control very challenging in large teams.
• Not being able to identify which certificate belongs to which administrator then leads to a security auditing and logging issues. Windows Azure Management Services provides operational logs for auditing and troubleshooting purposes. When a PowerShell script performs an operation against a service, an event is logged and the certificate thumbprint used to authenticate against the API is recorded. Once again, if we have no visibility of who owns which certificate, we severely reduce our ability to meet our organisation’s security policy requirements.
• Previously this process automatically included *all* subscriptions for which you were either a service administrator or co-administrator. This was very problematic for those of us that managed subscriptions on behalf of multiple client’s as it forced you to save details for all of your client’s subscriptions to the local machine. Not a very good conversation to have with a client when working onsite! Forcing the settings file to be scoped to just one subscription (or WAZ directory) is an improvement but still not the recommended practice.

So knowing what we do now, what is the recommended practice? How do we better manage these private key certificates? How should we setup our teams effectively and perhaps more importantly more securely? Lets take a look.

Recommended Practice

• Manage Windows Azure Management certificates using your organisations PKI infrastructure (e.g. Windows Server Certificate Authority)Here is some guidance however talk with your CA administrator to check your organisations policies:
  • Certificates must be X.509 version 3
  • Ensure Subject properties associate the cert with the admin user (don’t leave this as generic descriptions. We want to be able to identify the subject = user)
  • Key length must be 2048 bits
  • Use strong private key passwords
  • Don’t enable private keys to be exported

   

• Upload service management certificate public key to Portal
  • You may need to export the public key (*.cer) first from your Personal Certificate store
  • Upload the *.cer file to the Windows Azure Portal
• In your PowerShell scripts use the following cmdlets to set and manage your subscription context instead of relying on the publish settings file

Using the cmdlets above we can more effectively manage the service management access control in the PowerShell scripts we write. It requires a few more lines but I mitigate this by including the following function in a script template so that if forms the basis of all my WAZ management scripts. We also could pop this into a module and import it from our script. Either way, we are not having to rewrite this pattern each time.

<#
.SYNOPSIS
   Sets the specified Windows Azure Subscription as the current context
.DESCRIPTION
   First creates/updates the subscription profile
   Checks the required management certificate is installed
   Sets the subscription context for all WAZ cmdlets used in the session
.EXAMPLE
   Set-AzureSubscriptionContext -SubscriptionName “MySubscription” -SubscriptionId “00000000-0000-0000-0000-000000000000” -CertificateThumbprint “00000000000000000000000000000000000000000”
.OUTPUTS
   None
#>
function Set-AzureSubscriptionContext
{
param
(
# Windows Azure Subscription Name
[Parameter(Mandatory = $true)]
[String]
$SubscriptionName,

        # Windows Azure Subscription Id
[Parameter(Mandatory = $true)]
[String]
$SubscriptionId,

# Management Certificate thumbnail
[Parameter(Mandatory = $true)]
[String]
$CertificateThumbprint
)

# Get management certificate from personal store
$certificate = Get-Item cert:\\CurrentUser\My\$CertificateThumbprint
if ($certificate -eq $null) {
throw “Management certificate for $SubscriptionName was not found in the users personal certificate store. Check thumbprint or install certificate”
}

# Set subscription profile
Set-AzureSubscription -SubscriptionName $SubscriptionName -SubscriptionId $SubscriptionId -Certificate $certificate

# Select subscription as the current context
Select-AzureSubscription -SubscriptionName $SubscriptionName

}
 

By now we should have a better understanding of what goes on under the covers and some of the management pitfalls to avoid. Following the tips above we can achieve:

• Better compliance with your enterprise security policy.
• Central management of certificate generation and ownership.
• Tighter controls on script execution (as management certs need to be present on the local machine). Remember this is only achievable we mark private keys as non-exportable.
• Better administration event logging and auditing as event log entries will capture unique thumbprint of admin user.

So next time you are setting up your team’s Windows Azure Dev-Ops environment, take some time to consider your approach. Often the getting started guides and training course material take the easy, lowest barrier to entry approach rather than follow best practice.