Welcome to my blog! For more useful information on technical topics follow me on Twitter at @lenadroid and subscribe to my YouTube channel.

For detailed documentation of Azure topics covered in this article, take a look at Managed Identities documentation, Azure Linux Virtual Machines, and Azure CLI. To follow through examples, get started with Free Trial.

Introduction

In this article we are discussing Azure Managed Identities!
Why is it a good idea to use them?
How can they help make access to Azure resources more secure and less error-prone?

TL;DR: They can significantly improve authentication process between cloud resources, reduce operational overhead and vulnerability of managing and storing authentication credentials.

Note: Managed Identities in Azure are similar to IAM roles for EC2 instances on AWS.

Managed Identities? What are they?

Imagine there is an application running on a Linux Virtual machine on Azure. From your application, you'd like to have access to other cloud resources. It could be a file stored on Azure Storage, or a secret in Key Vault, or Event Hubs data source. Traditionally we would need to stote and manage credentials or access keys in application configuration files, make sure we rotate the keys when necessary and keep them secure, which is a challenge. We can store credentials in Azure Key Vault, but applications still need to authenticate to Key Vault to retrieve them.

Managed Identities feature helps authenticate to any of the supported services without needing to store or manage any credentials or access keys in application configuration or code. You can view Azure services that support Managed Identities here. That page also contains Resource ID URLs necessary requesting access tokens.

How does it work?

There are two main steps: requesting access token, and accessing the service providing the access token.

With Managed Identities the application that runs on a VM will ask for an access token by performing a request to Azure Instance Metadata Service identity endpoint. The request will need to indicate which service the token is needed for (e.g. Azure Storage, or Key Vault).

After application receives the access token, it will need to include it in the call to the specific service to be able to access it successfully.

System-assigned and User-assigned identities

There are two options for Managed Identities: system-assigned and user-assigned.

System-assigned managed identity can be enabled directly on Azure resource (e.g. your Linux VM). After it is enabled, credentials are set up for that instance, and the lifecycle of this identity is tied to the resource it's dedicated to, meaning that when the resource is deleted - identity is deleted as well.

User-assigned managed identity is on the contrary a standalone Azure resource that isn't dependent on a particular instance and is managed separately. Therefore, it can be assigned to many resources at the same time. This is convenient when you have a fleet of resources that need same type of access to some Azure service or services.

Some resources can have both system and user assigned identity.

How exactly does it all work?

Let's take a look at a concrete example. Imagine you're running a Linux VM on Azure. On this VM you'd like to run applications that access to a particular stotage account.

Preparing resource groups

We will need two resource groups - to host storage, and a VM. In further examples we might want to create a separate resource group for user-assigned identities.

Creating a Linux VM

To check whether it's possible to access Azure Storage Account through a Managed Identity we will need a VM. The code below creates an Ubuntu Linux VM. Make sure to note its IP address to connect to it in future steps.

Creating a Storage Account

We will also need a storage account, a container within it, and some file we will use as a target resource.

SSH to the VM and access the file

If we now try to SSH to the Linux VM and try to access the "text.txt" file we should get an error, because we haven't yet enabled Managed Identity for the VM.

Assign a System Managed Identity

Because in this case we have a single VM, there's no need for user-assigned identity. Here, we're assigning a system-managed identity with a role and a scope to the VM. Make sure to put the correct storage account Resource ID as a scope. Feel free to explore what other roles are supported by resources you need access to.

Try to access the file again!

The output should now display "hello" this time. Now the VM is set up to allow any of the applications running on it access Azure Storage with scope and role granted to the managed identity.

Clean up your resources

Thank you for reading!

I hope this was useful, and if so - mention me on Twitter - I'll be happy to hear your thoughts!
In the next parts we will learn about managed identities with Azure Kubernetes Service and Azure Functions!