Now we can set up an Initiative to the Resource Group, In this case we will set up the initiative called “Enable Azure Monitor” and the scope will be the Resource Group (you could also apply it to the entire subscription).Īs part of the initiative, we need to provide the Log Analytics workspace we want to use to configure the agent to connect to. As a result, you will be able to see this GCP VM on Azure as an Azure Arc connected VM that is now mapped to a Resource Group, Subscription and Region. Since we can install extensions on Azure Arc enabled VMs, we can use deployIfNotExist policies to automatically remediate non-compliant resources and install the MMA as an extension.įirst, I created a Linux Virtual machine in Google Cloud Platform and installed the Azure Arc agent. We will set up an initiative at resource group level to make sure that all Azure Arc enabled servers are reporting to Azure Sentinel, including on-prem and other cloud servers. This article, shows the steps needed to set up a policy that will act as built-in control to make sure all your servers are reporting to you Azure Sentinel Log Analytics Workspace. A very common way to make sure all of your VMs are reporting events to Sentinel would be to set up an Azure Policy at subscription or Resource Group level so, why not do the same for non-Azure Linux and Windows systems? Now that external resources are connected to Azure, you can start managing them in a similar way you’d do in Azure. Other automation tools: Ansible, Puppet, Chef, etc.System Center Virtual Machine Manager (SCVMM).System Center Configuration Manager (SCCM).You could deploy this agent manually or automate the installation with tools like: Deploy extensions at scale including Microsoft monitoring Agent, Desired State Configuration and Custom Script extension.Each Azure Arc connected machine will get a resource ID in ARM, so you will be able to scope your Log Analytics queries.Organize them into Resource Groups and Subscriptions to follow your cloud native practices.Have a full inventory of your resources.Having this agent and using Azure as the management control plane will also come with a set of new benefits: To apply policies to non-Azure VMs you must first deploy the Azure Arc agent, so it is registered into ARM. On this article we will focus on how you can not only automate the MMA installation using extensions but also leveraging Azure Policies to warrantee all servers are reporting events to Azure Sentinel. However, it was only available for Azure VMs for non-Azure deployments, we had to do a manual installation, what if we could have a similar experience for those servers as well?Īzure Arc for servers allows us to extend Azure Policies and extensions outside the boundaries of Azure, this makes non-Azure VMs first class citizens in Azure management plane. There is a very convenient and fast approach for making sure all of your Azure VMs are onboarded into Azure Sentinel, using an Azure Policy that can audit settings inside the machine and then using the VM extensions installation as a remediation task if the agent is not present. VM extension: the Log Analytics agent virtual machine installs the Log Analytics agent on Azure virtual machines, and enrolls virtual machines into an existing Log Analytics workspace.Scripting or Automation: either using PowerShell, Bash or other automation tools such as Ansible, Puppet, Chef, etc.Azure Automation Desired State Configuration (DSC): you can include the MMA agent as part of your desired state configuration.Manual installation: following a wizard or using an existing software distribution tool.The agent may be installed on Windows or Linux VMs by using one of the following methods: The MMA supports both Windows and Linux operating systems independently of where they run: on-premise, Azure or other clouds. To collect events in Azure Sentinel from VMs and servers, we use the Microsoft Monitoring Agent.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |