Azure Arc Enabled Servers Part 3: Setting up Security, Sentinel, and Runbooks

In the previous two articles of this three-part series, we’ve learned more about Azure Arc and its capabilities and discussed how to onboard new servers to Azure Arc. Once we’ve added the servers to Azure Arc, we can leverage the benefits of integrating other Azure and non-Azure resources, such as security, monitoring, and management solutions.

Securing, monitoring, and managing virtual machines (VMs) and other machines is vital for DevOps. In this final article of our Azure Arc Enabled Servers series, we’ll demonstrate how Azure Arc empowers DevOps by setting up Microsoft Defender for Cloud (previously called Azure Security Center) and Microsoft Sentinel on the machines we added to Azure Arc in the previous article. Finally, with the help of runbooks, we’ll be able to roll out additional configurations and customizations to our servers to give you a taste of what Azure Arc can do.

You just need to have a little bit of Python knowledge to follow this tutorial. We’ll show you how to do the rest.

Integrating with Microsoft Defender for Cloud

Microsoft Defender for Cloud offers a complete security solution. We get plenty of information, assessments, quick fixes, and mitigations to help keep our servers safe.

Usually, Microsoft Defender for Cloud appears with a direct link in the Azure portal. If not, search "Defender for Cloud." Then, click the link to open the blade.

We need to add our servers to the inventory to enable integrating them. So, click on the Inventory link. Then, click Add non-Azure servers. The screenshot below shows the inventory page.

If you have not yet used Microsoft Defender for Cloud, you’ll need to create a workspace. The workspace is vital. It will collect all the events and other information that Microsoft Defender for Cloud needs to protect your servers.

The onboarding screen looks like the screenshot below. Importantly, to use Defender for Cloud’s functions, we must install another agent on the server: the Log Analytics Agent, similar to the Connected Machine agent. We'll see later that we can even install the Log Analytics Agent with the help of the Connected Machine agent.

Click Create new workspace and fill out the form, as shown below.

If you run into issues using that form and it does not create a workspace, you can also use the Azure CLI. Use this command to create a new Log Analytics workspace:

az monitor log-analytics workspace create --resource-group arc-sample --workspace-name arc-log-analytics

Now the workspace should be visible in your Azure portal. You can select it to add a new non-Azure server.

The workspace page contains a quick guide to onboarding Windows and Linux-based servers.

Installing Microsoft Defender for Cloud on an Ubuntu VM

We install the Log Analytics agent directly in the console for the Ubuntu VM using the command below. The command uses a script hosted directly on Microsoft’s GitHub repository for the agent running on Linux.

wget https://raw.githubusercontent.com/Microsoft/OMS-Agent-for-Linux/master/installer/scripts/onboard_agent.sh && sh onboard_agent.sh -w <WORKSPACE-ID> -s <WORKSPACE-PRIMARY-KEY>

After you download the script, it sets up the agent with the given workspace ID and primary key. After, you can restart the service for a given workspace ID:

sudo /opt/microsoft/omsagent/bin/service_control restart [<WORKSPACE-ID>]

When all that finishes, the Microsoft Defender for Cloud blade’s inventory page should contain your non-Azure VM.

We might find some recommendations already in the system’s details. In our case, as the screenshot below shows, we received an alert that we should install an endpoint protection solution on our machine. Other than that, we received some generic information.

Our next step is to inspect particular recommendations, like the one mentioned about endpoint protection. These are linked to each item’s description. Here, Microsoft Defender for Cloud describes the issue in greater detail and provides remediation steps. We can apply a quick fix, too. Note that even after we deploy a potential fix, the issue might stay active.

We need to keep in mind the freshness interval, which is eight hours for the given example recommendation. Usually, that means that Microsoft Defender for Cloud will recheck the issue after that time.

Also, although a fix might be available, it may not work under the given circumstances. In any case, if we think the alert points to an urgent threat, we should take care of it ourselves to ensure it’s fixed correctly.

Installing Microsoft Defender for Cloud on a Windows VM

We could onboard our Windows VM the same as our Ubuntu VM. We could just install and start the agent. However, since we already installed the Connected Machine agent in article two, we can put it to work instead.

First, open the servers page in the Azure portal’s Azure Arc blade. Then, go to the VM where you will install the Log Analytics agent. In the VM overview, select Extensions (you’ll find it below Settings) in the menu on the left. You can now + Add the Log Analytics Agent – Azure Arc extension. Your Extensions page should look like this:

With the agent in place, Microsoft Defender for Cloud should collect data. So, you’ll find the server in Microsoft Defender for Cloud’s inventory.

While the Microsoft Defender for Cloud integration is a good step in the right direction, it’s not the only thing we can — or should — do to improve our systems’ security. Our next important step is to integrate the Microsoft Sentinel solution.

