WEBVTT

0:00:01.840000 --> 0:00:07.260000
 In this video, we're going to talk
 about storage account keys.

0:00:07.260000 --> 0:00:12.040000
 And in particular, we're going to take
 a look at the following topics.

0:00:12.040000 --> 0:00:15.380000
 First of all, how to use
 storage account keys.

0:00:15.380000 --> 0:00:19.040000
 Second of all, we're going to deal
 with things to think about in terms

0:00:19.040000 --> 0:00:21.600000
 of securing storage account keys.

0:00:21.600000 --> 0:00:25.300000
 And finally, we're going to take a look at
 a demonstration, a couple demonstrations

0:00:25.300000 --> 0:00:29.760000
 actually, of how you can use
 a storage account key.

0:00:29.760000 --> 0:00:35.600000
 So let's talk about storage account
 keys to start the process.

0:00:35.600000 --> 0:00:38.980000
 First of all, how do you use or why
 do you use storage account keys?

0:00:38.980000 --> 0:00:43.360000
 Remember to access storage,
 you always need a context.

0:00:43.360000 --> 0:00:47.020000
 And you're typically going to create
 that context one of three ways.

0:00:47.020000 --> 0:00:54.520000
 Either by directly using a storage
 account and key combination, or by

0:00:54.520000 --> 0:01:00.280000
 using a shared access signature, or
 by using a connection string that

0:01:00.280000 --> 0:01:01.100000
 has been generated.

0:01:01.100000 --> 0:01:05.820000
 The connection string really just combines
 the storage account name, the

0:01:05.820000 --> 0:01:09.280000
 key, and the way you're going
 to access the data.

0:01:09.280000 --> 0:01:11.280000
 So those are the different
 ways to generate.

0:01:11.280000 --> 0:01:13.900000
 You have to generate the context
 one of those ways.

0:01:13.900000 --> 0:01:18.700000
 Now, the way that you would store this information
 depends on your environment.

0:01:18.700000 --> 0:01:24.040000
 For example, if you're working with
 Azure Web Apps, have app settings,

0:01:24.040000 --> 0:01:27.260000
 they have connection strings that you
 could use, so that I could put my

0:01:27.260000 --> 0:01:30.420000
 key or connection string
 directly there.

0:01:30.420000 --> 0:01:34.760000
 If you're using file shares, file
 shares are a little bit different.

0:01:34.760000 --> 0:01:37.860000
 If you're using the file service, you can
 create a share, and you're accessing

0:01:37.860000 --> 0:01:42.300000
 it through SMB, you
 have to use the key.

0:01:42.300000 --> 0:01:46.840000
 I cannot use a SAS token to access
 a file share through SMB.

0:01:46.840000 --> 0:01:51.660000
 You actually can if you're accessing
 the file share through the REST API.

0:01:51.660000 --> 0:01:56.480000
 But what that means is that anything
 that's accessing your SMB share has

0:01:56.480000 --> 0:02:01.580000
 the key to that storage account and thus
 has access to absolutely everything,

0:02:01.580000 --> 0:02:05.100000
 even beyond the share that
 you are connecting to.

0:02:05.100000 --> 0:02:09.480000
 Any other applications, it really
 just depends on the application.

0:02:09.480000 --> 0:02:13.640000
 Typically, you're going to have some kind
 of configuration file or environment

0:02:13.640000 --> 0:02:18.400000
 variable that you're setting that
 holds this connection information.

0:02:18.400000 --> 0:02:24.120000
 One thing that you have to think about
 when you're dealing with storage

0:02:24.120000 --> 0:02:28.980000
 account keys is you really have to consider
 the security of those keys.

0:02:28.980000 --> 0:02:32.640000
 Because remember, if you have the storage
 account name and you have the

0:02:32.640000 --> 0:02:37.420000
 storage account key, you have absolute
 access to everything in that storage

0:02:37.420000 --> 0:02:40.800000
 account. And that could be
 bad if that key got out.

0:02:40.800000 --> 0:02:45.180000
 So you want to absolutely protect
 your storage account keys.

0:02:45.180000 --> 0:02:47.340000
 Web App Settings.

