Please go through the following articles to learn more about Storage Account.
- Azure Storage – Basics
- Azure Resource Manage Template: Create A Storage Account Using Blank Template
- Create a Storage Account and learn how to access It Programmatically
- Azure Storage – Creating Blob Container Using Storage Client Library
In the above articles, we have learnt how to create a Storage Account and perform a few basic operations to the Storage Services. We have also learnt how to create a ConnectionString that could be used to connect to the Storage Account using Microsoft .NET Client Storage Library using Access Keys shown below.
What is an Access Key?
Access Keys are used to authenticate the applications when making requests to this Azure storage account. These are like master keys for accessing the entire Storage Account. Let’s say, you have 100 Blobs, 200 Queues and Plenty of File Shares, then, you can access all of these services using any one of these valid Access Keys.
Azure provides us two Access Keys that we can use to connect to the Storage Account programmatically. You can use either of these Keys (key1 and Key2) in any of your applications (ASP.NET Application, Mobile Apps, Web Services etc.) to access the Storage Accounts and perform operations with the Azure Storage Accounts.
Below is the sample ConnetionString which should be used for connecting to the Storage Account.
DefaultEndpointsProtocol=https;AccountName=<StorageAccountName;AccountKey=<This is the key. You can use either Key1 or Key2 here>;
Few of us might be confused (at least I was for a long time) on why should I have two access keys and what is the difference between the two? Before discussing the answer for this questions let’s understand the use cases of sharing these Access Keys with different resources.
- You might use Key1 in a Web Application for accessing static html files stored in ‘images’ blob container stored in the Storage Account.
- You might use the same Key1 in a Mobile Application for accessing ‘mobile-images’ blob container stored in the same Storage Account.
- You might have shared it to some other developer working on different project.
Because, you have shared the Access Key of your storage account, there is a good chance that it might have got compromised and you would like to change the Access Key so that all non-intended application cannot access your Storage Account.
Azure Storage Account allows us to invalidate an Access Key by regenerating a new one as shown below.
Below is the screen capture after clicking on Regenerate Key for key1.
Note that the old Key1 is replaced with new.
Before regenerating the key, it prompts for a confirmation shown below.
Please be cautious that the old key is not recoverable. Which means all your applications that are using the old key will not work anymore as they are now using an expired key.
Below is the error message that you get when using an Invalid key.
You wouldn’t expect this behavior in your production environment. Let’s say, all your applications are using Key1 and you think that it’s compromised now and you would like to regenerate the same. All you have to do is, instead of regenerating the Key1 key immediately, you need to replace the Key1 in the Connection Strings of all your applications with Key2 and then regenerate the Key1 so that all other unintended users / applications will not work anymore.
That’s it. We have learnt why Azure provides two different Keys for accessing the Storage Account. Hope you enjoyed reading the article. Your feedback is appreciated.
Do you like this article? If you want to get more updates about these kind of articles, you can join my Learning Groups
First of all Thanks a lot for explaining it in detail. But my doubt is that there will still be downtime for applications, as they have to change the key somewhere in config/code when migrating from key-1 to key-2. Isn’t it?
And if there is downtime anyways then we could have simply refreshed the primary key and handover the new primary key to all the application.
You are right. It does make sense to use Key1 just by refreshing it if..
1) You know where you have to change the key.
2) You have acccess to prod environment of the application
3) You have appropriate access to azure to refresh the Key1
4) You know how to deploy and where to deploy.
5) You are not using DevOps Processes (it takes time to run the pipelines)
6) if you have only one application
If your answer is NO to any one of the above questions, then using Key2 makes more sense