In this article, we will understand why Azure has provided two access keys to access the Storage Account.
Please go through the articles given below to learn more about Storage Account.
In the articles given above, we have learnt how to create a Storage Account and perform few basic operations to the Storage Services. We have also learnt how to create a ConnectionString, which can 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 the master keys to access the entire Storage Account. Let’s say, you have 100 Blobs, 200 queues and plenty of file shares, then, you can access all these Services, using any one of these valid Access Keys. Azure provides us two Access Keys, which 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 the operations with Azure Storage Accounts. Below is the sample ConnetionString, which should be used for the connecting with the Storage Account.
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. The screenshot is given below after clicking on Regenerate Key for key1. Note, the old Key1 is replaced with new. Before regenerating the key, it prompts for a confirmation, as shown below. Please be cautious that the old key is not recoverable. It 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, which 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.
Understanding Azure: A Guide For Developers