0:02:47.340000 --> 0:02:51.320000
 So if you have an Azure web app or really
 any app service and you're putting

0:02:51.320000 --> 0:02:56.160000
 the key or the connection string in
 there into, let's say, the settings

0:02:56.160000 --> 0:02:59.300000
 of the web app or into a configuration
 file, remember that's going to

0:02:59.300000 --> 0:03:01.660000
 be in clear text.

0:03:01.660000 --> 0:03:05.680000
 And that means that it's going to be
 at least to some extent vulnerable.

0:03:05.680000 --> 0:03:10.200000
 An alternative to consider
 is using Key Vault.

0:03:10.200000 --> 0:03:15.040000
 Azure Key Vault can be used to
 securely store sensitive data.

0:03:15.040000 --> 0:03:16.380000
 It encrypts data.

0:03:16.380000 --> 0:03:18.060000
 It audits access to the data.

0:03:18.060000 --> 0:03:23.500000
 And it's got strict access control list
 policies that will limit access

0:03:23.500000 --> 0:03:27.400000
 to it. And I can set up a web app,
 for example, so that the identity,

0:03:27.400000 --> 0:03:33.400000
 the managed identity of the web app,
 has access to the Key Vault and can

0:03:33.400000 --> 0:03:37.160000
 pull the connection string, for example,
 out of the Key Vault, thus never

0:03:37.160000 --> 0:03:42.960000
 having that connection string or
 that key stored in clear text.

0:03:42.960000 --> 0:03:47.780000
 Again, any time you're working with
 a key, the way I think about it is,

0:03:47.780000 --> 0:03:50.720000
 really you want to treat it
 like a private key file.

0:03:50.720000 --> 0:03:55.660000
 It's not a private key file, but it
 gives you an awful lot of access to

0:03:55.660000 --> 0:03:57.880000
 the underlying storage account.

0:03:57.880000 --> 0:04:03.960000
 Also, the reason there are two keys
 is because you can recycle a key.

0:04:03.960000 --> 0:04:11.400000
 If a key becomes compromised or maybe
 just as part of good security hygiene,

0:04:11.400000 --> 0:04:16.000000
 you periodically want to recycle or
 change the keys, you can do that.

0:04:16.000000 --> 0:04:20.420000
 However, anything that was using the
 key, either directly or through a

0:04:20.420000 --> 0:04:24.540000
 connection string or any shared access
 signatures that were based on that

0:04:24.540000 --> 0:04:26.820000
 key will no longer be valid.

0:04:26.820000 --> 0:04:29.700000
 And the reason why there's two is that
 if you're going to recycle a key,

0:04:29.700000 --> 0:04:33.780000
 what you could do is you could set up
 your configuration to point to the

0:04:33.780000 --> 0:04:36.520000
 other key. Let's say you're on the primary
 key, you point to the secondary

0:04:36.520000 --> 0:04:40.240000
 key, make sure everything is on the
 secondary key before you recycle the

0:04:40.240000 --> 0:04:43.180000
 primary key, and then you could just
 push everything back to the primary

0:04:43.180000 --> 0:04:47.920000
 key. That's why you have two keys associated
 with every storage account.

0:04:47.920000 --> 0:04:50.320000
 They both give you the exact
 same functionality.

0:04:50.320000 --> 0:04:54.080000
 It's just to give you that ability to
 recycle without necessarily having

0:04:54.080000 --> 0:04:57.680000
 significant interruptions
 to your operations.

0:04:57.680000 --> 0:05:01.860000
 Okay, let's take a couple looks
 at working with keys.

0:05:01.860000 --> 0:05:05.380000
 The first look that we're going to
 have is actually going through the

0:05:05.380000 --> 0:05:08.440000
 portal. We're going to take a look in
 the portal and we're going to pull

0:05:08.440000 --> 0:05:10.940000
 up the keys through a portal.

0:05:10.940000 --> 0:05:18.060000
 Then what we're going to do, if I can
 find my portal and I tab through

0:05:18.060000 --> 0:05:19.160000
 it, there we go.

