Edit

Share via

Manage table-level access in a Log Analytics workspace

There are three ways to manage table-level access in a Log Analytics workspace using role-based access control (RBAC). This article references all the methods, even though only granular RBAC is recommended.

Granular RBAC lets you finely tune access at the table or row level. Users with table-level access can read data and query from specified tables in both the workspace and the resource context. For more information, see Granular RBAC.

Configure granular RBAC for table-level access

Table-level access configuration using granular RBAC is less complex than earlier methods and offers the flexibility to implement row-level conditions. These steps just focus on configuring table-level access though. For more information, see Granular RBAC.

Configuring granular RBAC for table-level access requires these steps:

  1. Create granular RBAC custom role
  2. Build condition for the assigned role (permissive or restrictive)

Create granular RBAC custom role

The control plane "data action" is one of the things that sets granular RBAC apart from earlier methods of configuring table-level access. For more information, see Create granular RBAC custom role.

Here's the JSON for an example custom role:

{    "properties": {
        "roleName": "Log Analytics Standard Table Access",
        "description": "This custom role provides general access to all non-restricted tables.",
        "assignableScopes": [
            "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/contoso-US-la-workspace"
        ],
        "permissions": [
            {
                "actions": [
                    "Microsoft.OperationalInsights/workspaces/read",
                    "Microsoft.OperationalInsights/workspaces/query/read"
                ],
                "notActions": [],
                "dataActions": [
                    "Microsoft.OperationalInsights/workspaces/tables/data/read"
                ],
                "notDataActions": []
            }
        ]
    }
}

Assign the custom role to a user or group. For more information, see Assign granular RBAC roles.

  1. From the Log Analytics workspace, select Access control (IAM).
  2. Select Add role assignment.
  3. Select the Log Analytics Standard Table Access example custom role you created, then select Next.
  4. Select the user or group you want to assign the role to, then select Next. This example assigns the role to the network team security group.
  5. Select Conditions > Add condition > Add action.
  6. Choose the Read workspace data data action > Select.

Build permissive condition

This example builds a permissive condition using the Access to all data, except what isn't allowed strategy. Access is restricted to the SigninLogs and SecurityEvent tables but access is permitted to all other tables. To see an example of a restrictive condition, see Granular RBAC use cases.

  1. In the Build expression section, select Add expression
  2. Select Resource from the Attribute source dropdown.
  3. Select Table Name from the Attribute dropdown.
  4. Select ForAnyOfAllValues:StringNotEquals from the Operator dropdown.
  5. Type SigninLogs and SecurityEvent in the Value fields.

Here's how the permissive table-level access condition looks when completed.

Screenshot of granular RBAC table-level permissive access condition.

With a single role assignment, table-level access is configured separating restricted tables from standard tables. For more information, see granular RBAC considerations and troubleshooting granular RBAC.

Configure table-level access (dual role method)

The best practice is to use the granular RBAC method instead of this method. For reference, this section outlines the steps on how the dual role method is configured.

This method of table-level access control also uses Azure custom roles to grant users or groups access to specific tables in a workspace, but requires assigning two roles for each user or group.

Scope Role Description
Workspace 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
Table A Reader role, scoped to the specific table

Build workspace role

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. Screenshot that shows the Roles tab of the Access control screen with the clone button highlighted for the Reader role. 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. Screenshot that shows the Basics tab of the Create a custom role screen with the Custom role name and Description fields highlighted.
  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 > Create.
  6. Select Access control (AIM) > Add > Add role assignment.
  7. Select the custom role you created and select Next. This opens the Members tab of the Add custom role assignment screen.
  8. + Select members to open the Select members screen.
  9. Search for a user > Select.
  10. Select Review and assign.

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

Assign table access role

  1. From the Log Analytics workspaces menu, select Tables.
  2. Select the ellipsis ( ... ) to the right of your table and select Access control (IAM). Screenshot that shows the Log Analytics workspace table management screen with the table-level access control button highlighted.
  3. On the Access control (IAM) screen, select Add > Add role assignment.
  4. Select the Reader role and select Next.
  5. + Select members to open the Select members screen.
    1. Search for the user > 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.

Configure table-level access (legacy method)

The legacy method of table-level access control is no longer recommended. It doesn't support row-level conditions and is more complex than the granular RBAC method. The best practice is to use the granular RBAC method instead of this method. For reference, this section outlines the steps on how the legacy method was configured.

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

  1. Set the user permissions in the Actions section of the role definition.
  2. Use Microsoft.OperationalInsights/workspaces/query/* to grant access to all tables.
  3. 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"
],

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

Considerations

  • 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 best practice helps you use existing group management tools to configure and verify access.

Related content