Intro

Monitoring your services is an important aspect of any professional operation. In Azure we have the Monitor platform service, with one of its core services ‘Azure Log Analytics workspaces’. However, when using Log Analytics there are some decisions to make. The two main setups are: centralized workspace vs several decentralized workspaces. Let's take a look at these on a high level...

Decentralized Log Analytics Workspace

This setup is the most common setup we’ve seen so far: every team creates their own Log Analytics Workspaces and does their own work in that environment. Even more so now that the Application Insights also need a workspace (if you haven’t upgraded your Application Insights resources to used workspaces, this is a call-to-action 😉). When you make your first steps in Azure, this is the most intuitive setup.

Centralized Log Analytics Workspace

When we’re talking centralized Log Analytics Workspaces, it mostly aligns with enterprise needs and wants: a centralized service for logging and monitoring. IT shops who run their stuff on-premises, would spin up a SCOM or other tool to perform the log collections and send out alerts.

The immediate question arises: what happens if my (internal/external) customers have access to resources, can they still query the logging information? And do they only see what they are supposed to see? In more general terms: security.

This then, becomes the scope of this post. how can we create and share queries in a secure way?

The setup

According to the Azure Monitor documentation, this setup is the recommended setup. On that note, one of our clients has strong GDPR requirements and due to product limitations when it comes data in transit requirements. But that is a topic for another post. Be sure to check back soon😉.

An important setting of the Log Analytics workspace is the Access control mode. When setting this to Use resource or workspace permissions, all we need to do is arrange the RBAC permissions on the individual resources.

What we’ll be doing is setting up 2 VM’s in 2 resource groups. Each of these RG’s will have a workbook. There will also be a shared dashboard to prove that we can use 1 set of queries for multiple customers and not break privacy constraints.

The IAM settings will be like as follows:

What do we need to validate?

For user 1 and 2 separately:

- Can I see the logging from my own azure resources (VM, app service, ...)

- Can I access the dashboard?

- Do I only see my resource information or do I see all resources?

For the admin:

- Do I still see all resource information?

- Can I easily manage all configuration?

Note: as we perform all configuration tasks as the admin, we can safely say that the admin has full control over all aspects.

The technical setup

Azure Monitor for IaaS services currently has 2 available options that can log performance counters and windows events to a workspace: MMA and AMA. Or the Microsoft Monitoring Agent and the Azure Monitoring Agent. It will take a few years probably, but the AMA will eventually replace the MMA completely. That’s a good thing because the management features on the AMA are more versatile.

I have used both agents in the setup because we all want to know if the functionality remains the same security-wise and there are no issues along the way.

The order in which I performed the steps:

1. Create resource groups
2. Create VM1
3. Create VM2
4. Create Log Analytics Workspace
   • Make sure Access control mode is set to “Use resource or workspace permissions”.
5. Register MMA on VM1
6. Register AMA on VM2
7. Create workbook in VM1-rg
8. Create workbook in VM2-rg
9. Create dashboard on shared-rg
10. Create user 1 & set access rights as listed above.
11. Create user 2 & set access rights as listed above.
12. Open up incognito browser logged in as user 1 and tested the result.
13. Open up incognito browser logged in as user 2 and tested the result.

Proof of configuration

Security settings

User 1 resource groups:

User 2 resource groups:

Azure configuration

The MMA on VM1

And the AMA on VM2

The AMA data collection rule:

And the MMA perf counter configuration:

You can find your usual logging information in the Log Analytics workspace:

There is more to be said about this, check out the gotcha down below.

And finally: the dashboard using the view of the Admin user:

Here you can clearly see we're querying information on 2 VM's and 2 azure app services running.

Verifying the configuration

For user 1

A simple query:

As you can see, the scope is set to the subscription level, not the resource group or resource level.

And the dashboard:

For user 2

A simple query:

As you can see, the scope is set to the subscription level, not the resource group or resource level.

And the dashboard:

Creating queries to be shared and managed

Why?

If you want more control over how your queries and dashboards are shared, you can make a resource group containing a log analytics query pack and a dashboard resource:

What log analytics query pack is, is detailed pretty well in the services release blog post. In summary: it’s a way to organize and share queries, and have RBAC-capabilities on those queries.

Also, your users can search for these queries in the log queries overview in a nice convenient package:

How?

You create your query as if you would any other query, and the click Save. A popup window will appear on the right-hand side, to ask where you want to save this.

Be sure to deselect the “save to the default query pack” and select the query pack in the shared resource group.

Gotcha: performance counters MMA vs AMA

What you’ll inevitably notice, is that the performance counters on the MMA and the AMA are not 100% alike. Small differences like bytes vs megabytes or the MMA including different defaults compared to the AMA. This can result in confusion, like here:

Upon investigation, the MMA configures this by default:

Whereas the AMA configures it like this:

The solution then is to add a custom entry to the data collection rule

After waiting a little bit for the AMA to pick up the changes, we get the expected result.

Conclusions

When configured correctly, the Azure Monitor platform integrates amazingly well with the available RBAC assignments, it filters out resources and fields one does not have access to.

The diagram below is absolutely possible and is, in fact, one of the recommended approaches for when you are dealing with a central IT-style enterprise.

The things you must watch out for:

• Set correct roles for your users
• Be sure to set “Use resource or workspace permissions” as the access control mode for your log analytics workspace
• This works for all Azure resources, PaaS and IaaS alike
• Be sure to set the scope of your queries to the highest possible scope. Or the queries will not be able to run for your end-users.