You need to identify which blades in the azure portal must be used to perform the following tasks

Skip to main content

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Manage access to Log Analytics workspaces

• Article
• 12/22/2022
• 15 minutes to read

In this article

The data in a Log Analytics workspace that you can access is determined by a combination of the following factors:

• The settings on the workspace itself.
• The access to resources sending data to the workspace.
• The method used to access the workspace.

This article describes how access is managed and how to perform any required configuration.

Overview

The factors that define the data you can access are described in the following table. Each factor is further described in the sections that follow.

Access mode

The access mode refers to how you access a Log Analytics workspace and defines the data you can access during the current session. The mode is determined according to the scope you select in Log Analytics.

There are two access modes:

• Workspace-context: You can view all logs in the workspace for which you have permission. Queries in this mode are scoped to all data in all tables in the workspace. This access mode is used when logs are accessed with the workspace as the scope, such as when you select Logs on the Azure Monitor menu in the Azure portal.
• Resource-context: When you access the workspace for a particular resource, resource group, or subscription, such as when you select Logs from a resource menu in the Azure portal, you can view logs for only resources in all tables that you have access to. Queries in this mode are scoped to only data associated with that resource. This mode also enables granular Azure RBAC. Workspaces use a resource-context log model where every log record emitted by an Azure resource is automatically associated with this resource.

Records are only available in resource-context queries if they're associated with the relevant resource. To check this association, run a query and verify that the _ResourceId column is populated.

There are known limitations with the following resources:

• Computers outside of Azure: Resource-context is only supported with Azure Arc for servers.
• Application Insights: Supported for resource-context only when using a workspace-based Application Insights resource.
• Azure Service Fabric

Compare access modes

The following table summarizes the access modes:

Access control mode

The access control mode is a setting on each workspace that defines how permissions are determined for the workspace.

• Require workspace permissions. This control mode doesn't allow granular Azure RBAC. To access the workspace, the user must be granted permissions to the workspace or to specific tables.

  If a user accesses the workspace in workspace-context mode, they have access to all data in any table they've been granted access to. If a user accesses the workspace in resource-context mode, they have access to only data for that resource in any table they've been granted access to.

  This setting is the default for all workspaces created before March 2019.

• Use resource or workspace permissions. This control mode allows granular Azure RBAC. Users can be granted access to only data associated with resources they can view by assigning Azure read permission.

  When a user accesses the workspace in workspace-context mode, workspace permissions apply. When a user accesses the workspace in resource-context mode, only resource permissions are verified, and workspace permissions are ignored. Enable Azure RBAC for a user by removing them from workspace permissions and allowing their resource permissions to be recognized.

  This setting is the default for all workspaces created after March 2019.

  Note

  If a user has only resource permissions to the workspace, they can only access the workspace by using resource-context mode assuming the workspace access mode is set to Use resource or workspace permissions.

Configure access control mode for a workspace

• Azure portal
• PowerShell
• Resource Manager

View the current workspace access control mode on the Overview page for the workspace in the Log Analytics workspace menu.

Change this setting on the Properties page of the workspace. If you don't have permissions to configure the workspace, changing the setting is disabled.

Get-AzResource -ResourceType Microsoft.OperationalInsights/workspaces -ExpandProperties | foreach {$_.Name + ": " + $_.Properties.features.enableLogAccessUsingOnlyResourcePermissions}

DefaultWorkspace38917: True
DefaultWorkspace21532: False

$WSName = "my-workspace"
$Workspace = Get-AzResource -Name $WSName -ExpandProperties
if ($Workspace.Properties.features.enableLogAccessUsingOnlyResourcePermissions -eq $null)
    { $Workspace.Properties.features | Add-Member enableLogAccessUsingOnlyResourcePermissions $true -Force }
else
    { $Workspace.Properties.features.enableLogAccessUsingOnlyResourcePermissions = $true }
Set-AzResource -ResourceId $Workspace.ResourceId -Properties $Workspace.Properties -Force

Get-AzResource -ResourceType Microsoft.OperationalInsights/workspaces -ExpandProperties | foreach {
if ($_.Properties.features.enableLogAccessUsingOnlyResourcePermissions -eq $null)
    { $_.Properties.features | Add-Member enableLogAccessUsingOnlyResourcePermissions $true -Force }
else
    { $_.Properties.features.enableLogAccessUsingOnlyResourcePermissions = $true }
Set-AzResource -ResourceId $_.ResourceId -Properties $_.Properties -Force
}

Azure RBAC

