Azure Virtual Network Service Endpoints - explained in plain English with a story and demo

hello and welcome to a short Montcalm this is virtual network service endpoints explained with the why and how using a story and a step-by-step demo on how to configure it in less than five minutes secret recipes was a business which provided Secret Angel recipes to their customers by charging a premium subscription using the site www.secretinfoclub.com the virtual network consists of a subnet where we have the web server for the website www.secretgarden.eu.com storage for this website is hosted on an azure blob storage in this case we know that the virtual machine has a private IP address of 10.0 of 0.4 and the actual sequel does not let's start off with the why for that let's analyze the situation before we had servers endpoints now the VM needed to access the storage account in a way that the exposure to the public Internet is minimized let's pause you for a bit and understand the three things which happens here and the implications of it number one the private IP address of your virtual machine gets translated to a public IP when it reaches out to actual storage number two the access control list of the blob storage itself will need to be updated with the translated public IP of the virtual machine let's take a look at how that is done using the I show portal this is the virtual machine which is making the outbound connection to the blob storage and this is the blob storage account where we would need to update the access control list let's first click on the washing machine and then and then connect to the virtual machine I am going to enter my username secret user and my password and use sebastien to connect to it now that I'm inside the virtual machine I would try and go to portal door ah sure calm from within my virtual machine itself I see the application resource group I would click on the storage account and then go to firewall and virtual networks if you see here you see that the options that are default selected are all networks which means that everybody in the Internet can access my storage account if they have the right credentials which is not something that I'd want to be I am going to restrict the access I choose selected networks and if you see here below I see that my client IP has automatically been populated I select add my client IP and then choose safe the third point is the network security groups or the access control list around the virtual machine itself need to be updated to allow a sure storage as an outbound rule if you are new to network security group I highly recommend clicking on this link to check out the ridiculously simple explanation of network security groups let's take a look at how that's done from the azure portal I would click on my virtual machine and then go to the networking tab if I click on the outbound security rules I would see that I have a deny outbound for the internet my security team is very strict so I go ahead and add a rule for an exception to access a show storage for that I would click on destination as a service tag and the destination service tag would be storage in this case and I would also append this region which is east us in my case I'm only going to be accessing my storage accounts using the port 4 4 3 so I'm going to restrict the port add in the TCP enter my priority and also give it a name and a description once I have all those fields filled out I would click on add and then save I'm good to go from a network security group perspective while we're here one thing to note is that even though there is a public IP the communication between the virtual machine and the storage in this case happens over the Microsoft backbone network without traversing the public Internet all this is great and everyone's happy until the virtual machine starts making outbound connections to the public Internet outside of the Microsoft backbone network the information security team is not pleased with the fact that the virtual machine is making outbound calls to the public internet secret recipes has an on-premise firewall we're all internet bound traffic is inspected and then sent out to the internet so they dictate that every traffic from the virtual machine now be routed on-premise using what we called a forced tunneled route and then go out to the internet after inspection this is acceptable but clearly this had an unintended consequence the internet bound traffic coming back compromise was reasonable but think of the ash of virtual machine crashes sequel traffic this now had to come all the way or chrome eyes the multiple extra hop traffic we just needed to get across the street now travels a lot more than it needs to well this caused slowness in the website moreover the access control lists around the storage account itself did not change we still needed to have a public IP listed only this time it was an on-premise counterpart in short clearly the business wasn't happy they wanted to have the public Internet bound traffic route back on promise but at the same time they wanted to keep the traffic between the virtual machine and the sequel they may not the Microsoft backbone network and the venue would achieve that is using virtual network servers endpoints let's go back to the scenario and talk about how things would change if we implemented actual virtual network servers endpoints the traffic between the subnet where the virtual machine resides to any storage account in the region where the virtual network besides always stays inside the Microsoft backbone network and it reaches using an optimized direct route while still maintaining your force tunneled route to optimize when this is accomplished because of the weight out in priorities work in Asha and I'll make another video explaining that in detail in short for now servers and points takes a higher precedence than the default route advertised great let's take a look at how servers and points is configured from the azure portal in order to configure servers endpoints I would click on the virtual network and then choose my subnet once I'm in the subnet I see the option for servers and points in this case I'm enabling my servers and points for the service Microsoft dot storage and then I click on save the other advantage of servers endpoints is that you can extend the identity of your virtual network to the platform as a service resource in this case as a storage thereby you can letting you remove all the public ackles on the storage account let's see how that's done I would go back to my storage account and then click on firewall and virtual network now I would go ahead and remove any public access control list that I have on my storage account and then I would choose add existing virtual network in this case I have my virtual network which already has servers endpoints enabled so I'm going to go ahead and add that submit and then choose save if you see here the biggest difference is now I don't have any public ackles hanging out of my storage account but I'm still able to access it in a secure way and an optimized route here is the list of services that currently support service endpoints and the list is constantly growing well great everyone's happy right until they found the seemingly similar business called dubby dubby dubby dot not so secret recipes comm and it had the exact same recipes as the original how did that happen on further investigation they found that there was a rogue administrator inside secret recipes payroll who was leaking this information to another storage account in the same region in order to prevent data exfiltration we can limit the storage account that servers endpoints has access to using what we called service endpoints policies let's take a look at how that is done using the azure portal in order to configure servers and point policies I would go to the search icon and then go to service endpoint policies now that inside service endpoint policies I would go ahead and choose add I would now choose my resource group for my secret recipes application and I would give it a name no storage accounts and I would also give it a location in my case it's going to be east US and then I would define my policies so here's where I would choose the allowed resources or allowed storage accounts that my virtual machine or my subnet needs access to now I can limit it to just one single storage account or I can limit it to all the accounts inside my Asha subscription in my case what I'm going to do is allow access to every storage account inside my subscription but any storage account that the rogue administrator tries to access outside of my subscription is going to get denied I choose next and then go to review they go that's all that we need to do from a service endpoint policy configuration perspective this prevents data exfiltration from an Asha storage perspective one thing to note is that as of today service endpoint policies exists only for a short storage and again the list is constantly growing excellent finally everyone's happy that secured the access to the network in the best possible way without compromise on use of the business is getting good as well this is getting too easy to implement that the original chef who had access to the secret recipes now wanted to update the recipes herself by using the blob storage and accessing it from one promise well servers endpoints does not work for on-premise connection you can at any point of time add a natural public IP or the access control list but if you don't want any public endpoints at all in your storage account but still want to access your storage from optimize there is a way using private endpoints will demystify what private endpoint is in the next video thanks for watching we'll see you again in the next video

Channel: azuremonk - cloud in plain english

Views: 31,138

Keywords: lessthan5min, #lessthan5min, explained, simplified, in less than 5 minutes, less than 5 minutes, azure, virtual network, networkinginazure, network, cloud networking

Id: gxsitRRgylI

Length: 11min 53sec (713 seconds)

Published: Mon Dec 09 2019