0:05:19.160000 --> 0:05:21.760000
 Then I'm actually going to
 use this in some code.

0:05:21.760000 --> 0:05:24.320000
 Now, I know this is not a development
 class, but I just want to show you

0:05:24.320000 --> 0:05:28.220000
 the way that an application
 could use an access key.

0:05:28.220000 --> 0:05:32.460000
 Finally, we're going to take a look at
 how you can use an access key within

0:05:32.460000 --> 0:05:35.260000
 the PowerShell environment.

0:05:35.260000 --> 0:05:37.260000
 So if you're doing it
 from the command line.

0:05:37.260000 --> 0:05:38.880000
 Oh, that's not quite fine.

0:05:38.880000 --> 0:05:42.060000
 Then we'll go and we'll take a look and
 see what we've done through Storage

0:05:42.060000 --> 0:05:44.260000
 Explorer just to get
 another look at that.

0:05:44.260000 --> 0:05:45.960000
 I am in a storage account.

0:05:45.960000 --> 0:05:51.640000
 I'm in the INE Storage
 Demo PS1 account.

0:05:51.640000 --> 0:05:53.480000
 If I go to access keys,
 I'll see a few things.

0:05:53.480000 --> 0:05:55.180000
 First of all, I'll see the
 storage account name.

0:05:55.180000 --> 0:05:59.380000
 And I'll see two keys and the
 associated connection string.

0:05:59.380000 --> 0:06:04.440000
 Typically, when you are programmatically
 accessing a storage account,

0:06:04.440000 --> 0:06:08.640000
 you can either go with the storage
 account, name and key or connection

0:06:08.640000 --> 0:06:12.780000
 string. In this case, I've got some
 code that's going to use the storage

0:06:12.780000 --> 0:06:15.720000
 account name and the key.

0:06:15.720000 --> 0:06:19.700000
 So I'm going to copy the name and I'm
 going to pull up some code here.

0:06:19.700000 --> 0:06:21.140000
 Sorry, wasn't quite
 in the right place.

0:06:21.140000 --> 0:06:24.740000
 And this is some .NET Core code.

0:06:24.740000 --> 0:06:27.520000
 It's a .NET Core console
 application.

0:06:27.520000 --> 0:06:30.920000
 The details of the code itself
 are not really critical.

0:06:30.920000 --> 0:06:34.500000
 But I'm able to set
 the account name.

0:06:34.500000 --> 0:06:36.160000
 I've got a variable for that.

0:06:36.160000 --> 0:06:44.920000
 And I'm going to take the account key
 and add in the account key as well.

0:06:44.920000 --> 0:06:47.560000
 Again, I could have chosen
 either of the account keys.

0:06:47.560000 --> 0:06:49.520000
 So now I've got an account
 name and account key.

0:06:49.520000 --> 0:06:56.500000
 And then this next block of code on
 lines 14 through 17, establish my

0:06:56.500000 --> 0:07:00.580000
 context. First, I establish credentials,
 storage credentials based on

0:07:00.580000 --> 0:07:02.880000
 the account name and
 the account key.

0:07:02.880000 --> 0:07:09.080000
 Then I create a cloud account, cloud storage
 account object, which references

0:07:09.080000 --> 0:07:15.560000
 the account based on my connection
 to it, my connection credentials.

0:07:15.560000 --> 0:07:18.040000
 Then I create a cloud
 queue client.

0:07:18.040000 --> 0:07:20.120000
 In this example, I'm
 using a queue.

0:07:20.120000 --> 0:07:22.380000
 Doesn't really matter
 what I'm using.

0:07:22.380000 --> 0:07:25.620000
 I just thought it would be interesting
 to not always use blob storage.

0:07:25.620000 --> 0:07:28.660000
 So I've got a queue and
 I reference a queue.

0:07:28.660000 --> 0:07:32.120000
 Then the next step is I check to see,
 well, first of all, I try to create

0:07:32.120000 --> 0:07:34.180000
 the queue if it doesn't exist.

0:07:34.180000 --> 0:07:35.900000
 And I'm able to do this.

