Welcome to today’s post.
I will discuss how to secure your Azure access keys that are used within your Azure applications that are stored outside of Azure.
Your local development environment, where development tools such as Visual Studio or Visual Code are used to develop both in-premises and cloud-based applications, which will have an application configuration file, appSettings.json, which stores configurations that allow your application to connect to databases, authenticate to identity services, cloud services, notification services, and configure logging.
Importance of Securing Settings in a Source Code Repository
The nature of the development environment is that the code in most controlled software development environments is accessed using a code repository, such as GitHub or Azure DevOps Git. When the code is shared between numerous developers in the team, the possibility that access keys, connection strings, and endpoints that are used to access application resources could be leaked and used by an unauthorised external party to access those resources.
There are ways in which we can avoid compromising the configuration settings. One is to not store the settings at all in the repository. This approach may be suitable when the repository has private access and only authorized developers, release engineers and project personnel can access the repository. In cases where the code repository is part of an open-source project and is mostly public access, some of the more sensitive configurations can be referenced from a folder outside of the versioned source project folder or the configuration file settings values can be redacted before committing to the repository.
Another tactic that is used to reduce unauthorized access to keys is to rotate them. I will be explaining what a key rotation strategy is in the next section.
Securing Azure Resources with Access Keys
When an application is deployed to Azure and resources such as an Azure Storage Account are required by the application, two 512-bit keys, a primary account access key and a secondary account access key are created on the storage account.
Example of Azure resources where access keys are used are with include:
- Azure Function Triggers
- Azure Blob Storage Accounts
- Azure Service Bus Queues
- Azure Storage Accounts
These account keys are frequently stored in application settings files in a machine in a production environment. There is no guarantee that our on-premises server environments can be safe so being able to secure and manage the security settings of our cloud-based production environment is critical in minimizing security vulnerabilities should they occur.
One policy that should be practiced is the rotation of access keys for all Azure applications. I will be showing how access keys can be rotated by simply regenerating them. Following regeneration, the existing keys can be replaced with the new access key. By applying this procedure, we ensure that keys which are compromised are no longer useable by their unintended recipients.
An example (with redacted details) is shown for application settings for an Azure Function trigger:
{
…
"Values": {
"AzureWebJobsStorage": "DefaultEndpointsProtocol=https;
AccountName=[storage account name];
AccountKey=????????????????????????????????????????????????????????==;
BlobEndpoint=https://[storage account name].blob.core.windows.net/;
TableEndpoint=https://[storage account name].table.core.windows.net/;
QueueEndpoint=https://[storage account name].queue.core.windows.net/;
FileEndpoint=https:// [storage account name].file.core.windows.net/",
"AzureWebJobsDashboard":
"DefaultEndpointsProtocol=https;
AccountName=[storage account name];
AccountKey=?????????????????????????????????????????????????????????;
BlobEndpoint=https://[storage account name].blob.core.windows.net/;
TableEndpoint=https://[storage account name].table.core.windows.net/;
QueueEndpoint=https://[storage account name].queue.core.windows.net/;
FileEndpoint=https://[storage account name].file.core.windows.net/"
}
}
If a key were to be in the wrong hands and access to your Azure resources being compromised could result in not only data being compromised, but also in excess usage and storage charges being utilized on your accounts.
The recommended method of securing Azure account access keys is to rotate the keys periodically so that old keys are no longer valid for your application resources.
The alternative to manual key rotation is to use Azure Key Vault.
In the next section, I will show how to access shared access keys in the Azure Portal.
Azure Resource Shared Access Keys
In the Azure Portal, when we open a resource, the access keys are in Shared access policies under the Settings menu.
The key is then accessed in the RootManageSharedAccessKey policy, which is shown below:
Select the RootManageSharedAccessKey policy.
The subsequent dialog will show with the following keys:
- Primary Key
- Secondary Key
- Primary Connection String
- Secondary Connection String
Depending on your level of permissions on the Azure account you will have Manage, Send, Listen claims on this policy. In this case the Manage claim is the only option which is preselected:
To regenerate the keys simply select the ellipsis menu on the top right corner as shown in the screenshot below and regenerate whichever of the keys you wish:
Confirm the regeneration.
Before re-generation of primary keys, update all access keys in application settings files with the secondary access keys.
Likewise, when re-generating the secondary access keys, update all access keys in application settings files with the primary access keys.
Once the keys are re-generated, they can be copied and updated within your application settings for your Azure application resource.
If you have setup the Azure CLI on your machine, then key regeneration can be run using the following script:
az storage account keys renew \
--resource-group <resource-group> \
--account-name <storage-account>
--key primary
The above overview has shown us how to rotate primary and secondary access keys for an Azure resource. The benefit of this is that it improves the security of our application settings so that a new set of keys is used to access resources, with potentially compromised older access keys invalidated for older versions of the settings.
That’s all for today’s post.
I hope you found this post useful and informative.
Andrew Halil is a blogger, author and software developer with expertise of many areas in the information technology industry including full-stack web and native cloud based development, test driven development and Devops.
