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 email@example.com.
- 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 Configuring VM Security. Before we get into VM policies and templates, I should probably make sure that you first understand the key features of Azure Resource Manager, since it serves as the deployment and management service for Azure subscriptions.
The main function of Azure Resource Manager is to provide a consistent management layer for creating, updating, and removing resources. The Resource Manager is also used to manage access control, auditing, and tagging. This, in turn, helps you secure and organize Azure resources after they've been deployed.
Any time you perform an action via one of the management tools, like the portal, or Azure PowerShell, the Azure CLI, or one of the other available management tools, it's actually the Resource Manager API that handles the request. This produces consistent results and capabilities across all the different management tools.
Whenever you deploy a resource in Azure, the request is handled by the Resource Manager API. Successful requests result in the creation of the resource and the assignment of it to a resource group. Whenever you need to deploy resources that are related to each other, you should use Resource Manager to deploy them into the same resource group. This allows you to deploy, update, manage, and monitor them as a group.
So, now that we've given Resource Manager a good once-over, let's take a look at some key terms that you should be familiar with when working with Resource Manager.
The term Resource Provider refers to a service that supplies Azure resources. One of the more common resource providers in Azure is Microsoft.Compute. The Microsoft.Compute resource provider, as you may have guessed, supplies VM resources. I'll let you guess what the Microsoft.Storage resource provider supplies.
A Resource Manager Template is a JSON file. The JSON file defines one or more resources that you wish to deploy into a resource group or subscription. Using Resource Manager Templates allow you to consistently and repeatedly deploy resources over and over again, without the need to manually configure them each time.
Declarative Syntax is a syntax that you use to create resources without having to write out the sequence of programming commands that are necessary to create them. A prime example of Declarative Syntax is actually the Resource Manager template, because within the JSON file, you define the properties for the infrastructure to deploy to in Azure.
When you use a Resource Manager template to define your virtual machines, you can easily deploy and redeploy them later on, if necessary. As a matter of fact, Microsoft actually recommends periodically redeploying your virtual machines, why? Because it forces the deployment of a freshly updated and security-enhanced virtual machine OS. That said, it's likely difficult to do in practice, due to business SLAs, approvals, and the coordination involved. But that still doesn't mean it's a bad idea.
It's important to understand that Resource Manager processes templates like any other request. What it does is parse the template and then convert the syntax into REST API operations.
Now, because this course isn't about building templates, I'm not going to get into the weeds on template building. However, if you want to learn about building them, visit the URL that you see on your screen (https://docs.microsoft.com/en-gb/azure/azure-resource-manager/templates/template-syntax).
I should also point out, that, because RBAC, or role-based access control, is integrated into the management platform, you can apply access controls to all services in your resource group.
At this point, I want to talk a little bit about the four levels of scope, in the context of Azure management. They include management groups, subscriptions, resource groups, and resources.
The image that you see on your screen now shows how these scopes are related. So, what's the significance of scope? Well, what you can do is apply management settings at any one of these levels. Obviously, the level you apply your settings to will dictate how widely your settings are applied. Lower scope levels will generally inherit settings that are applied at the higher scope levels.
For example, if you apply a policy to a resource group, that policy will apply to not only the resource group itself, but it will filter down and apply to the resources within the resource group.
It's also important to understand that you can deploy templates to management groups, subscriptions, and resource groups.
Speaking of resource groups, let's talk a little bit about them now. Although they are quite possibly the simplest resources that you can deploy, there are some things to consider when defining a resource group.
First and foremost, when planning your resource group deployments, it's important to understand that all resources within a resource group should share the same lifecycle. You should be deploying, updating, and deleting such resource all together. An example of this would be an internet-facing web app that communicates with a backend database. Generally speaking, in such a scenario, you'd have a web server, an app server, and a database server, that all exist solely to support the app. In such a case, they would all go in one resource group. However, if one of those resources, say the database server, for example, exists on a different deployment cycle because it supports other apps, that database server should be deployed in another resource group.
While we're on the subject of which resource groups should house which resources, I should also point out that each resource can only exist in one resource group. You can't add a resource to two different resource groups. That said, you can add and remove resources to and from a resource group at any time. You can even move resources from one resource group to another.
I should also note that a resource group, despite being located in one region, can contain resources that are located in different regions. For example, a resource group in East US can host resources that are deployed in West US. And, of course, resources in one resource group have no problem interacting with resources in another resource group. Essentially, resource groups serve as LOGICAL groupings.
You can also use a resource group to scope access control for administrative actions.
When you create a resource group, you are prompted to provide a location for that resource group. The location you choose is important because it tells Azure where to store metadata about the resources within that resource group. This has potential compliance ramifications, especially if you need to ensure that your data is stored in a particular region.
In the next lesson, we'll get into VM hardening.
Introduction - Configuring Endpoint Security within VMs - Configuring and Monitoring Antimalmare for VMs - Hardening Virtual Machines - Configuring System Updates for Virtual Machines - Starting a Runbook from the Azure Portal - Configuring Baselines - Azure Networking - Configuring Authentication - Container Isolation - AKS Security - Azure Container Registry - Creating a Container Registry - Implementing Vulnerability Management - Conclusion
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.