Click here to Skip to main content
15,351,508 members
Articles / DevOps
Posted 24 Jan 2022


4 bookmarked

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

Rate me:
Please Sign up or sign in to vote.
5.00/5 (3 votes)
24 Jan 2022CPOL9 min read
In this article we see how to set up security, Sentinel, and runbooks.
Here we show how to set up Azure Security Center on both servers we added to Arc in the previous article, show how to set up Azure Sentinel on both machines, and show how to perform additional configuration and customization on both server using a Python 3 runbook.

This article is a sponsored article. Articles such as these are intended to provide you with information on products and services that we consider useful and of value to developers

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.

Image 1

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.

Image 2

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

Image 3

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.

Image 4

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

Image 5

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.


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.

Image 6

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.

Image 7

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.

Image 8

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:

Image 9

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.

Image 10

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:

Image 11

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.

Image 12

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.

Image 13

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.

Image 14

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:

Image 15

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.

Image 16

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.

Image 17

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

Image 18

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

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.

Image 19

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.

This article is part of the series 'Azure Arc Enabled Servers View All


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Florian Rappl
Chief Technology Officer
Germany Germany
Florian lives in Munich, Germany. He started his programming career with Perl. After programming C/C++ for some years he discovered his favorite programming language C#. He did work at Siemens as a programmer until he decided to study Physics.

During his studies he worked as an IT consultant for various companies. After graduating with a PhD in theoretical particle Physics he is working as a senior technical consultant in the field of home automation and IoT.

Florian has been giving lectures in C#, HTML5 with CSS3 and JavaScript, software design, and other topics. He is regularly giving talks at user groups, conferences, and companies. He is actively contributing to open-source projects. Florian is the maintainer of AngleSharp, a completely managed browser engine.

Comments and Discussions

GeneralMy vote of 5 Pin
DrABELL22-May-22 2:36
MemberDrABELL22-May-22 2:36 
GeneralMy vote of 5 Pin
Ștefan-Mihai MOGA24-Jan-22 19:09
professionalȘtefan-Mihai MOGA24-Jan-22 19:09 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.