Access to a workspace is managed by using Azure RBAC. To grant access to the Log Analytics workspace by using Azure permissions, follow the steps in Assign Azure roles to manage access to your Azure subscription resources.

Workspace permissions

Each workspace can have multiple accounts associated with it. Each account can have access to multiple workspaces. The following table lists the Azure permissions for different workspace actions:

Built-in roles

Assign users to these roles to give them access at different scopes:

• Subscription: Access to all workspaces in the subscription
• Resource group: Access to all workspaces in the resource group
• Resource: Access to only the specified workspace

Create assignments at the resource level (workspace) to assure accurate access control. Use custom roles to create roles with the specific permissions needed.

Note

To add and remove users to a user role, you must have Microsoft.Authorization/*/Delete and Microsoft.Authorization/*/Write permission.

Log Analytics Reader

Members of the Log Analytics Reader role can view all monitoring data and monitoring settings, including the configuration of Azure diagnostics on all Azure resources.

Members of the Log Analytics Reader role can:

• View and search all monitoring data.
• View monitoring settings, including viewing the configuration of Azure diagnostics on all Azure resources.

The Log Analytics Reader role includes the following Azure actions:

Log Analytics Contributor

Members of the Log Analytics Contributor role can:

• Read all monitoring data granted by the Log Analytics Reader role.
• Edit monitoring settings for Azure resources, including:
  • Adding the VM extension to VMs.
  • Configuring Azure diagnostics on all Azure resources.
• Create and configure Automation accounts. Permission must be granted at the resource group or subscription level.
• Add and remove management solutions. Permission must be granted at the resource group or subscription level.
• Read storage account keys.
• Configure the collection of logs from Azure Storage.
• Configure data export rules.
• Run a search job.
• Restore archived logs.

Warning

You can use the permission to add a virtual machine extension to a virtual machine to gain full control over a virtual machine.

The Log Analytics Contributor role includes the following Azure actions:

Resource permissions

When users query logs from a workspace by using resource-context access, they'll have the following permissions on the resource:

The /read permission is usually granted from a role that includes */read or * permissions, such as the built-in Reader and Contributor roles. Custom roles that include specific actions or dedicated built-in roles might not include this permission.

Custom role examples

In addition to using the built-in roles for a Log Analytics workspace, you can create custom roles to assign more granular permissions. Here are some common examples.

Example 1: Grant a user access to log data from their resources.

• Configure the workspace access control mode to use workspace or resource permissions.
• Grant users */read or Microsoft.Insights/logs/*/read permissions to their resources. If they're already assigned the Log Analytics Reader role on the workspace, it's sufficient.

Example 2: Grant a user access to log data from their resources and configure their resources to send logs to the workspace.

• Configure the workspace access control mode to use workspace or resource permissions.
• Grant users the following permissions on the workspace: Microsoft.OperationalInsights/workspaces/read and Microsoft.OperationalInsights/workspaces/sharedKeys/action. With these permissions, users can't perform any workspace-level queries. They can only enumerate the workspace and use it as a destination for diagnostic settings or agent configuration.
• Grant users the following permissions to their resources: Microsoft.Insights/logs/*/read and Microsoft.Insights/diagnosticSettings/write. If they're already assigned the Log Analytics Contributor role, assigned the Reader role, or granted */read permissions on this resource, it's sufficient.

Example 3: Grant a user access to log data from their resources without being able to read security events and send data.

• Configure the workspace access control mode to use workspace or resource permissions.
• Grant users the following permissions to their resources: Microsoft.Insights/logs/*/read.
• Add the following NonAction to block users from reading the SecurityEvent type: Microsoft.Insights/logs/SecurityEvent/read. The NonAction shall be in the same custom role as the action that provides the read permission (Microsoft.Insights/logs/*/read). If the user inherits the read action from another role that's assigned to this resource or to the subscription or resource group, they could read all log types. This scenario is also true if they inherit */read that exists, for example, with the Reader or Contributor role.

Example 4: Grant a user access to log data from their resources and read all Azure AD sign-in and read Update Management solution log data from the workspace.

