Take a look at the access keys available for authentication when interacting with an Azure storage account. Note the option to regenerate keys and the need for two keys so that applications can use one key while another is being regenerated.
Before we start to write any code to connect to storage accounts, we need to deal with authentication and authorization. The simplest way to authenticate an authorized access for connecting to a storage account is something called access keys. Take a look in the Azure portal, select one of your storage accounts, and below the overview you'll see an access keys entry. Click on access keys, and notice on the right hand side there's quite a bit of detail. First the storage account name is significant, so you'll have a set of keys per storage account, you'll have two keys, key one and key two, so that you can rotate keys.
Meaning that if an application is using the first key, you can reset the second one and then let the application switch to the second key and then you can reset the first one. So that allows you always have at least one active and valid key for applications to use connecting to the storage account. Notice that the keys though are essentially your route access, your administrator access, to the storage account. So given one of these keys you'll have full access and you can do anything. So first off, try to avoid using these keys. There are other means of authenticating.
If you do have to use these keys for the types of access your application needs, try not to hard code these into your configuration files, whether it's appconfig, webconfig, and so forth. Rather place these keys in something like Azure Key Vault, and retrieve them from there as necessary. So as I mentioned, try to store these keys in the Azure Key Vault. And do note that you do need to regenerate them, especially when they've been disclosed or they are put at risk, you need to regenerate them and so for that scenario you have two keys at all times. One that your application is using actively, another one that you can reset or regenerate, and you can swap them out.
Another trap, try to document all and any services that you use your storage account keys. It's not always obvious which services, and even Azure services, might have used these keys for access to the storage account. So start early when you create a storage account, start making notes of who these keys have been shared with, for which applications and services would be dependent on them. So now that you've seen how to create a storage account, you can find the access keys and this would be the first way of authenticating and authorizing essentially as a route user for accessing the storage account.
- Azure Storage overview
- Azure Storage security
- Deploying Azure Storage
- Accessing Azure Storage files
- Passing messages with Azure Storage queues
- Storing unstructured data with Azure Storage blobs
- Storing structured data in Azure Storage tables (Cosmos DB)