Azure Virtual Desktop (AVD) is a Desktop and App virtualisation service that runs completely in the Azure public Cloud. Virtualisation is a method of streaming a user’s desktop or application remotely to a device so it can be accessed anywhere. Prior to cloud computing in an on-premises scenario, this was often achieved using technologies such as Remote Desktop Services or Citrix.
In a post-pandemic world where remote working is common, AVD allows users to access work-related applications from their own devices anywhere in the world. With the end of support for Windows 10 fast approaching, AVD stands out as a practical and timely solution for organisations needing to transition to a modern, secure platform without immediate hardware replacement investments.
Since its release in late 2019, AVD has continued to add new features and capabilities which has helped it become an extremely useful tool for business and enterprise users all around the world. Some of the key benefits of the solution include:
With the end of support for Windows 10 fast approaching, now is the time for organisations to choose between migrating to Windows 11 or an alternate option.
AVD is a compelling solution for organisations transitioning away from Windows 10. One of its key advantages is the ability to migrate seamlessly to Windows 11 without the need for costly hardware upgrades, enabling organisations to optimise their existing assets while embracing modern technology. Furthermore, AVD’s flexibility in delivering virtual desktops and applications to diverse devices ensures continuity for remote workers and teams spread across different regions.
In addition to its operational benefits, AVD prioritises compliance and security by offering secure, virtualised access to applications and desktops. As the end of support for Windows 10 approaches, this becomes especially critical, ensuring that organisations are not exposed to vulnerabilities associated with unsupported systems. With built-in security features such as identity management, data encryption, and regular updates, AVD provides a robust environment that aligns with regulatory requirements and protects sensitive information, making it an ideal solution during this transitional period.
For organisations looking to stay agile and competitive as Windows 10 reaches the end of its lifecycle, AVD provides a future-ready platform that combines scalability, performance, compliance, and security with all of the benefits listed in the above section as key contributing factors.
As AVD is provided via various licensing options including the ability to provide external user access via per-user access pricing, the service has a number of use cases, including:
The planning and design phase of any AVD deployment is important to ensure the user experience is as good as possible. The apps and desktop should feel like they are running locally to the user and not from the cloud. There are a few performance-related areas to think about when trying to improve the user experience:
As with many solutions in the cloud, performance is important. However, performance needs to be balanced with cost. As previously covered, the cost for users in AVD is via licensing, many of which organisations will already be using today. An additional cost comes from the AVD service and infrastructure running in Azure, which includes Sessions Hosts, Storage, Logging, Backups and Networking.
Licencing costs are easier to predict than the infrastructure, but with correct planning and an understanding of the available features you can optimise for costs. Some key areas to think about when balancing cost with performance include:
Azure Virtual Desktop has become an extremely popular service over the last few years and with the increase in remote working, this isn’t likely to change. As discussed in this blog, the increase in performance alongside the reduction of management overheads is significant compared to traditional VDI solutions, thus making this a no-brainer for companies looking to empower their users via the public cloud. To conclude this blog post, some key takeaways for AVD include:
With a team of experts dedicated to infrastructure and the Azure cloud, our specialists are knowledgeable and experienced and at implementing Azure Virtual Desktop. If you are wondering if this is right for you, why not get in touch and find out how we can help.
Or check out our Azure Virtual desktop case studies:
Considering recent research bringing to light a security risk within Azure Functions storage accounts with key-based access, in this blog post, we will explore how to configure Azure Functions with managed identity for storage access, before disabling key-based access entirely.
Azure Functions is a serverless compute service that allows you to run code on-demand without worrying about infrastructure management. It provides a flexible way to build and deploy event-driven applications and microservices. One of the key features of Azure Functions is its integration with other Azure services, such as Azure Storage.
When creating an Azure Functions App, a dedicated storage account is also created, the Functions App relies on the storage for various operations such as trigger management and logging. By default, this account is created with “Allow storage account key access” enabled. An access key derived connection string is added to the Function App configuration, in the AppWebJobStorage application setting. A common practice is to move the connection string to Azure Key Vault and configure the Function App to fetch the connection string secret on startup.
SECURITY RISK FOUND IN AZURE FUNCTION STORAGE ACCOUNTS KEY-BASED ACCESS
Recent research by Orca Security, a cloud security company, discovered that attackers who have obtained the access key could gain full access to the storage account and business assets. Moreover, the attackers could move laterally within the environment and even execute remote code.
Although Microsoft has already recognised the risks associated with shared key access and recommends disabling it, the default setting for storage accounts still enables this authorisation method. Microsoft recommends that, where possible, key-based access to storage accounts should be disabled and advises using Azure Active Directory authentication for enhanced security and reduced operational overhead.
AZURE FUNCTIONS WITH MANAGED IDENTITY FOR STORAGE ACCESS
Based on a real example encountered in a recent project, here we are going to explore an HTTP triggered Function as an initial example, looking at how to secure the Functions access to its own storage account. Next, we look at a Function triggered by a queue in a different storage account and how to secure the interactions between those two resources.
CONSIDER A SIMPLE FUNCTION APP WITH AN HTTP TRIGGER
The Function App is backed by an Azure storage account. If we visit the Azure Portal and take a look at the Configuration screen, we can see an application setting called AzureWebJobStorage which stores the connection string for the Function App Storage.
Rather than using a connection string, we can switch to an identity-based connection by performing the following steps:
STEP 1: ENABLE MANAGED IDENTITY FOR AZURE FUNCTION APP
Navigate to the Function App Identity screen in the Azure portal and select “System assigned” for the managed identity option. Click save. This will create a managed identity for the Function App in Azure Active Directory.
STEP 2: GRANT ACCESS TO AZURE STORAGE
The next step is to grant access to Azure Storage for the managed identity created in the previous step. To do this, go to the storage account’s Access Control (IAM) screen in the Azure portal, and add a role assignment for the Function App’s managed identity with the role of “Storage Blob Data Owner”.
STEP 3: CONFIGURE THE FUNCTION APP SETTINGS
The Function App now needs to have its setting modified to instruct it to use managed identity when accessing its storage account. Open the Function App Configuration screen in the Azure Portal. Rename the AzureWebJobsStorage variable name to AzureWebJobsStorage__accountName (with 2 underscores). This convention ensures the function uses managed identity to access the storage account. Next, we change the value of this variable to the name of the storage account that was created with the function. Save changes.
STEP 4: DISABLE ACCOUNT KEY ACCESS TO STORAGE
At this point the Function App will use its managed identity to access its storage, so we can safely disable account key access*. In the Azure Portal open the Configuration screen for the Function App storage account. Toggle the “Allow storage account key access” setting to disabled and save changes.
CONSIDER A FUNCTION APP WITH A STORAGE TRIGGER
Beyond HTTP Functions can be triggered in many ways. In this example, we have a Function that is triggered by a new message on an Azure Storage Queue. The Function App needs to be configured to have access to the Storage Queue. The following steps will describe how to achieve this with managed identity.
Important: Requires Microsoft.Azure.Functions.Worker.Extensions.Storage V5 or later
STEP 1: ENABLE MANAGED IDENTITY FOR AZURE FUNCTION APP
If not already complete we need to enable managed identity for the Function App as described above.
STEP 2: GRANT PERMISSION TO THE FUNCTION APP IDENTITY IN THE STORAGE ACCOUNT
The Function App identity must be granted permission to perform its queue actions. In this example, the Function reads a message from a queue, processes it, and removes it from the queue. For this, we’ll give it the “Storage Queue Data Message Processor” and “Storage Queue Data Reader” roles.
Navigate to the queue storage account’s Access control (IAM) screen in the Azure portal and add role assignments for the Function App’s identity with the roles of “Storage Queue Data Message Processor” and “Storage Queue Data Reader”. The role requirements will vary by scenario, so we need to ensure we have assigned the correct role(s) for our needs.
STEP 3: CONFIGURE APPLICATION SETTINGS
If this is an existing Function App with a queue trigger, it will already have queue connection settings. For example, it might have a connection string application setting with the name StorageConnectionString and a value that contains the connection string or a reference to the Azure Key Vault secret containing the connection string. In the below example, we have an environment variable that contains the connection string to a storage queue.
In the Configuration screen for the Function App, the application settings need to be configured with the following convention: The setting name should be in for the format {connectionName}__queueServiceUri (2 underscores). The value should be the Uri of the queue service.
STEP 4: DISABLE ACCOUNT KEY ACCESS TO STORAGE
Now that the Function App uses its managed identity to access the queue storage which will trigger it, we can safely disable account key access*. In the Azure Portal open the Configuration screen for the queue storage account. Toggle the “Allow storage account key access” setting to disabled and save changes.
CONCLUSION
Configuring Azure Functions with managed identity for storage access is a simple and secure way to access Azure Storage resources without storing credentials or secrets in code or configuration files. By using managed identity, we can avoid the complexities of managing and rotating credentials and improve our application’s security. With the above steps, we can easily configure our Azure Functions to use managed identity for accessing Azure Storage.
Note: If any other services have been setup to use this storage account via a key-based mechanism, they will also need to be configured to use managed identity before disabling the account key access.
If you are looking for Azure experts or or help with your app development, be it consultancy or outsourcing, do get in touch and find out how we can be of help.
REFERENCES
