Managing Access Keys and Shared Access Signatures

We're gonna talk about how we can manage access keys and shared access signatures.Our objectives include understanding what our access keys understanding what our shared access signatures and, of course, jumping out and take a look at a demo of how we can use each of these and connecting to our storage account services.

‍

First, let's talk about access keys, access keys, authorized access to data inside the storage account and our services inside of it, like the blobs, cues, tables and file services. Each storage account comes with 2 512 bit storage account access keys, and the reason we have to is you can have one given out to someone used inside an application over access, and then you can give them the 2nd 1 while you regenerate or revoke the 1st 1 This way, they never lose access to the storage account. You know some best practices around these access keys is you want to avoid hard coating them inside an application or storing them somewhere inside of plain text. The's access keys can be considered root access to your storage account, so enmity with ease access keys can have full access to your storage account and be able to manipulate the data or even remove it maliciously.

‍

There is a recommendation to use azure active directory for authorization to your storage count, and that is something we looked at in a previous lesson. But access keys are perfectly valid for using and other scenarios. And like we saw in a previous lesson, we can use the azure key vote to manage our keys and store them. They're an auto rotate our keys for us now real quick. Here is a screenshot of what the key looks like inside a Roger portal. This is just one key. We have the key itself and then a connection stream we can use that has three key inside of it. And here's just a quick example of where you would use an access key. In fact, we've seen it before in our previous lesson, when we connected our azure file share to our Windows server inside of that script, when we created the command key so we could reconnect to our foul share when we restarted the server. The text here and pink is actually the access key to our storage account that is something to consider is if you go to revoke a key or regenerate it, you have tow.

‍

Think about which services are connecting using that key and be able to update those using a new key. Next, let's talk about shared access signatures. This is a uniform resource identifier or your eye that grants access to our stores services. It's an alternative to access keys because instead of having full access to the storage account like our access keys have was shared access signatures, you can delegate specific permissions and also have them be time based, so there are only valid for a certain period of time. The SAS token that's a part of the your eye gives all the information to grant access to the user that has three shared access signature. Now here's a quick example of a SAS token. This may look pretty confusing right now when we look at it, but let's jump into the next slide and let's break this down. So let's break down each part of the your eye and take a look at each component. The first line in the URL is the storage service girl.

‍

This is going to look pretty familiar. Based on previous lessons in this example, the name of my storage account is my storage account. 92837 and we're looking at the Blob's service based on blob d'accord out windows dot net suffix. Next is thes sign version, which is this the version of the storage service to use. Kind of like a tape EI version SS inside the your eye stains four Sign services or which stories, servers and storage account we're gonna be using here be means blob. But we could also have the letter Q for Q Services T for table and F for file he signed Resource Type specifies the resource type that is accessible in the account. Shared access signature as stains for the service level AP I sees for a container level and those for object level, we'll talk about these different kinds in the next slide. The sun permission are the permissions that are allowed inside the your eye on this example. R N w stand for reading, right?

‍

But we could also have D for delete l for list or a for ad permissions he signed. Expiry is the time when the excess signature becomes invalid and along that signs start is when the access signature becomes valid. This is an optional parameter, but if it's not specified, the start time is to be assumed when the service receives the request. Starting in times must be written as UTC time and I s 0 86 So one format. The sign protocol specifies the permitted protocol that could be used inside the request. Here we have https, but H t T P could be included as well. However, only using http is not a valid option. And finally we have the signature and this is part of the your eye that is used to authorize the request in the shared access signature. Now, we just mentioned signed resource type. So what type of shared access signatures can we have?

‍

First, we have an account level which delegates access to all the different storage services inside the storage account. We have our service level type, which specifies a single resource like the blob que table or file service insider storage account. Finally have user delegation where we can secure the token with Azure 80 credentials. However, this is only supported for our blob's service. That doesn't for some of our concepts. Let's jump out to the azure portal where we're gonna take a look at a demo. We're going to rotate our shared access key will connect to Storage Explorer using the access key. Look at creating a shared access signature and how we can use that signature to connect a storage, explore and view our limited permissions. Let's jump out to the azure portal now back here in R J B T 2020 storage account.

‍

