Monitoring Azure applications – Part 2

The “Monitoring Azure applications” series:

• Part 1: Enabling instrumentation and monitoring in your Azure app(s)
• Part 2: Setting up the handshake
• Part 3: Discovering your application
• Part 4: When things don’t work

In this blog post I’m going to cover how to get the certificate pieces setup, which allow mutual authentication between Azure applications and your OpsMgr infrastructure.  Since I primarily came from an OpsMgr background, I had very little experience with certificates and I definitely didn’t know what was involved in the Azure side.

The first thing that needs to be sorted out is authentication between your Azure application(s) and your OpsMgr manager infrastructure.  Given that we’re talking about potentially sensitive data, which is being routed over the internet, it’s very important that this whole channel be as secure as possible.  Since we can’t rely on a domain level-trust we have to use an approach not entirely unlike certificate based mutual authentication for agents, but since we’re working Azure, we’re going to be authenticating with the Windows Azure Service Management API instead of with one or more HealthServices.  No need to worry though, all communication with the Service Management API is mutually authenticated over SSL.

Create a certificate to be used

As I mentioned, I’m not really a pro in this area, so I won’t run the risk of misinforming folks on how to get your hands on a certificate.  Within Microsoft, we have a formalized process for requesting certificates from our central certificate authority, so that is what we did.  Later, I found that Walter Myers gives some great instructions in his primer (starting about 1/3 of the way down) on how to create a certificate yourself with IIS, and that cleared up a lot of things for me.  Following are the key (sorry, but I couldn’t resist) best practices we learned:

1. We extended the expiration date of the cert for as long as we could: You will have to renew your certs, but the further apart that can be, the less effort on your part.  The trade-off here is risk, but you can always programmatically push out a new cert and remove the old one if you need to.
2. We keep the private key (.PFX), and its password, secret and safe:  Anyone who gets this certificate can do anything with the Azure applications it gets added to.  Those who are familiar with certificates or the service management API
   are thinking this is obvious, but for me as an OpsMgr administrator, this is a good reminder as I don’t work with certificates much at all and up until I’d never worked with the service management API.

Add the public key (.CER) to your Azure subscriptions as a “Management Certificate”

Once we have the certificate we now need to configure the Azure subscriptions, so that they will accept communications signed with this certificate.  We do this by uploading the public key portion of the certificate up to our subscription, as a managed certificate.  Following are the steps involved:

1. Export the public key (.CER file) from the private key (.CER file).  Again, this is covered well in Walter Myers’ primer Open the Azure management portal Click on Hosted Services, Storage Accounts & CDN
2. In the left-hand folder list click on Management Certificates
3. For each subscription you want to monitor, click the Add Certificate and import the certificate for each

Create the Run As Accounts required for certificate based authentication

Lastly, we need to create two RunAs accounts within Operations Manager, which contain the full certificate (binary authentication) and the password to access the full certificate (basic authentication) respectively.  This too, is a relatively new concept, even for folks with an OpsMgr background, but fortunately you only have to set it up once.

1. Open the Operations Manager Console

2. Switch to the Administration section

3. Navigate to Run As Configuration -> Accounts

4. Right-Click on the right-hand pane, where the accounts are shown, and select Create Run As Account… to create the binary authentication run as account, which will hold the certificate file:

   1. On the General Properties section select Binary Authentication from the drop-down list for Run As account type and in the display name, we provided something like “Azure Monitoring – Certificate”
   2. On the Credentials section, click browse and navigate to the .PFX file for the certificate
   3. On the Distribution Security section we opted to go with More Secure and then added the Azure watcher node, to the list of systems that were approved to have the account distributed to it.
   4. We then created the account.

5. Back at the Run As Account screen, we need to create a 2^nd run as account.  Right-Click on the right-hand pane, where the accounts are shown, and select Create Run As Account… to create the basic authentication run as account, which will hold the password that is used to access the private key within the certificate:

   1. On the General Properties section select Basic Authentication from the drop-down list for Run As account type and in the display name, we provided something like “Azure Monitoring – Certificate Password”
   2. On the Credentials section, we gave the account name of “Azure Monitoring – Certificate Password”, and the password we put here is the password of the PFX file.
   3. Again, on the Distribution Security section we opted to go with More Secure and then added the Azure watcher node, to the list of systems that were approved to have the account distributed to it.
   4. We then created the account.

Note: The Run As Accounts and Run As Profiles topic gives an overview of the various types of accounts available, and how they relate to profiles.  The Security Considerations section of the Azure MP guide, gives the specific details relevant to this MP.

So that’s it!  Now we have the pieces in place between our Azure subscriptions and our monitoring infrastructure, to allow discovery and monitoring via the service management API.