This is Part 1 of a 3-article series that demonstrates how to use infrastructure-as-code tools – in this case, Terraform – to provision and configure cloud networks. This article discusses cloud networking basics and explains several network securities concepts, including network security groups, routing control, firewall, and DDOS protection. It also discusses Private Links and Service endpoints.
The front ends of your web applications or services are usually publicly available. To access them, your users only need to know the public IP or the domain name and port. However, under the hood, all the requests are handled by the back ends, which can include many sub-services.
To secure your solutions, make sure not to expose your back ends to the public. Instead, limit connectivity only to traffic from front ends. At the same time, the underlying infrastructure running your back-end services, like virtual machines (VMs) or containers, must connect to the Internet to receive software updates or access third-party services. To achieve this connectivity control in Azure, you can use the Azure Virtual Network (VNet).
Azure VNet enables you to create virtual private networks in Azure. The cloud-based, virtual private network is logically isolated from other networks and customers in the same cloud. This means you can isolate resources like VMs and containers by launching them into VNet. VNet also lets you specify IP ranges and subnets, as well as associate security groups and route tables.
You can think of VNet similarly to the traditional home-based or on-premises network. There are many ways to configure it to control access. For example, you can enforce MAC address filtering to enable connectivity only from the registered devices. You can also create several subnets. Devices that join one subnet are visible to each other but are isolated from devices connected to different subnets. You can ensure additional security by defining who can access sensitive information — for example — in the network-attached storage (NAS). Finally, you can also filter and route the traffic using firewalls and route tables.
A similar strategy can be applied in the cloud. Think of the VNet as a software-based router that you configure similarly to your on-premises routers. You can create IP ranges, subnets, network traffic filters, routing tables, and NAT gateways.
The key scenarios of using VNets include:
- Communication between Azure services and the Internet
- Communication between Azure services and with on-premises resources
- Filtering and routing network traffic
- Securing the network traffic
More specifically, you can create the VNet so that it contains two subnets. The workloads running the front end (VMs or containers) of your application can be deployed to the subnet which is publicly exposed to the Internet. Then, workloads running your back ends can be deployed in another subnet which can only be accessed by the front-end services. All other incoming network traffic can be blocked to secure your back ends.
You can also use the VNet to enable secure communication between Azure Resources and on-premises resources. Importantly, using VNet does not generate any additional cost.
Creating and Using the VNet
To begin creating a VNet with Azure Portal, you first need to provide the resource group, name, and region:
Then, you configure the IP address ranges using Classless Inter-Domain routing (CIDR) notation and create subnets:
Finally, you can enable the BastionHost, DDoS Protection, and Firewall. We will see how to configure these components in the final part of this tutorial.
Once the VNet is created (here, the VNet name was set to db-vnet-sample), you can use it for your Azure resources. For example, you can deploy the VM into the VNet:
You can also deploy other Azure resources to this VNet, like when creating an instance of the Azure Kubernetes Service (AKS). When creating a Kubernetes cluster, navigate to the Networking tab and select Azure CNI as the Network configuration. Provided that the AKS is deployed to the same region as your VNet, the dropdown list will include your VNet:
Controlling Connectivity
Now, as with on-premises networks, you need to add specific rules and configurations, which will alter the default connectivity.
For this, you can use the network access control (NAC). With NAC, you can specify the access to your services to approved users or devices within the VNet. Azure provides several services that enable you to configure network access control.
One of the most popular tools is the Network Security Group (NSG).
Network Security Group
NSG is based on the IP addresses and network protocols and enables you to filter the inbound and outbound traffic to your Azure resources within the VNet. When configuring NSG, you provide the set of security rules that can allow or deny the traffic based on the source and destination (IP ranges, for example), service, protocol, and port ranges. Here is an example:
All the rules are processed sequentially based on the Priority. The lower the number, the higher the priority, which means that the rules with lower numbers will be processed before those with higher numbers.
After specifying all your rules, attach the NSGs to the subnets in your VNet as shown below:
Routing
By default, Azure routes traffic between all subnets in the VNet. To override this default configuration, you can specify your own routes. By controlling the routes, you can ensure that all the traffic from the devices or services enters or leaves the VNet through the specific location. You can, for example, ensure that all the traffic goes through the virtual network security appliance.
To define custom routes, you use the user-defined rules (UDRs). To do so, you first create the route table:
After the route table is provisioned, you create the routes. As the following screenshot shows, each route must contain the name, address prefix destination (e.g., the range of IP addresses), hop type, and the hop address:
After setting up the route table, you associate it with the subnet in your VNet:
Application Security Group
Application Security Group (ASG) is similar to Network Security Group, but it operates within the application context. With ASG, you can group a set of resources (like VMs) under the common application tag. Then, you define traffic rules, which are automatically applied to all resources in the tagged resources.
How to Secure the VNet
Two common ways for securing the VNet include Azure Firewall and DDOS Protection.
Azure Firewall
Azure Firewall is a cloud-based managed firewall service. It analyzes the traffic between the trusted network (VNet) and an untrusted network. The purpose of Azure Firewall is to detect and block any malicious network traffic. It is offered in two tiers: Standard and Premium. The Standard version works at layers 3-7 to detect malicious traffic, while the Premium version provides advanced features for rapid attack detection.
When provisioning the Azure Firewall, you need to provide the name, Azure region, and then Availability Zones (see below). Afterwards, you need to select your VNet.
Please note that the VNet should contain the subnet called AzureFirewallSubnet.
Once you have the firewall provisioned, you should add it to the VNet using the VNet settings.
DDOS Protection
A distributed denial of service (DDOS) aims to exhaust your application so that it becomes unavailable to the users. You can enable DDOS protection when setting up your VNet.
When DDOS protection is enabled, all resources deployed within the VNet are automatically DDOS-protected.
Private Links and Service Endpoints
One of the biggest challenges and concerns when creating cloud-based solutions is access to on-premises networks. For some architectures — especially when the protection of user data is critical — you want to create hybrid solutions. For this reason, VNets provide the Private Link resource. This service enables you to privately access the Azure resources from the VNet or the on-premises network.
When you need to securely access the resources deployed to the VNet, you can also use service endpoints. Service endpoints provide secure and direct connectivity to the resource. With a service endpoint, you can reach the endpoint of the Azure service from the private IP addresses within the VNet. Otherwise, without service endpoints, you would need to add the public IP to the VNet.
VNet Peering
You can also connect one or more VNets using VNet peering. As a result, the connected VNets will effectively work as one virtual network. The traffic between VMs and other resources deployed to individual VNets will be routed between them. So, all resources will be able to connect.
Summary
In this article, we introduced Azure Virtual Network as the approach to isolate and secure your cloud resources. We discussed cloud networking basics and explained several network securities concepts, including network security groups, routing control, firewall, and DDOS protection. We also learned about the Private Links and Service endpoints.
In the next article, we will learn how to automate VNet deployment and provisioning with infrastructure as a code using Terraform.
To learn more about how, through IaC, you apply software engineering practices such as testing and versioning to your DevOps practices, check out the resource Infrastructure as code.