Let's go under settings and check out access keys. And here we have to access keys and like you mentioned in the slides, you have to so you can give someone the second key while you regenerate the 1st 1 This make sure they maintain access to the storage account, and no service interruptions occur. Now take a look at key to hear It starts with 22 plus VH. So let's see what happens when we try to regenerate this key. Next to Key to let's click this circle of arrows. It is going to say if you regenerate this one, anything using it is going to lose access. We'll go ahead and click on OK and are key to value has changed and now starts with D. H u R Q. This just shows how easy does to regenerate those keys, but you want to make sure you put some proper lifecycle management around it, so you don't lose access to something when you do this.

‍

Now let's copy this first access key here, and let's jump back over to the Storage Explorer and see how we can connect to our storage account using it back in storage Explorer. I'm still connected to my pay as you go subscription using my Azure 80 credentials. So I want to go ahead and remove. This connection here will go under this account tab VCR's description here. Let's go and click on Remove. We'll select yes, and we'll click. Apply just to make sure it takes effect. Now our subscription is gone and access to our storage account. So let's click on this connection icon. Hear it brings up the Connect to Asher storage, and we're going to select the option to use a storage account name and key. We'll click on next. We'll give it a display name. I'm going to give it the name of the storage account and I'm gonna to specify in the display name we're connecting. Using an access key will enter the storage account name and our storage account key will have the option of selecting which azure region were connecting to what we saw this previously.

‍

And our storage Explorer lesson was gonna leave it at the commercial Azur. Oh, click on next, review our summary and go and click on Connect over here on the left. Under storage accounts, we now have the J. P. T 2020 access key. And if we expand it, we can see we still have access to all our blob containers and file shares so you can see instead of using our azure active directory credentials, we can just use an access key to gain access to our storage account and all of its services gonna go ahead and detached to this connection because we're gonna create another one using our shared access signatures and see how that works. Let's jump back over to the azure portal back in the azure portal under settings. Let's go check out shared access signature. And this is a great form where we can create our shared access signature. Your I in order to create a connection that is limited based on what we configure. First, let's take a look at allowed services.

‍

We can configure the shared access signature to only access certain services. So I'm gonna uncheck file Q and table as I only want to connect to my blob's service. Next, we have the allowed resource type of service container, an object. This just specifies if you want to connect to the account service or maybe just specifically to the container or objects in them going to go ahead and leave this selected at all three. And the real power comes in to allow permissions. We have read, write, delete list at and create wheels. Have updating process for other services. For this example, I only want to allow this shared access senator to read and list objects inside our container, so I'm gonna uncheck the rest of these options.

‍

Another great thing is our starting expiration times a default eight hours and when you can also specify the time zone this allows this year L to expire at some point, we can also specify allowed I P addresses so we only allow connections from these I p addresses and are configured protocols. Probably good idea to only leave this at https. And finally, we have our signing key. These are actually our access keys that we just looked at. And we can use these to sign the shared excess signature. Gonna go ahead and leave it at key one. And let's generate our shared access, Signature and connections drink. We scroll down, we have our connection string here. Maybe we could use this inside an application. We have our SAS token, which just represents all the options we configure it above. And we also looked at this in our slides and broke down What? Each part, if it means.

‍

And finally, we have our blob's service, SAS CRL, which includes the name of the storage account. I'm gonna go ahead and copy this to the clipboard. Let's switch back to the Storage Explorer and connect using it back in Storage Explorer. Let's go ahead and click on the Connect icon again and in our connector azure storage. Let's use the option of a shared access signature. We'll go ahead and give it a display name again. I'll give it the name J P T. 2020 an s a s and let's paste in our euro. We'll go ahead and click on next reviewer summary and click on Connect and again under storage accounts. We have our connected storage account, but we don't have access to the blob container. This is because the shared access signature when we configured it, we said We only want to connect to the blob service so you can see how we can already use this to limit access based on the your I. Let's go into the vacation pics container.

‍

If you remember, we said, we only want to read our list items. Let's go and select one of these files and try to delete it and see what happens. And down here, under activities we can see we got a failed to delete it based on insufficient credentials. So our shared access signature is working. We said services using this shared access signature can only reader list items not delete or do anything else. And we can just see here that it is working as intended. Let's jump back to the slides and wrap this up that does it for this lesson where we took a look at access keys for our storage accounts, how we can configure limited permissions using shared access signatures. And finally, a demos where we rotated those keys and created shared access signatures and demonstrate how we can connect with them using Storage Explorer Coming up next, we're going to take a look at the final lesson in this module. We're going to configure a network security and secure transfers. See you in the next episode.