0:07:35.900000 --> 0:07:39.340000
 I have full access because
 I have the account key.

0:07:39.340000 --> 0:07:40.500000
 So I can do whatever I want.

0:07:40.500000 --> 0:07:43.920000
 I can create queues, delete queues,
 same thing for any of the services.

0:07:43.920000 --> 0:07:45.920000
 So I go ahead and create
 it if it doesn't exist.

0:07:45.920000 --> 0:07:50.600000
 And then I just run through
 and upload some messages.

0:07:50.600000 --> 0:07:59.960000
 And if I go ahead and run this, so I've
 done everything right here, popped

0:07:59.960000 --> 0:08:02.420000
 up on another scramble,
 pull it over.

0:08:02.420000 --> 0:08:05.800000
 There you go. Pretty quickly, you
 can see that it created the queue.

0:08:05.800000 --> 0:08:11.100000
 It sent the messages to the
 queue and now it's done.

0:08:11.100000 --> 0:08:21.820000
 So there we go. Pretty simple in terms
 of using a key with the code.

0:08:21.820000 --> 0:08:27.940000
 Now we're going to take a look at using
 a key with our PowerShell script.

0:08:27.940000 --> 0:08:30.780000
 So I have some variables set
 up for PowerShell script.

0:08:30.780000 --> 0:08:33.020000
 And of course I could do
 the same through the CLI.

0:08:33.020000 --> 0:08:37.240000
 But I figure if you see one, you could
 hopefully translate to the other.

0:08:37.240000 --> 0:08:42.380000
 And what I want to do first, in order
 to establish my context, I of course

0:08:42.380000 --> 0:08:43.720000
 need to have a key.

0:08:43.720000 --> 0:08:45.560000
 So I'm going to return the key.

0:08:45.560000 --> 0:08:49.180000
 Sounds like I'm checking
 out of a hotel.

0:08:49.180000 --> 0:08:56.100000
 Return the key. It's a little
 bit of PowerShell fun.

0:08:56.100000 --> 0:09:04.320000
 I'm going to go az storage account
 key, resource group name.

0:09:04.320000 --> 0:09:07.660000
 And the name is going
 to be sa name.

0:09:07.660000 --> 0:09:14.500000
 Now that's going to return a
 collection of keys, two keys.

0:09:14.500000 --> 0:09:19.200000
 I want to get the first key
 and I want to get its value.

0:09:19.200000 --> 0:09:28.820000
 Let's go ahead and run that.

0:09:28.820000 --> 0:09:34.040000
 And if I take a look at the key that's
 been returned, I've got a key.

0:09:34.040000 --> 0:09:41.840000
 Now if you wanted to see the full
 output, select that and run that.

0:09:41.840000 --> 0:09:45.320000
 And there are both the keys, their value,
 and of course are always going

0:09:45.320000 --> 0:09:48.800000
 to give full permissions.

0:09:48.800000 --> 0:09:53.040000
 Now the next thing I need to do is
 I need to create a context using my

0:09:53.040000 --> 0:09:55.060000
 storage account name and key.

0:09:55.060000 --> 0:10:09.660000
 So we're going to go to our sign context
 is equal to new az storage context.

0:10:09.660000 --> 0:10:13.960000
 And I'm going to specify
 the storage account name.

0:10:13.960000 --> 0:10:19.860000
 And I'm also going to specify
 the storage account key.

0:10:19.860000 --> 0:10:25.740000
 That will give me my
 connection context.

0:10:25.740000 --> 0:10:32.360000
 Now if I take a look at this
 context, it gets returned.

0:10:32.360000 --> 0:10:34.860000
 I can actually see a lot of
 interesting information.

0:10:34.860000 --> 0:10:38.560000
 I see the connection endpoints for
 the different services, name of the

0:10:38.560000 --> 0:10:42.020000
 storage account, full connection
 strings as well.

0:10:42.020000 --> 0:10:43.920000
 So I am connected.

0:10:43.920000 --> 0:10:47.600000
 Now the next thing I'm going to do is I'm
 actually going to create a container

0:10:47.600000 --> 0:10:49.360000
 because I have a key.

