Description: It will talk about the different types of Azure Storage Mechanisms existing in our platform as well as some of the ways we can secure access to the storage nodes.
In this topic, we are going to talk about Azure Storage. We will talk about the different types of storage mechanisms existing in our platform. We will also talk about some of the ways we can secure access to the storage nodes.
We will talk about what are each one of the storage options we have. So from a higher level, I will draw out what we have. In talking about storage, we would like to mention that we have a storage account. So in Azure, we will go in and provision a storage account. We will name it just like Mark was saying earlier when you are planning these things out and when you are using resource groups. It is good to plan these out and build your storage account before you start building.
But in considering the storage account as a container, we are talking about blobs. So we have this thing called Blob Storage in Azure. In our storage account, we would have this thing called a container. So, the container is like a folder in a file system. It is a place for us to house our blobs. Therefore, our blobs are binary storage. These could be images, text files and data in any format unstructured that we want to store in here.
It is just like a binary stream we can store these inside. Now the nice thing about this is it scales for you know storage options. We can also have it work with multiple different types of clients as opposed to it being like a file share or something like that only works with applications that could work with stuff.
Page blob is used like a VHD. Those are a stream of how binary bits that are laid down. So we cannot go in and replace certain sections of those bits. We append them to the end or delete them, but we cannot go in and replace chunks of it, like the Block blob.
I define specific blocks I am going to upload, go back and replace ones. I can index into that binary stream and do whatever I need from that standpoint. Block blobs are great for you to comprehend the standard files, images, contents that we have on websites or other similar things.
They work for those, something like I mentioned before like VHDs or something where we do not have to go back and replace those little bits is great for like a Page. You can go up to 200 gigabyte and the Page blob up. This is our primary from a high-level what a Blob Storage looks like.
Now if we did the same exact things and words, we also have Table Storage in Azure. So Table Storage is basically the similar concept. We have our storage account. On top of our storage account, we will have our table. So, this is where we would name our actual table and then we will have entities in our table.
This is Table Storage. In NoSQL and other topics, we have talked about what is involved with the NoSQL database. But from a higher level, this is what we are looking at a Table Storage. Now for looking, the last option we have is queues.
We have a storage account and a queue. Now these are Storage Queues. We have another type of queue also with Service Bus. But what we are talking about is the Storage Queues, which are very simple queues and we have messages inside. That is what we have inside of a queue.
Again, we can provision all these through the portal. We can do Power Shell. We can do them programmatically. These are all different storage mechanisms and all ride on top of the Azure Platform Storage subsystem. Now, these are the traditional ones we have had since Azure was born, but we also have one other option that came out later it rides on top of Blob storage. However, essentially what we can do is: if we have and I’ll draw this out but then we’ll take a look at it.
We can create this thing called Azure Files. Now Azure Files is a concept that allows us to do SMB. So this will be like an SMB, a typical Windows share. If you wish, it is similar to that we’ve developed in the past on Windows Server. So we can set up a file server name you know like this where we had server and we had our server name and then we had a share name. With the same concept, please work in the same way and that is the idea of it.
The scenario is something like this. We have a lift and shift application. So we have a VM here or maybe a couple of VMs. Let us say and these VMs in the on-premise world are pointing up to a file share for something, some data. There are some files up here, maybe some configurations or something of that nature.
Now if we took and lifted this, shifted it to Azure without Azure Files, we had a problem right. We could not do this. We would have to set up yet another VM up here to host the file share, so that these could access it and essentially these were accessing a VM as opposed to accessing a true file share like a NAS type device or something like that.
This is the point of what Azure Files is about. It is about letting you put this SMB share on top of Blob Storage. Now it is a kind of loaded to say that because then it sounds like, I can still use, I can mix and match them.
Once you set up the Azure File Storage, you cannot address it like a Block blob or any other similar things. It is addressed as a share. So there are two ways to access the Azure Files: one is through the file share the endpoint; the other way is through the REST endpoint with the premise that you set it up.
If you are using the UNC path or the SMB share, you can only do it in Azure. With these means, this thing exists up in Azure and our VMs exist in Azure and they can access it. If someone outside tries to access that share, it does not work. It has no public endpoint.
I think an important thing people need to also be aware of is that it is SMB 2.1.A lot of people question why is that and the bottom line. It is because when this was all developed that was the factor standard what most people were doing. In the future course, this will be updated.
If I could use the Azure Files, but I want to expose it publicly, what options do I have? We cannot do it through the UNC share, but we can do it through the REST interface. So we can still access the blob share through a special REST interface to get access to it from the public Internet. So if that is a requirement, we could do that.
The last piece to cover here is about security. So we have talked a little bit about what are the different storage options here. However, we also have to keep in mind security. Now, one of the ways is when we have a storage account and I mentioned we could store things in there, whether they are blobs or queues.
How do we lock that thing down because that has a public endpoint exposed on it? So there are two ways for us to lock this down. One is that we can either use the key, so up in the portal when you generate a storage account, you generate two keys – a primary and a secondary one. Those keys could be accessed and you could use those to write, read, do all kinds of different things in your storage account.
The other way we can do is what called a SaaS token. Now, we will talk about this and I will draw this architecture out. The reason that we have SaaS tokens is that the key mechanism is dangerous if we had a client involved. So if we had an end-user out here, an end-user’s machine that wants to access storage. Yes! We can give him the key, but now he has the key. There is no way for us to revoke the key, those kind of things. We would have to change the key and potentially break our application and that is where the SaaS token comes in.
If we took a look at that architecture what we would say is we have our client here. Let us draw this out. It is not a VM, instead it is a client. So this is our client and he is going to access our storage. So, down here is our storage and we will call it the storage account. However, what we do is we end up setting up a web service here. Now this web service is special. So typically the use case for this is we have a web server and some of these files are in Blob Storage, so the user is accessing this website, everything is happy, they are doing everything, and they got access to let us say a PDF file or a word document or something of that nature and we have stored that in the storage account in Blob Storage.
In order to enable them to get access without the key, they have tried to access this and the web server is going to say, you need a token in order to access that and redirects them to a web service. Now this web service is something you create.
We have an interface for it. It is very simple to implement on your back-end. This is all server side. Usually, what we do is we have some sorts of authentication happening there to make sure he is who he says he is. Once he does that, we will go and use our key to generate a token. So we have this little token. That token gets passed back to the server. Now, he can use that token for the lifetime of that token to access storage. And that my friends shared access storage. It is a great way to lock down your storage accounts so that you cannot control access to the keys. You do not have to give your keys to your clients, but they can still access the storage and that wraps the topic on Azure Storage and security of Azure Storage.