Implementing Host Security
Configuring Container Security
The course is part of these learning paths
This course focuses on implementing security controls, maintaining the security posture of an Azure environment, and protecting data, applications, and networks, showing you how to configure security for your containers and virtual machines.
The content of this course is ideally suited to those looking to become certified Azure security engineers.
For any feedback, queries, or suggestions relating to this course, please contact us at firstname.lastname@example.org.
- Understand how to configure VM security including VM endpoints and system updates
- Configure baselines
- Understand key Azure networking components
- Configure AKS security
- Obtain a basic understanding of Azure Container Registry and how to create registries in Azure
- Manage vulnerabilities in Azure
This course is intended for people who want to become Microsoft certified Azure security engineers, or those who are tasked with implementing security controls, maintaining the security posture of an Azure environment, or protecting data, applications, and networks.
To get the most from this course, you should have a moderate understanding of Microsoft Azure and of basic security principles.
Hi there, welcome to Azure Networking. In this lecture, we're going to take a quick look at several key networking components that you need to be familiar with before attempting to configure networking and Azure. We're not going to get into too much detail, because I'm going to assume that if you're preparing for the Microsoft Azure Security Technologies exam, you already have at least a basic knowledge of these concepts already. So for most of you, this should be more like a refresher than anything.
Let's start with virtual networks. Virtual networks are used to connect resources. Whether those resources reside in Azure or on-prem. You use Azure virtual networks to enable secure communication between all kinds of Azure resources between Azure resources and on-prem environments and between Azure resources and the internet. It's important to note that each virtual network which consists of one or more subnets is scoped to a single Azure region.
While you can deploy multiple virtual networks within each Azure subscription and within each Azure region, it's important to understand that each virtual network is isolated from other virtual networks.
When you deploy a virtual network, you can specify a custom private IP address space that consists of public or private addresses. When you connect resources to a virtual network, Azure assigns a private IP address to that resource. The address that it assigns comes from the address space that you assign.
For name resolution, you can use either Azure provided name resolution, or you can provide your own custom DNS server. Resources on the virtual network you are configuring will use this DNS for name resolution.
In much the same way as physical on-prem machines do, Azure resources like VMs, load balancers, and application gateways require unique IP addresses to function. Virtual networks use two types of IP addresses. They include private IPs and public IPs.
Private IP addresses can be allocated to resources dynamically or statically. Resources use these addresses to communicate with other Azure resources or on-prem devices.
Public IP addresses allow Azure resources to communicate with external clients. This kind of address is assigned directly to the virtual network adapter of a virtual machine or to the load balancer. Public IP addresses can also be added to Azure only virtual networks. With that being said, in an Azure only virtual network, all IPs are routable only within the customer's network. Meaning that they won't be reachable from outside.
Subnets in Azure, in the same way as physical subnets on-prem, allow you to subdivide your virtual network. This helps attain logical and security related isolation of Azure resources. A subnets range of addresses must fall within the defined address space of the parent virtual network. What subnetting does is hide the details of the organization of the internal network from external routers. It also segments the hosts within the network. This makes it easier to apply network security at the interconnections between subnets.
Virtual network adapters are used by virtual machines to communicate with other virtual machines as well as with other resources. When you deploy a virtual machine, you configure the virtual machine's virtual network adapter with a private IP address and optionally, a public IP address. It's also important to note that a virtual machine can have more than one virtual network adapter attached to it.
DNS or the Domain Name System allows clients to resolve fully qualified domain names to IP addresses. Although Azure does provide a built-in DNS that supports most name resolution scenarios, there will be times when you need to configure custom external DNS in order to provide the necessary name resolution services. A typical use-case for custom DNS is a scenario where you want to extend an on-prem Active Directory into Azure by deploying a VM in Azure that will function as a domain controller for the on-prem AD.
In situations where you wish to increase scalability or availability of an application that's hosted on a VM, what you can do is create two or more VMs and publish the same application on them. You can then use an Azure load balancer to distribute traffic among the VMs that host the application. In such a configuration, all of the VMs share the same endpoint. That being the case, you can spread the traffic load across multiple servers.
You have two types of load balancers at your disposal; a public load balancer and an internal load balancer.
A public load balancer is used to map the public IP address and port number of incoming traffic to the private IP address and port number of your VMs. And of course, vice versa for the response traffic from your VMs.
You use an internal load balancer to direct traffic to resources that exist inside a virtual network, or to resources that use a VPN to access the Azure infrastructure. This is what differentiates internal load balancers from public load balancers.
I should also note that Azure restricts access to the load-balanced front-end IP address of a virtual network. In other words, the front-end IP addresses and virtual networks are never directly exposed to the internet.
The application gateway is another service that you can use to deploy load balanced solutions. However, unlike load balancers, application gateways are designed strictly for HTTP traffic. That being the case, they use routing rules as application-level policies that can offload SSL processing from load-balanced VMs. I should also mention that you can use application gateways when cookie-based session affinity is required.
Azure Traffic Manager is yet another Azure-based load balancing solution. You typically use traffic manager to balance loads across endpoints in different Azure regions, across hosted providers or across different on-prem data centers. The endpoints of Traffic Manager can be Azure VMs or Azure websites. Generally speaking, you use the Traffic Manager load balancing service to ensure that end users connect to an endpoint that is located closest to their physical location. This typically results in faster response times.
It's important to note that Traffic Manager works at the DNS level. In other words, it uses DNS to direct users to specific service endpoints based on a combination of the traffic routing method you choose, and the current endpoint health. This doesn't mean that Traffic Manager is a proxy, it's not. Once clients are directed to the appropriate endpoint, they directly connect to that endpoint. Traffic Manager doesn't see the traffic passing between the client and the service being load balanced.
At this point, we just have a few more networking concepts to review. Let's take a quick moment to touch on network security groups. Network security groups are used to provide network isolation for Azure resources. This is accomplished by defining security rules that either allow or deny specific traffic to specific VMs or subnets.
A common use case for network security groups is a scenario where you want to isolate traffic between multi-tier applications. For example, if you have a three-tier web app that consists of a web front-end VM, a VM hosting the app and a back-end SQL server that the app VM talks to, you might leverage network security groups to ensure that only the app VM can communicate with the SQL VM over Port 1433. Since there's no need for the front-end web VM to be communicating directly with the back-end SQL VM.
Lastly, let's take a look at cross-prem network connectivity. Using Azure virtual networks and VPNs, you can extend your on-prem network to Microsoft Azure. You can create connectivity between an on-prem network and an Azure virtual network by deploying a site to site VPN that traverses the public internet. However, if you're looking for more security and reliability you can use ExpressRoute to create a connection that doesn't cross the internet. Using either of these two methods allows you to provide on-prem users access to Azure resources as if they were physically located on-prem in your own data center.
A point to site VPN can be used to allow individual users or computers to connect to Azure, just like you might leverage Cisco AnyConnect or any other VPN service to allow users to connect to your on-prem network from home.
With that said, we'll wrap up this lecture. Like I said at the outset, this lecture was probably just a refresher for most of you. But I had to mention these concepts because you may run into them while sitting the exam. I'd rather run through that and have you not see them on the exam, that not go through them and then have you getting hit with questions about them when you sit the exam.
Introduction - Configuring Endpoint Security within VMs - Configuring and Monitoring Antimalmare for VMs - Configuring Virtual Machine Security - Hardening Virtual Machines - Configuring System Updates for Virtual Machines - Starting a Runbook from the Azure Portal - Configuring Baselines - Configuring Authentication - Container Isolation - AKS Security - Azure Container Registry - Creating a Container Registry - Implementing Vulnerability Management - Conclusion
About the Author
Tom is a 25+ year veteran of the IT industry, having worked in environments as large as 40k seats and as small as 50 seats. Throughout the course of a long an interesting career, he has built an in-depth skillset that spans numerous IT disciplines. Tom has designed and architected small, large, and global IT solutions.
In addition to the Cloud Platform and Infrastructure MCSE certification, Tom also carries several other Microsoft certifications. His ability to see things from a strategic perspective allows Tom to architect solutions that closely align with business needs.
In his spare time, Tom enjoys camping, fishing, and playing poker.