Integrating with Microsoft Sentinel

Microsoft Sentinel (previously called Azure Sentinel) is a scalable, cloud-native, security information event management and security orchestration automated response solution. It understands events from your servers and can derive threats and respond to incidents in real-time, even when we bombard the system with events.

We need a Log Analytics workspace to connect Azure Arc-enabled servers to Microsoft Sentinel. Luckily, we already created that workspace in the previous section and can reuse it. You can find a complete starter guide in Microsoft's documentation.

When we look at Microsoft Sentinel’s information in the Azure portal, we should currently see an empty table like this:

Creating a Sentinel is as straightforward as selecting a workspace. Since we already made a workspace, we can just choose that one to set up Microsoft Defender for Cloud. If we would like to create a new one, we’ll also need to dispatch events to this new Log Analytics workspace. For our purposes, dispatching to a single workspace is sufficient.

If we did everything right, events should appear on the Microsoft Sentinel overview page. Even better, the recommendations and incidents in each server's security tab should expand beyond what we’ve seen before.

You might still be unsure if Microsoft Sentinel "sees" your servers. In this case, just check the event log. One way to do that is by clicking Update in the events chart shown above. In there, you should find events from all your servers. In our case, we just have the two servers we onboarded earlier.

That’s how you set up Azure Sentinel with a single selection in the Azure portal. You can't get much more straightforward than that!

For the last part of this article, let’s explore how we can further leverage Azure for our non-Azure servers using Python runbooks.

Using Python 3 Runbooks

At the time of writing, Python 3 runbooks are still in preview. Nevertheless, due to the deprecation of Python 2, it makes sense to use Python 3 rather than Python 2 runbooks. In any case, Python 3 runbooks enable us to put additional configuration and customizations onto our servers directly from the Azure Portal or Azure CLI, which is excellent for infrastructure maintenance scalability.

The runbook itself will be running in a managed Azure resource, where we can access and modify all our resources.

Creating a Runbook

To create a new runbook, we first need to create an automation account. We do this on the Automation Accounts blade. You should see a page like this:

Already, the Runbooks page contains two tutorials. They’re published, but you can view or edit them. We don’t want to do that, as we aren’t currently interested in (graphical) PowerShell runbooks. Instead, we will create a new Python runbook.

To create a new Python runbook, click the Runbooks menu item, then + Create a runbook. Choose runtime Python and version 3.8.0 (preview). Then, specify a name and description.

We’ll need to set up a Run As account to do anything useful with a runbook. Otherwise, the Python script cannot access our resources. So, click Run As accounts (below Account Settings in the created runbook). Adding an Azure Run As account effectively makes a new service principal user in Azure Active Directory.

Creating a Hybrid Worker

Previously, we mentioned that runbooks run in Azure, which is valid to some extent. If for some reason you’d like to run on a dedicated machine, such as the Ubuntu or Windows VM that we set up for this article, then you can create a hybrid worker.

First, open the Hybrid worker groups menu item and add a new hybrid worker group. You can create a new hybrid worker in there by selecting machines that will run the runbooks.

We see the Arc-enabled server as part of the hybrid workers when we finish.

We can now select where to run the worker with such a hybrid worker group. As an example, consider the following worker code, which just prints the current machine’s hostname:

#!/usr/bin/env python3
 
import socket
print(socket.gethostname())

The screenshot below shows the result of invoking this runbook on the worker group. We get back the hostname of the Ubuntu VM that we selected as a worker.

When we run the same job on Azure, it yields "CLIENT" as the output.

With the help of Runbooks, we can create scripts that help us to automate our whole infrastructure. Need to gather some information on all servers quickly? Use a Runbook. Need to deploy some resources to some servers? A Runbook can help here, too. It simplifies the automation of additional configuration and customization.

Next Steps

Securing our non-Azure servers is straightforward with Azure Arc. We can employ Microsoft Defender for Cloud and Microsoft Sentinel’s advanced capabilities by bringing the Log Analytics agent to our servers. These two services offer event reporting, alerts, and recommendations to help keep all our servers secure, no matter their location in the cloud or on-premises.

Python 3 runbooks conveniently fulfill the need for automation, enabling us to deploy solutions to multiple servers quickly. These servers are now all secure, well-monitored, and scalable, with the potential for helpful automation via runbooks.

Azure Arc enables you and your organization to unite your multicloud and hybrid cloud servers behind a single pane of glass. Now that you know how straightforward it is to set up Azure Arc-enabled services, you can implement security, event reporting, and runbook-enabled automation on your architecture. Sign up to try Azure Arc for free to scale your services into and across the cloud seamlessly.

To learn more about Azure Arc enabled servers, check out Azure Arc-enabled servers Overview.