Manage table-level read access in a Log Analytics workspace

Table-level access settings let you grant specific users or groups read-only permission to data in a table. Users with table-level read access can read data from the specified table in both the workspace and the resource context.

This article describes two ways to manage table-level read access.

Note

We recommend using the first method described here, which is currently in preview. During preview, the recommended method described here does not apply to Microsoft Sentinel Detection Rules, which might have access to more tables than intended. Alternatively, you can use the legacy method of setting table-level read access, which has some limitations related to custom log tables. Before using either method, see Table-level access considerations and limitations.

Set table-level read access (preview)

Granting table-level read access involves assigning a user two roles:

• At the workspace level - a custom role that provides limited permissions to read workspace details and run a query in the workspace, but not to read data from any tables.
• At the table level - a Reader role, scoped to the specific table.

To grant a user or group limited permissions to the Log Analytics workspace:

1. Create a custom role at the workspace level to let users read workspace details and run a query in the workspace, without providing read access to data in any tables:

   1. Navigate to your workspace and select Access control (IAM) > Roles.

   2. Right-click the Reader role and select Clone.

      

      This opens the Create a custom role screen.

   3. On the Basics tab of the screen:

      1. Enter a Custom role name value and, optionally, provide a description.
      2. Set Baseline permissions to Start from scratch.

      

   4. Select the JSON tab > Edit:

      1. In the "actions" section, add these actions:

         "Microsoft.OperationalInsights/workspaces/read",
         "Microsoft.OperationalInsights/workspaces/query/read" 
         

      2. In the "not actions" section, add:

         "Microsoft.OperationalInsights/workspaces/sharedKeys/read"
         

      

   5. Select Save > Review + Create at the bottom of the screen, and then Create on the next page.

2. Assign your custom role to the relevant user:

   1. Select Access control (AIM) > Add > Add role assignment.

      

   2. Select the custom role you created and select Next.

      

      This opens the Members tab of the Add custom role assignment screen.

   3. Click + Select members to open the Select members screen.

      

   4. Search for and select a user and click Select.

   5. Select Review and assign.

The user can now read workspace details and run a query, but can't read data from any tables.

To grant the user read access to a specific table:

1. From the Log Analytics workspaces menu, select Tables.

2. Select the ellipsis ( ... ) to the right of your table and select Access control (IAM).

   

3. On the Access control (IAM) screen, select Add > Add role assignment.

4. Select the Reader role and select Next.

5. Click + Select members to open the Select members screen.

6. Search for and select the user and click Select.

7. Select Review and assign.

The user can now read data from this specific table. Grant the user read access to other tables in the workspace, as needed.

Legacy method of setting table-level read access

The legacy method of table-level also uses Azure custom roles to 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.

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"
],

Limitations of the legacy method related to 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.

Using the legacy method of table-level access, you can't grant access to individual custom log tables at the table level, but you can grant access to all custom log tables. 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"
],

Table-level access considerations and limitations

• In the Log Analytics UI, users with table-level can see the list of all tables in the workspace, but can only retrieve data from tables to which they have access.
• The standard Reader or Contributor roles, which include the */read action, override table-level access control and give users access to all log data.
• A user with table-level access but no workspace-level permissions can access log data from the API but not from the Azure portal.
• Administrators and owners of the subscription 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

• Learn more about managing access to Log Analytics workspaces.