In the last 2 years, an entirely new permissions and access model came to Log Analytics. Prior to these permission changes, enterprises would struggle related to adopting Azure Monitor and deploying a Log Analytics workspace. I always meant to blog on this topic, but there was never enough time for me 2 years ago to compose some thoughts on the scenario.
Let's take a few steps back and make sure everyone is on the same page. Azure Monitor is Azure's comprehensive monitoring solution for collecting, analyzing, and acting on telemetry collected from Azure, on-premises, and other clouds. By using this service, customers have a single pane of glass for monitoring in a cloud based (+ hybrid) world. Azure Monitor is comprised of Azure Monitor Metrics and Azure Monitor Logs. Both Azure Monitor Metrics and Azure Monitor Logs are features of Azure Monitor, so think of them as sitting underneath the Azure Monitor umbrella (and if you did picture an umbrella, you're my favorite).
For purposes of the rest of this blog, I'll continue to cover Azure Monitor Logs and Log Analytics workspaces (I'll save Azure Monitor Metrics for a future blog). Azure Monitor Logs organizes log and performance data generated by virtual machine agents or extensions in a Log Analytics workspace. Think of a Log Analytics workspace as an Azure resource where data is collected, aggregated, and stored for purposes of analyzing an environment. I tend to think of a Log Analytics workspace as a database where your monitoring data is stored. If anything, the reason I decided upon a database within my own head is data within the workspace is organized into tables (sounds kinda like a database, right?). Each table then stores different kinds of data + unique properties based upon whatever generates the data. A lot of data sources will write to their own tables within a Log Analytics workspace. ADDITIONALLY (this is cool), you can use Log Analytics to retrieve and view Azure Monitor Metrics data. To me, a Log Analytics workspace is quite an awesome tool (p.s. Azure Sentinel data is also stored in a Log Analytics workspace and Azure Security Center can work with a Log Analytics workspace, so it's a great multi-tool).
To give you a visual, I took this picture from the design logs deployment article on Microsoft Docs:
The visual showcases all the different types of tables that can be stored in a Log Analytics workspace. Hopefully that visual shows you it's just about every type of monitoring data that can be collected. It's tremendous! Also, Log Analytics workspaces are logically separate based upon customer. The workspaces are hosted on physical clusters that are managed by Azure upon creation.
Going back to the best practices recommendation, Microsoft advises to use as few Log Analytics workspaces as possible. Prior to March 2019, if enterprises built out environments using Azure native monitoring, the only permissions model would provide log data information to everyone that had access to the workspace. Seeing as cloud is making centralized IT sort of die out, there needed to be a better way for different business units or DevOps teams to see the logs they originate (and only the logs they originate). I can't tell you how many of my customers struggled to adopt Azure native monitoring tools 3-4 years ago because it didn't adhere to best practices (as few Log Analytics workspaces as possible) and folks would see all logging vs. the logging they needed to see.
There's a concept called access mode now. This refers to the way users access a Log Analytics workspace. A scope is defined based upon the data they can access. Customers have two context options for accessing data:
1) Workspace-context - Users can see all logs in the workspace where permissions are assigned. Queries are scoped to all data in all tables within the workspace. If you still have central IT in charge of provisioning and maintaining environments, this is a viable option for monitoring your Azure resources.
2) Resource-context - Users can only see logs for a specific resource, resource group, or subscription vs. all logs collected in a workspace. If you are leaning more on business units to maintain and administer environments in Azure, this is a viable option for monitoring each group's environments in Azure.
Additionally, there's a concept of access control modes. This is a specific setting on each workspace that defines permissions for the workspace. There are two different access control modes:
1) Require workspace permissions - Using this access control mode doesn't allow for granular Azure RBAC. If a user accesses a workspace, they need permissions granted to the workspace or to specific tables. Let's say a user accesses the workspace configured in the workspace-context mode. Accessing in this mode means the user has access to all data in any table they've been granted access to. If a user accesses the workspace configured in resource-context mode, they have access to only data for that resource in any table they've been granted access to. Note, this is the default setting for all workspaces created before March 2019 (FYI).
2) Use resource or workspace permissions - Configuring Log Analytics workspaces in this mode allows for granular Azure RBAC. Users can be granted access to the data they're supposed to see vs. all data in a specific workspace. The permissions model is scoped at the Azure resource, resource group, or subscription level. Then the user would also need a read-only permission assigned to see the log data for environments they're maintaining. Note, this is the default setting for all workspaces created after March 2019 (FYI).
The growing deployment model is to use a resource-context Log Analytics workspace and ensure the access mode isn't "Require workspace permissions." Having "use resource or workspace permissions" as the default deployment now helps significantly for newer Log Analytics workspace deployments. Using use resource or workspace permissions allows customers the most flexibility related to log data and how individual teams or business units monitor their Azure environment. I still feel like knowledge of these access models and access modes are a bit unknown, so my hope is to shed some light and help you understand how to better design your environment from a logging and monitoring perspective.
Over the next few blog posts, I'll showcase how you can switch your context of existing Log Analytics workspaces and how to consolidate resources to report into 1 Log Analytics workspace. Stay tuned!