Azure Networking - The Basic Concepts
Most of us have a home network. This network allows your devices to communicate with each other. You can stream movies using your Chromecast, you can send documents to your printer, and even turn your lights on and off again. Imagine how it would be if anyone within the reach of your network could access it. Then suddenly, everyone passing by can control your lights and Chromecast. It may be an interesting experiment, but when you have your personal data stored somewhere within your network, you probably want something in place to protect your network resources from unauthorized individuals.
IP (Internet Protocol) numbers are unique numbers that refer to a device on your network (a network resource). When a device sits in your network, it gets an IP address assigned (or takes one). Each device on a network should have its own unique IP address. There are two major types of IP addresses, IPv4 and IPv6. An IPv4 address looks like xxx.xxx.xxx.xxx, where the x’s are replaced by numbers between 0 and 255, like 192.168.0.1. IPv6 addresses look different. They have 8 groups of 4 hexadecimal numbers, like 2001:0000:130F:0000:0000:09C0:876A:130B. When you want to address a network resource, you do so by its IP address. Alternatively, you can use a URI (also sometimes referred to as a URL), like www.website.com. But now you need a DNS (Domain Name System) server, to translate the hostname into an IP address. And now you still use this IP address to reach a certain network resource.
This is where your firewall plays a role. A firewall is nothing more than a set of rules to allow or deny certain traffic from, or to a location (in a digital network). So at the edge of your home network, often your router, a firewall takes care of what inbound, and what outbound traffic to allow (or deny). Firewalls are often configured to deny all traffic by default and have a specific set of rules to allow certain traffic. So your router is responsible for accepting incoming traffic and routing it to its final destination within your network. The other way around (outboundtraffic) is handled by a gateway. A gateway IP is a device on a network which sends local network traffic to other networks. Any traffic destined for an IP outside the subnet is routed through a gateway. In your home network, routers and gateways are often combined in the same device.
Devices in a digital network, referred to as resources, can be organized in groups. These groups are called subnets. A computer network exists of one or more subnets. When you want to set up network traffic to go from one subnet to the other, you need to configure a mechanism that allows you to do so. With the example of your home network, this doesn’t necessarily apply because most basic home networks only have a single subnet. When you, on purpose, have set up multiple subnets in your home network, you probably already know what you’re doing.
Not only, do you need to set up a mechanism to enable traffic going from one subnet to another. It also allows you to set up an additional set of rules to, in a fine-grained way, allow certain network traffic from and to specific subnets within your network. You don’t have to, but you can.
To the cloud we go
Now you know some of the theory, let’s bring this idea to the cloud. Let’s say you have a website, so a web app, that needs to communicate with a database. When you use the Microsoft Azure cloud, your resources automatically live in a network. The Microsoft Azure network. So you can already take control of some network traffic and configure some rules. However, the is the Azure Network. A worldwide spread network. So when you configure your database deployed in Azure’s North Europe region to be only available from within the Azure network, it is still accessible from a VM that some individual in a different tenant and with a different subscription deployed somewhere in Azure in the Australia region, the other side of the world. Given that fact, you can consider the Azure network as being the public internet. Everyone can create an Azure account and therefore enter your network.
Obviously, most services allow you to set up a little bit more sophisticated set of rules to limit the allowed traffic and take some more control. But still, this is on a network that you don’t manage. IP Addresses change, so being on the safe side matters. Especially when you want to run commercial software in production that, for example, contains data that you don’t want to spread out on the internet.
In Azure, you can create Virtual Networks. When doing so, you create your own network, within the Azure network. And since you own the network, you now have full control of its configuration. Compared to your home network, there is somewhat of a difference. Because now, you are managing a network that runs software that, probably, needs to be available 24/7. So you need to think of a plan for how to structure your network. This starts with an IP plan. So instead of just plugging in another laptop, or connecting a mobile device to your WiFi, you now need to think of the resources your network is going to contain upfront. Virtual networks can grow over time, but resizing networks is an exercise you want to stay away from as much as possible. Making networks too large often comes with a (network) latency, and sometimes a price penalty.
Unlike your home network, you want to take more advantage of subnets. Some Azure resources require their own subnet to demand a certain network structure, other resources require specific settings to be configured before they can be assigned to a certain subnet. Now back to the website example, where you host a website and a database. The cloud allows you to configure flexible scaling on your website, but as your website scales out, each instance requires its own unique IP address. This is the same for your database (depending on what type of database you use). For our example, it would be a good idea to create two subnets. One contains the web app, and the other contains the database. Note that in Azure, for each subnet 5 IP addresses are reserved by Azure to do network management. So when you create a subnet with a space of 16 IP addresses, you can effectively only use 11 of them.
So given the information in the previous paragraph, let’s assume that our website is going to scale to a maximum of 10 instances, and so is our database. That means that both subnets need at least 10 IP addresses available, plus the 5 that Azure reserves, which makes 15. The sizes of networks and subnets are defined by a Classless Inter-Domain Routing (CIDR) notation. This means that you in fact divide all available IP addresses with a number, which results in the amount of available IP addresses. A network configured as 10.0.0.0/26 (this is the CIDR notation) will result in 64 IP addresses available. The higher the number behind the slash, the lower the number of IP addresses available. 10.0.0.0/27 would result in 32 addresses in a range of 10.0.0.0 to 10.0.0.31. This is what we’re looking for in the example of a website and database.
Dividing the network into subnets
In our case, the subnets are going to be of equal size. Both are going to have 16 IP addresses, with effectively 11 addresses available for use. The first subnet needs to be created using the 10.0.0.0/28 notation, and the second using the 10.0.0.16/28 notation. This will result in two subnets with IP ranges from 10.0.0.0 to 10.0.0.15, and 10.0.0.16 to 10.0.0.31. To me, this calculation and arrangement of networks and subnets is more confusing and difficult than actually securing them.
Network security groups (NSGs)
In Azure, you can assign a Network Security Group (NSG) to a subnet. You can compare an NSG with a mini firewall. It allows you to configure a set of rules to deny or allow certain traffic from and to the subnet it is assigned to. You can for example deny all traffic to a certain subnet, except for when it comes from a specific subnet within your network, then allow it. Being able to configure these rules at such a fine-grained level is really key to securing your software system from a network traffic level.