Azure Virtual Network and PaaS Network Controls

hey everyone welcome to this new video all about virtual networks and how they can interact with the azure path services things like an azure storage account as a sql database azure cosmos db so i think there's a little bit of confusion when i hear about network security groups and service endpoints and service tags and endpoint policies and private link and what does it all mean so firstly i can think about a virtual network so remember a virtual network is an isolation boundary a virtual network lives within a certain subscription and then it's created within a certain region i cannot span subscriptions i cannot span regions with a virtual network so i create a virtual network and i defined my virtual network as one or more let me make a little bit clearer one or more cider ranges and those cider ranges can be ipv4 they can be ipv6 remember a side of range is kind of like the network component and the number of bits that make up the subnet mask so it could be for example 10.1.0.0 slash 16. so then i could have many different subnets within there 10.1.1.0 24 etc but i could have multiple i could also add in well i'm going to add in 192 168 dot 5.0 24 as part of the virtual networks range i can add more than one side of range within that virtual network i break it up into subnets so i would then create a subnet i'm gonna get multiple subnets and that subnet is defined as an ipv4 cider range so a subset of the ip range of the virtual network so it could be 10.1.1.0 24. optionally i can also have an ipv6 side arranged but we're not going to talk about ipv6 and then i create resources within there so if i was then to create a resource let's say it could be a vm but i create a resource it has a private ip so that's an ip allocated from the ip range of the subnet there could be other resources in this subnet in other subnets and they can all communicate using those private ip addresses but on its own i can't really talk to anything else if i want to talk to other things let's say for example there's another virtual network over here well i could do peering those ip ranges cannot overlap but now they could talk i could have on-premises and maybe my on-premises is connected by a site-to-site vpn maybe it's connecting via express route and once again the ip ranges could not overlap but now they could communicate if i don't do anything else that v-net is kind of that boundary of communication i can't talk to any other entities now what i also have out there is obviously the internet so i can think about well over here is the internet now the internet is all made up of public ip's these are routable on the internet so all of these private ips they wouldn't route to the internet so what happens is when i go and talk to an internet service what's actually used is well there's going to be a public ip so i can think about a public ip is used so when i let's say from this vm go and talk to the internet it actually is going out via a public ip who then goes and talks so that's kind of a request and then i can get a response back now if a virtual machine has a public ip and an instance level assigned directly to it then it's really kind of simple it doesn't know it has a public ip azure just does that for me but if it doesn't maybe that's just automatically assigned behind the scenes like an implicit public ip azure just uses one for a group of vms if i'm behind a standard load balancer i can do outbound nat rules and it will use the public ip of the load balancer i can have a nat gateway that there's different means but essentially to get to the internet i have to use a public ip so everything is really just blocks of ip addresses i've got blocks of ip addresses in my vnet blocks of ip addresses to networks i might talk to there's things out on the internet they're using routable blocks of ip so it's ip blocks and routing so you're saying okay what does this have to do with the path services so if i think of azure pass services for a second they are pretty much all multi-tenant so let's think about azure paths i could think about for example storage so maybe this is azure storage maybe we call it storage account 01 maybe i also have a database i could have a terrible database but i could have things like azure sql database and there are many many others all of these services are obviously internet facing they have public ip blocks there are huge numbers of public ips these services actually leverage we can actually see them so if i jump over to a browser and i go and look there's actually a file i can download and get a list of all of the ip ranges and service tags used by azure and i can actually go and look at that file so we'll jump over here and here i can see all of the different services if i go and look at this file for a second and find my cursor there we go so i can scroll through this massive file these are all various public ips used by different services let's see this one is hard to scroll so quickly um there's a name so batch node management um if we kind of keep going down see all the public ips that it's using and i'll see azure storage rc sequel rc cosmos some of them will be region specific for example if i search for let's say south central so now i can see where there's action groups for south central u.s there's a huge number of these various services available and then what i can actually do is i'm going to cheat a little bit i can run a bit of code and what i'm going to do here is i'm going to get a list of all of the service tags that exist for south central and then i'm going to run a command to actually get the details for the prefixes just for storage in south central see there's a whole array of them if we see well how many actually are there because there's 41 in total and we'll actually go and look at the details of them there's a huge number of these so i've got all of these different available to me that's being used just for that storage account so this shows hey these past services really they're just accessible via huge blocks of public ip addresses so when i use those if i'm in a vm if i don't do anything else i'm still accessing them it has to be viable public ip so if i want to go and use a storage account what's really happening is well once again i'm going out by whatever public ip i have available and then it's going to go down to one of the public ips and i'll get my response back but it's going via the public ip that's kind of the key point of this is nothing magical now it doesn't actually bounce all the way out to the internet and come back again um within the azure data centers there's various routers and switches that it is going across but it doesn't actually go out to the internet and back in again but it's not a direct path there are various router switches within there and any azure service if it's interacting with the internet it has to use a public ip be it azure bastion if it's azure firewall if i'm offering something i have to have a public ip so okay so now let's think about how do i control that then how do i start to control maybe the past services i want to use and then how can i lock down the past services maybe only certain virtual networks now one thing i would say up front before i start thinking about locking down access to pass services if it's for maybe regulatory reasons um there's some sort of corporate driver and i don't want to use certain services in certain regions remember azure policy as a policy would stop being created in the first place if i use azure policy i apply it to management groups to subscriptions i can block creating types of resource and i can block creating in certain regions so the best defense would be not to let it be able to be created at all however i still might want to be able to lock down certain communications so the way we lock down absolutely is i can apply at a subnet level a network security group so an nsg so i can apply these nsgs now i can also apply at the neck of a virtual machine generally we don't want to apply them at the beginning there's no benefit to that it's easier from a manageability perspective to apply it actually at the subnet level and i'll explain a bit more detail about why because people i think get confused firstly i guess something to stress an nsg is not an edge device it's not some appliance that lives at the boundary of the subnet realistically what actually happens with these things is if i think just for a second about well there's a physical host where my vm runs that physical host actually has a virtual switch and in that switch this thing called the vfp the virtual filtering platform now i then go and have my virtual machine my vm has a nick attached to it which then goes and connects to the switch nsgs these things we're talking about are enforced in the virtual filtering platform so it doesn't matter if i apply the nsg at the subnet or the nic it's always enforced at the switch all you're really doing by applying it at the neck is making your manageability harder it's not saying hey i'm going to apply at the subnet and the nic i'm going to get double protection it's enforced at the same place it's always applied at the switch level so from a manageability ease of use it's better to create the nsg and actually apply it at the subnet so okay what is this nsg thing so it's a network security group and it's really based around the idea of rules now i can have rules for inbound and outbound and it is stateful what that means is if i allow a rule maybe outbound to the internet i don't have to create a rule allowing that traffic to come back from the internet i don't have to open up holes to the internet when the response comes in it will let that response come in because it's stateful now what those rules actually are made up of i can think about well there's a source there's let's see there's a destination there is a port there is a protocol and then kind of my action am i allowing it or am i denying it and i think paul and protocol action they're kind of fairly obvious let's talk about that source and destination this can absolutely be an ip range so i might define as an ip range hey the ip ranges for this subnet for this service i could do individual ips i could do entire ranges of ips so i could control things using ip ranges but remember we're kind of focusing right now on the idea that well hey i maybe want to control access to certain path services and as we kind of saw just this storage account alone has 41 different sets of public ips just for a storage account service in south central so i'd have to have 41 different ip ranges that do get updated they'll be super hard for me to track so the other one we have here are service tags all a service tag is is what i ran in that powershell if we jump back to that powershell for a second we can see i looked at all of the service tags and i looked at the prefixes and it's just this giant list of prefixes the first one is 13.65.107.32 28. there's a whole bunch of these i can actually go and look at all the different service tags that are available so here we can see their service tags for action groups for api management are they inbound or outbound can they be regional so again if we look at things like scroll through pretty quickly but if i look for example at storage i can see yes that's regional sql yes that's regional and these are mainly outbound i'm going to control those services don't reach into my virtual network then things from my v-net i want to go outbound too some of them they may be like action groups that they might go and reach into your v-net for example so i can see the direction of the various services that these are all of the service tax if it's regional it will be this tag dot the region name so now i can use these as part of my nsg rule so rather than having to go and remember what all of the different ip ranges and update it every time microsoft updates i can just control it so if we jump over and look at the network security group we look at an example one i can look at for example i have inbound walls and i have outbound rules now by default ignore the two at the top they're special ones that i created you can see the priority 1000 and 4096. um i created those well one of them was actually created by azure security center but we have these default ones and essentially it's saying well allow v-net inbound from the virtual network to the virtual network so within the virtual network anything can talk to anything on any port any protocol it allows the load balancer health probe to talk to it but it's denying everything else so from the internet for example inbound would be bad outbound which allows again any communication v-net to v-net it allows anything to go and talk to the internet remember it's stateful so i can get the response back and it denies everything else now that virtual network and internet they are just service tags so if we look firstly at virtual network virtual network is the known ip space it's the ip space of the virtual network and any connected virtual networks or any other type of network so virtual network would be its own v-net any v-nets it's peered to any networks is connected to by a site-to-site vpn or express route they would all be the virtual network so don't think of vnet as just its ip range it's the known ip space of anything it's connected to as well so i can really think of breaking that up into okay if i think about the entire kind of ip space i can think about well there's kind of virtual network and then the other tag that's super common is internet so the internet service tag represents everything in the ip space that is not the virtual network it also doesn't include kind of the rfc 1918 there's a few other little things and that's blocked from it but think of internet as everything that is not the known ip space that's connected or is your virtual network virtual network is everything i'm connected to so i have those service tags that enable me to not have to worry about what sort of different ip ranges um this pass service could actually be so that's what i would use if i jump over to the portal if i wanted to add let's say an outbound rule maybe i took off the internet the past services remember what's the range internet is everything that is not the v-net everything that's not the virtual network so all of those azure pad services well they live in the ip range of internet so if my nsg lets me talk to the internet it lets me talk to the pas services as well that's kind of an important point so let's say i turn that off i blocked the internet now if i wanted to go and allow certain services well my source would probably be my virtual network my destination would be a service tag and that service tag now i could go and find the service so if it was storage well hey i could say well i want storage but only in i lost that but only in a certain region so i can say hey storage in here we go south central so i could select there i would select the right port and based on the type of interaction i'm doing protocols allow etc etc so i could use those services that's all a service tag is it's simply a representation of the ip ranges of that service it saves me hands try and worry about what the ip ranges that's all it's doing now the other option is more to do with my services my virtual machines because if i wanted to use control maybe only these vms are allowed to talk to this type of service maybe middle tier rather than the source having to be an ip range maybe it's just certain types of vm so one of the things i can also do is on the virtual machine let's just look at one of these look at its networking i'm saying called application security groups what this lets me do is essentially add tags to that virtual machine i could say hey it's a a web virtual machine like because that's in quarantine then in my nsg rules i would say hey don't let this talk to anything except a remediation subnet but if i configure these application security groups these tags if i go back now and again we're going to look at our network security group and again i can look at my outbound rule for the source instead of it being the virtual network or an ip range i could say hey only let it come from vms that have that particular app security group that tag on them so it's another way to kind of control how i can actually do that and remember for all of these it's enforced at the switch level so i don't have to worry about some edge device or anything else it's involved there so i have app security groups as my other option so i can absolutely use nsgs to control access so what is the nsg doing nsg is really all about controlling what i within the v-net can or can't talk to nsg is controlling what i can talk to fantastic what about controlling who's allowed to talk to actual specific pass services remember those nsgs are not instant specific i'm just saying storage in a region that's it i could talk to any storage account and i'm not really protecting the storage account from other v-nets or other things that may want to talk to it now for our various past services most of them do have some kind of control they have the ability to have like a firewall they do have configuration that helps me control who can actually talk to them but i can't just use ip range because most of these are using rfc 1918 every v net in azure is probably using a similar set of ip addresses i also don't want to say we'll just allow anything running in azure because there could be a bad guy sitting in a subscription next to me that wants to go and hack my storage account so i need some way to actually identify individual subnets not by ip range but by the subnet itself and this is what service endpoints so remember service tags are the public ips that make up a certain service a service endpoint is something i can configure on the subnet and i configure service endpoints for particular services for example i might say storage and if i go and actually look at the documentation it will tell me will service endpoints available for storage sql all the things like postgres mysql mariadb cosmos keyboard service belts etc etc so a whole bunch of services support this service endpoint concept and what this essentially does is it makes this subnet known now to that type of service so if i jump over if we now go and look at a virtual network we'll pick a particular subnet it's enabled at the subnet level i'll pick the infrasubnet you'll see i can turn on particular types of service endpoint in this case it has sql and storage enabled for it so just for that particular subnet it has storage and sql enabled that's doing actually two things the first thing it's doing is now if i was to go and look at a storage account so i'll go and look at a storage account for storage accounts it has to be in the same region or the paired region i think the sequel has to be in the same region others it could be different regions but if i now pick the storage account in that same region if i was to now go and look at its firewall i could now say hey i'll only allow access from selected networks and i could actually now add an existing virtual network if i go and pick my network i can now see my info subnet is ready it will actually do the work for me if i have not actually gone and defined that service endpoint myself if i just check one where the endpoint is required it will go and configure it on the subnet for me as well but essentially now i could lock down this particular storage account to only that particular subnet it now gives me that capability so i can completely lock it down so only that subnet just as a point if i actually wanted to lock down completely and a service to no public access i would say selected networks and then not add any then nothing could actually get to it so that that isn't options do that but you notice so adding the service endpoint has now made that subnet known to the service so by adding the service endpoint on the firewall i could actually now say hey that particular subnet one i'm gonna allow to actually talk to me but it's doing something else as well it's now establishing a path from the subnet in the most efficient route to that service and that path will now use the private ip of the source so this will no longer see the public ip it's actually now going to go directly by the private ip and i can look at that so if i'm going to kind of sneak around a little bit if i go and look at a network adapter of a vm in that network i can look at the effective routes this will show me all of the routes it knows about so it takes a second to go through these are all automatic and it's actually cool to look at so here you can see obvious ones hey i can see the iop range of the virtual network i can see the address prefix so everything is the internet uh i can then see some ones it's kind of black holing next top is none for all of the other rfc 1918 space some other ip ranges but now the ones i really care about are these virtual network service endpoints and i can see hey look the second one down 113.65.107.32 and 40 more let's jump back to our code for a second there were 41 of them and the first one was 13.65.107.32 look familiar yep so that is the route that was added when we added service endpoint for storage um here so now i've got all of those routes it's not going to link directly through to that in the most direct way possible so it's not going to bounce out by a public ip the routing table now for that subnet has a fast path a direct path not fast above like express route has a direct path the most optimal path possible from that subnet to actually get to the storage account note this service endpoint is not usable by other subnets i'd have to add the service endpoint specific to the other subnets it's not usable by paired networks it's not usable by a site to site or vpn it's only for that particular subnet so that's what service endpoints do two things it gives me a better path to get to it because it's updating the routing table now say hey if i want to get to all these public ip addresses use this service endpoint for the next top next hop means the place to go next to get somewhere and it makes it known to that service so i can now enable it and maybe block other things so that's what service endpoints are all about so these endpoints are all about hey i can now protect my services to only be able to talk to particular subnets for example but it's one thing we've not solved um and it's really data exfiltration the idea that hey i'm in here i'm allowed to only talk to maybe storage services in a certain region great the storage account is protected so only i can talk to it great but um there might be another storage account in the same region sa02 and i am allowed to talk to storage in that region so i could connect to this one because i'm allowed to buy its firewall get the data and copy it to another storage account that would be a bad thing so the next thing we can actually do is essentially a service endpoint policy and what that is going to basically say is hey you can use sa01 but you can't use sao2 so now if i actually try to connect to a different storage account it will kick me out so we can go and look at that if we now go and look at our service endpoint policies i've got one created if i look at the policy definition i can actually lock it down to a particular account which is what i've done here i could lock it down to all accounts in a certain resource group or lock it down to all accounts in a certain subscription it lets me lock down so i create this service endpoint policy and then i associate it to a subnet so once i do that association then it would lock it down to only be able to talk to the particular instances of the storage account that i have in that policy so it's really giving me that ability to lock that down so those things together i have really now restricted it down i've restricted the services i can talk to based on a region with the nsg i've given myself a direct path to certain types of service with service endpoints and protected that service to only certain subnets and of the service endpoint policy i can only talk to particular instances of that service that i've allowed so that's kind of bringing all those different things together but there's another now i'm going to talk about this pretty quickly because i have other videos on this and i'm going to start a different picture just for the cleanliness sake so again i have the same virtual network i have the same one or more subnets i have the same idea that there's some paths service over here that i want to get to and what we're going to do is we're actually going to talk about private link and private link has a number of different benefits i can use it for my own custom services but if i'm thinking about pes what it actually lets me do is this service can essentially get an ip we'll call it ip5 in my subnet that responds actually will go to a particular instance so it's not like a service endpoint that is all instances of that service type it's that particular instance so this is instance specific if there was a second storage account i'd have to have another private endpoint particularly cosmos db an endpoint a sql database an endpoint and in fact for storage i have to do an endpoint for blob and endpoint for files and input tables etc so now services within that subnet or other subnet or peered networks or it gets even better connected networks so i've got some connection here again it could be site to site could be express route providing they have the right dns so there's a special dns private link um variant of the zone as long as they have access to that and can resolve it to that private ip they can use it remember other networks couldn't use service endpoints private link they can as long as i can do the right dns resolution anything can use that private endpoint so it's giving me now another way to control access so now i could essentially block everything and just create private endpoints so i can't physically get to anything else i would block everything else and now only these private endpoints now today private endpoints ignore nsgs so i don't have to worry about creating special energy to allow this to get to storage i'll be able to get to that storage account if i'm blocking it with my nsg at the subnet if i've created a private endpoint to that storage account i'll be able to get to it so that obviously stops data exfiltration as well because i can't physically get to any other storage accounts and i can use it from other networks so that's what i really think about i mean that was my message about controlling access now obviously as well um if i have a virtual machine i'll just draw a bigger vm remember the vm itself well it probably has a firewall in it so that i also have to remember to if i'm blocking things to enable it through the firewall within the guest there are other options so when i think about networking for example i can absolutely have special subnets with things like a network virtual appliance or azure firewall and then i can tell subnets will actually route traffic using user defined routes then just like that automatic routing table we saw i can actually say hey i want to add my own so instead of going out via this service next top always go into this nva or this azure firewall and it's gonna perform checks and you can actually see those as well so if i actually jump back for a second and look at that network card just for completeness if we look at the effective routes again those private endpoints i talked about they get added into here you can actually see them within here you'll actually see hey look interface endpoint i have two here the bottom well one up from the bottom the 1.4 the 1.5 they are private endpoints that i actually have created within here for storage um within my account also when you do peering you can see hey the next top is to use global v-net peering i can see those in here as well that bottom one is because i enabled v-net integrated azure cloud shell so that kind of did an interface in there you can see that 1.41.5 using an interface endpoint well if i was to actually go and look at my storage account and actually look at my private link and look at my private endpoints you can see i've got two one of them is 1.4 and one of them is 1.5 so everything really kind of comes together so look at those effective routes fiber nick is a great way to kind of go and see and understand some of what is happening so i hope this made sense nsgs let me control the inbound and outbound flow of traffic service tags are just something i can use in the rules to simplify not having to worry about the tens of different ips that might be used for a pass service i can use those tags remember virtual network is the known connected ip space not just the v-net internet is everything that is not the v-neck including those past services that would still be used by the public ip so a service endpoint creates a direct path we saw the routing changes now it uses the private ip so that file will see the private ip and it becomes known that sub that becomes known to the service so i can allow just that particular subnet if i want to actually protect to say hey you can only use these particular instances i can use service endpoint policies and or it's really or private link hey now i'll create an ip address in that goes those particular instances so i hope that was useful um if it was as always please like subscribe comment and share and until next time take care you

Channel: John Savill's Technical Training

Views: 9,201

Keywords: virtual network, azure, vnet, network security groups, nsg, service endpoints, private link, service endpoint policies, paas, firewall, private endpoints

Id: MnARPRQ2kvk

Length: 40min 24sec (2424 seconds)

Published: Tue Aug 25 2020

Reddit Comments

[u/mdnbcfpr]

This is a good video, and it needs to be explained better in general from the Azure side.

The fact that right now PaaS services are all over the place in terms of private link endpoints being GA, public preview, private preview, as well as having dramatically different firewall behavior regarding Azure IPs (SQL Server giving you the option of "allow literally all of Azure or manage it yourself" and most other PaaS services giving you the option to allow trusted service IPs being the most striking example) certainly doesn't help the matter.

And don't even get me started about how if you turn on the firewall on storage accounts you completely break some PaaS services that require a storage account (functions on a consumption plan, batch, etc) with no workaround.

Networking in Azure needs a serious look from MS and could stand to be tidied up quite a bit.