0:10:49.360000 --> 0:10:51.360000
 I have full rights
 to do everything.

0:10:51.360000 --> 0:10:57.440000
 And I'm going to go new
 az storage container.

0:10:57.440000 --> 0:11:02.060000
 The name of the storage container
 is going to be dollar sign.

0:11:02.060000 --> 0:11:08.880000
 Container. The permission.

0:11:08.880000 --> 0:11:10.880000
 That is the access permission.

0:11:10.880000 --> 0:11:13.520000
 And I'm going to set that to off.

0:11:13.520000 --> 0:11:16.320000
 So there's no anonymous access.

0:11:16.320000 --> 0:11:23.160000
 The context is going to
 be dollar sign context.

0:11:23.160000 --> 0:11:26.120000
 And that's all I need to set.

0:11:26.120000 --> 0:11:28.280000
 There's a few other settings
 that I've got.

0:11:28.280000 --> 0:11:37.000000
 But that gives me the basis
 to create a container.

0:11:37.000000 --> 0:11:38.780000
 And now I have a container.

0:11:38.780000 --> 0:11:43.600000
 Now the next thing that I want to do
 is I want to go ahead and upload

0:11:43.600000 --> 0:11:46.500000
 a file. I've got a
 file name there.

0:11:46.500000 --> 0:11:50.400000
 I've got the blob name that
 I want to use for it.

0:11:50.400000 --> 0:11:55.760000
 And I've never been 100% thrilled
 with this syntax.

0:11:55.760000 --> 0:11:57.440000
 I'll tell you why in a moment.

0:11:57.440000 --> 0:12:01.800000
 Storage blob content.

0:12:01.800000 --> 0:12:07.180000
 Whether the blob already exists or not,
 this is the approach you use to

0:12:07.180000 --> 0:12:10.220000
 set it. If it exists, you
 can have it over right.

0:12:10.220000 --> 0:12:12.800000
 Otherwise it's going
 to create the blob.

0:12:12.800000 --> 0:12:18.720000
 For you, I don't know.

0:12:18.720000 --> 0:12:22.380000
 I didn't create this
 set of commandlets.

0:12:22.380000 --> 0:12:25.720000
 I couldn't have created it, so I
 can't really complain too much.

0:12:25.720000 --> 0:12:28.220000
 And the rest of this is just
 kind of filling this out.

0:12:28.220000 --> 0:12:30.200000
 I've got the file name.

0:12:30.200000 --> 0:12:32.580000
 I've got the container
 I wanted to upload to.

0:12:32.580000 --> 0:12:37.400000
 I've got the blob name
 that I want to use.

0:12:37.400000 --> 0:12:39.020000
 I hope I have the file name right.


0:12:39.020000 --> 0:12:40.580000
 Now the blob type.

0:12:40.580000 --> 0:12:44.780000
 A pinned block or page.

0:12:44.780000 --> 0:12:49.920000
 I can choose once you choose
 for a blob, it is set.

0:12:49.920000 --> 0:12:52.900000
 And that is all I should
 need to set.

0:12:52.900000 --> 0:12:54.900000
 There are other options.

0:12:54.900000 --> 0:12:56.700000
 We set metadata.

0:12:56.700000 --> 0:13:01.600000
 If I've got premium page blobs, which
 I don't, I can set that up.

0:13:01.600000 --> 0:13:02.920000
 Oh, I do need the context.

0:13:02.920000 --> 0:13:06.240000
 Also, if it already exists,
 you could set force.

0:13:06.240000 --> 0:13:15.520000
 This is why I love IntelliSense.

0:13:15.520000 --> 0:13:19.200000
 It reminded me that
 I needed to do that.

0:13:19.200000 --> 0:13:21.920000
 All right. And there we go.

0:13:21.920000 --> 0:13:23.220000
 I uploaded a file.

0:13:23.220000 --> 0:13:28.720000
 Let's pop over to Storage Explorer
 and let's see what I've just done.

0:13:28.720000 --> 0:13:30.840000
 Here I've got Storage Explorer.

0:13:30.840000 --> 0:13:33.960000
 I've already gone into
 my subscription.

