With the help of Azure Managed Service Identity (MSI) currently in preview, you can avoid storing passwords in your code to authenticate to services that support Azure Active Directory (AAD) authentication, including Key Vault.

Paul Schnackenburg

Paul Schnackenburg works part time as an IT teacher as well as running his own business in Australia. He has MCSE, MCT, MCTS and MCITP certifications. Follow his blog TellITasITis.

The problem with credentials in code is not new. It's been with us since the early days of computing. What's new is that the cloud exacerbates this problem because of its public nature, along with the fact that sysops now write code for "infrastructure as code."

There's a clear need to fix part of this problem. (When was the last time you heard of a cloud breach because of exposed credentials?) A new preview feature for Azure, Managed Service Identity (MSI), aims to do just that. And yes, we now have another meaning for "MSI." No longer is it related to "the old way of installing software on computers that was meant to save the world but really didn't."

Managed Service Identity ^

Ideally passwords should never appear in clear text in your code. Azure has for some time had the Key Vault service, which provides a secure way (either in software or backed by hardware security modules, HSMs) to store secrets such as credentials and certificates. Key Vault also integrates with AAD.

Today MSI supports Windows and Linux virtual machines (VMs), Azure App Service, and Azure Functions.

OK, so we store the credentials in Key Vault, but how does the code authenticate to it to get the credentials it needs? These are the steps involved (for a VM):

  1. You tell Azure Resource Manager (ARM) to enable MSI on a VM. It then creates a Service Principal (very similar to the credentials for services we've been used to in AAD) in the AAD tenant trusted by the subscription you're using.
  2. It creates a client ID and certificate in the MSI VM extension on the client.
  3. You can now assign permissions in AAD to the Service Principal of the VM using role-based access control (RBAC).
  4. Code on the VM requests a token from AAD through the endpoint in the MSI extension with its client ID and certificate; AAD then issues a JSON Web Token (JWT).
  5. The JWT then calls a service that supports AAD.

Because each service works slightly differently, I'll provide steps for one scenario: accessing an Azure Storage account from a Windows VM. If you don't have an Azure subscription, you can sign up for a trial here.

Enabling MSI on a Windows VM and accessing Azure Storage ^

  1. Sign in to Azure and click on the plus sign to create a new VM.
  2. Pick Windows Server 2016 Datacenter.
  3. Enter the required information, and create the VM in a new resource group.
    Setting up a new VM

    Setting up a new VM

  4. After creating the VM, go to it under Resource groups. Click Configuration and set Managed service identity to register with AAD. This will add ManagedIdentityExtensionforWindows to the list of extensions for the VM. Note that you cannot add MSI as an extension during VM creation, something they'll likely fix during the preview.
    Enabling MSI for the VM

    Enabling MSI for the VM

  5. If you don't have an existing storage account, create one by clicking the plus sign, picking Storage and then Storage Account.
  6. Set it to the ARM deployment model and General purpose type of storage. Pick the same subscription and resource group you created in step 3.
    Setting up a new storage account

    Setting up a new storage account

  7. Navigate to the storage account after creating it, and click Containers (this is a storage construct, not to be confused with the Docker kind of container). Give it a name and pick an access level.
  8. In the storage account, pick Access control (IAM), and then click +Add to add a new role assignment. Pick the Storage Account Key Operation Service Role on the right (every other blade is on the left; not sure why this one is on the right) and Assign access to VM. Pick your resource group that will list your VM, highlight it, and click Select and Save.
  9. Now comes the magic of MSI. Azure Storage doesn't support AAD authentication, but MSI can get an access key from ARM and use that to access the storage without you having to store the credential in the VM.
  10. Log in to your VM by clicking Connect on the Overview page, using the username and password you specified in step 3. Open an Administrator PowerShell window in the VM.
  11. Now we use Invoke-Webrequest to get an access token for ARM from MSI, extract the JSON content, and then get the access token from the response:
  12. Using the access token, we now call on ARM to give us the storage access key so we can upload and download data to the storage account:

    You'll need to put in your subscription ID, the name of the resource group, and the name of the storage account. Again we need to retrieve the key from the JSON data:
  13. To work with Azure storage in PowerShell, we need the module, so run:
  14. To test access, we can use a text file. Create one via:
  15. We can now upload this file via:

    Use your own storage and container names.
MSI PowerShell

MSI PowerShell

The net result is that your VM can access storage without Azure Storage understanding AAD directly. Note that this is full access to the storage account. In a production scenario, you'd probably use the Shared Access Signature (SAS) method instead.

MSI supports several other scenarios at this time, such as accessing ARM from a VM, accessing storage with a Shared Access Signature (SAS), accessing Azure SQL from a VM, both for Windows and Linux variants. There's also support for Azure App Service and Azure Functions. Read more here.

Conclusion ^

Notice MSI doesn't fix the problem of credentials for administrator accounts in the VM itself. Azure requires this during creation of a VM. Instructions for using Key Vault and ARM for this are here. MSI's purpose is to allow access from services in Azure to other services that don't directly support AAD.

It'll be interesting to see what the uptake of MSI is and what improvements will show up during the preview. Keeping credentials out of code is a worthwhile goal.

Win the monthly 4sysops member prize for IT pros


Related Posts


Leave a reply

Your email address will not be published. Required fields are marked *



Please ask IT administration questions in the forum. Any other messages are welcome.

© 4sysops 2006 - 2017

Log in with your credentials


Forgot your details?

Create Account