• Configure the workspace access control mode to use workspace or resource permissions.
• Grant users the following permissions on the workspace:
  • Microsoft.OperationalInsights/workspaces/read: Required so the user can enumerate the workspace and open the workspace pane in the Azure portal
  • Microsoft.OperationalInsights/workspaces/query/read: Required for every user that can execute queries
  • Microsoft.OperationalInsights/workspaces/query/SigninLogs/read: To be able to read Azure AD sign-in logs
  • Microsoft.OperationalInsights/workspaces/query/Update/read: To be able to read Update Management solution logs
  • Microsoft.OperationalInsights/workspaces/query/UpdateRunProgress/read: To be able to read Update Management solution logs
  • Microsoft.OperationalInsights/workspaces/query/UpdateSummary/read: To be able to read Update Management logs
  • Microsoft.OperationalInsights/workspaces/query/Heartbeat/read: Required to be able to use Update Management solutions
  • Microsoft.OperationalInsights/workspaces/query/ComputerGroup/read: Required to be able to use Update Management solutions
• Grant users the following permissions to their resources: */read, assigned to the Reader role, or Microsoft.Insights/logs/*/read

Set table-level read access

Azure custom roles let you grant specific users or groups access to specific tables in the workspace. Azure custom roles apply to workspaces with either workspace-context or resource-context access control modes regardless of the user's access mode.

To define access to a particular table, create a custom role:

• Set the user permissions in the Actions section of the role definition.
• Use Microsoft.OperationalInsights/workspaces/query/* to grant access to all tables.
• To exclude access to specific tables when you use a wildcard in Actions, list the tables excluded tables in the NotActions section of the role definition.

Examples

Here are examples of custom role actions to grant and deny access to specific tables.

Grant access to the Heartbeat and AzureActivity tables:

"Actions":  [
    "Microsoft.OperationalInsights/workspaces/read",
    "Microsoft.OperationalInsights/workspaces/query/read",
    "Microsoft.OperationalInsights/workspaces/query/Heartbeat/read",
    "Microsoft.OperationalInsights/workspaces/query/AzureActivity/read"
  ],

Grant access to only the SecurityBaseline table:

"Actions":  [
    "Microsoft.OperationalInsights/workspaces/read",
    "Microsoft.OperationalInsights/workspaces/query/read",
    "Microsoft.OperationalInsights/workspaces/query/SecurityBaseline/read"
],

Grant access to all tables except the SecurityAlert table:

"Actions":  [
    "Microsoft.OperationalInsights/workspaces/read",
    "Microsoft.OperationalInsights/workspaces/query/read",
    "Microsoft.OperationalInsights/workspaces/query/*/read"
],
"notActions":  [
    "Microsoft.OperationalInsights/workspaces/query/SecurityAlert/read"
],

Custom tables

Custom tables store data you collect from data sources such as text logs and the HTTP Data Collector API. To identify the table type, view table information in Log Analytics.

You can't grant access to individual custom log tables, but you can grant access to all custom logs. To create a role with access to all custom log tables, create a custom role by using the following actions:

"Actions":  [
    "Microsoft.OperationalInsights/workspaces/read",
    "Microsoft.OperationalInsights/workspaces/query/read",
    "Microsoft.OperationalInsights/workspaces/query/Tables.Custom/read"
],

An alternative approach to managing access to custom logs is to assign them to an Azure resource and manage access by using resource-context access control. Include the resource ID by specifying it in the x-ms-AzureResourceId header when data is ingested to Log Analytics via the HTTP Data Collector API. The resource ID must be valid and have access rules applied to it. After the logs are ingested, they're accessible to users with read access to the resource.

Some custom logs come from sources that aren't directly associated to a specific resource. In this case, create a resource group to manage access to these logs. The resource group doesn't incur any cost, but it gives you a valid resource ID to control access to the custom logs.

For example, if a specific firewall is sending custom logs, create a resource group called MyFireWallLogs. Make sure that the API requests contain the resource ID of MyFireWallLogs. The firewall log records are then accessible only to users who were granted access to MyFireWallLogs or those users with full workspace access.

Considerations

• If a user is granted global read permission with the standard Reader or Contributor roles that include the */read action, it will override the per-table access control and give them access to all log data.
• If a user is granted per-table access but no other permissions, they can access log data from the API but not from the Azure portal. To provide access from the Azure portal, use Log Analytics Reader as its base role.
• Administrators and owners of the subscription will have access to all data types regardless of any other permission settings.
• Workspace owners are treated like any other user for per-table access control.
• Assign roles to security groups instead of individual users to reduce the number of assignments. This practice will also help you use existing group management tools to configure and verify access.

Next steps

• See Log Analytics agent overview to gather data from computers in your datacenter or other cloud environment.
• See Collect data about Azure virtual machines to configure data collection from Azure VMs.

Additional resources

Additional resources

In this article

Which blade should you use from the Azure portal?

Which blade should you identify to monitor the health of Azure services?

Which blade is used to view security recommendations?

Which task can you perform by using Azure Advisor?