0:13:33.960000 --> 0:13:35.540000
 I've got my storage accounts.

0:13:35.540000 --> 0:13:38.300000
 Here's the storage accounts.

0:13:38.300000 --> 0:13:43.220000
 And there's my blob containers.

0:13:43.220000 --> 0:13:45.000000
 And there's my file.

0:13:45.000000 --> 0:13:48.980000
 And so I could double click that and
 it will eventually download and open

0:13:48.980000 --> 0:13:51.720000
 up. So you can tell you it's
 actually pretty cool.

0:13:51.720000 --> 0:13:52.540000
 It's telling me it's cute.

0:13:52.540000 --> 0:13:54.320000
 It's opening. It's downloading.

0:13:54.320000 --> 0:13:55.500000
 And there you go.

0:13:55.500000 --> 0:13:56.560000
 It has opened that up.

0:13:56.560000 --> 0:14:03.580000
 So it's just like double clicking
 the file that is on your desktop.

0:14:03.580000 --> 0:14:07.140000
 All right. Now I also
 implemented a queue.

0:14:07.140000 --> 0:14:10.640000
 And if I click on the queue, these
 are the messages that I sent to the

0:14:10.640000 --> 0:14:12.760000
 queue. It's very simple.

0:14:12.760000 --> 0:14:19.120000
 If you have the storage account key,
 the real takeaway from this now is

0:14:19.120000 --> 0:14:25.920000
 that if you have the storage account
 key, you have everything.

0:14:25.920000 --> 0:14:30.880000
 All right. So our takeaways,
 when do you use keys?

0:14:30.880000 --> 0:14:34.760000
 Right. Possibly in web apps,
 background services.

0:14:34.760000 --> 0:14:38.020000
 And if you are using SMB shares,
 you have to use them.

0:14:38.020000 --> 0:14:44.020000
 You want to try to limit your keys,
 limit where they're used, because

0:14:44.020000 --> 0:14:49.720000
 remember how much access a key gives,
 and there's no way to control that.

0:14:49.720000 --> 0:14:52.820000
 Consider, if you're going to use keys,
 consider protecting the key through

0:14:52.820000 --> 0:14:54.420000
 Azure Key Vault.

0:14:54.420000 --> 0:14:57.900000
 I can set up a key in Key Vault, it
 gets a URI, and then I can access

0:14:57.900000 --> 0:14:59.760000
 that if I have rights
 to the Key Vault.

0:14:59.760000 --> 0:15:02.640000
 It's a very secure way
 of handling your keys.

0:15:02.640000 --> 0:15:08.300000
 And also, be aware of the different
 ways of generating a key.

0:15:08.300000 --> 0:15:13.780000
 And I put in here the CLI, I showed
 you PowerShell, which is the, if you

0:15:13.780000 --> 0:15:17.080000
 were to regenerate a key with PowerShell,
 it would be new AZ storage account

0:15:17.080000 --> 0:15:19.960000
 key instead of GET, that
 would regenerate it.

0:15:19.960000 --> 0:15:24.660000
 If you're going to use the CLI, it's
 AZ storage account keys, and then

0:15:24.660000 --> 0:15:27.300000
 to renew, you would renew,
 or you could list.

0:15:27.300000 --> 0:15:31.160000
 And if you're getting very deep and
 technical, I'll throw these in every

0:15:31.160000 --> 0:15:31.720000
 once in a while.

0:15:31.720000 --> 0:15:34.740000
 You could use the
 REST API directly.

0:15:34.740000 --> 0:15:40.600000
 It is actually a post call, and that
 would be the URL of the post with

0:15:40.600000 --> 0:15:45.720000
 your subscription ID, your resource
 group name, your account name, and

0:15:45.720000 --> 0:15:47.740000
 then it would regenerate the key.

0:15:47.740000 --> 0:15:52.160000
 Lots of ways to work with keys, but
 again, the most important thing I

0:15:52.160000 --> 0:15:56.340000
 can tell you in this video is to be
 very careful with the distribution

0:15:56.340000 --> 0:15:57.760000
 of your storage account keys.