Merge pull request #247468 from guywi-ms/table-level-rbac-update

Update manage-access.md

Author: v-dirichards

articles/azure-monitor/logs/manage-access.md

@@ -12,13 +12,13 @@ ms.custom: devx-track-azurepowershell
 
 # Manage access to Log Analytics workspaces
 
- The data in a Log Analytics workspace that you can access is determined by a combination of the following factors:
+The factors that determine which data you can access in a Log Analytics workspace are:
 
 - The settings on the workspace itself.
-- The access to resources sending data to the workspace.
+- Your access permissions to resources that send 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.
+This article describes how to manage access to data in a Log Analytics workspace.
 
 ## Overview
 
@@ -234,7 +234,7 @@ The Log Analytics Contributor role includes the following Azure actions:
 
 ### Resource permissions
 
-When users query logs from a workspace by using [resource-context access](#access-mode), they'll have the following permissions on the resource:
+To read data from or send data to a workspace in the [resource context](#access-mode), you need these permissions on the resource:
 
 | Permission | Description |
 | ---------- | ----------- |
@@ -298,33 +298,19 @@ In addition to using the built-in roles for a Log Analytics workspace, you can c
 
 ## Set table-level read access
 
-Table-level access allows you to let specific people read data only from a specific set of tables. It applies both for workspace-context and resource-context. There are two methods to define table-level permissions:
-* By assigning permissions to the table sub-resource under the workspace resource - this is the recommended method that is described in this section. This method is currently in **preview**.
-* By assigning special actions that contain table name to the workspace resource - this is the legacy method that is described in the next section. It has some limitations around custom log tables.
-
-Table-level RBAC is applied during query execution. It does not apply to metadata retrieval calls. For that reason, tables will appear in the list of tables even if they are not available to the user.
+Table-level access settings let you grant specific users or groups read-only permission to data from certain tables. Users with table-level read access can read data from the specified tables in both the workspace and the resource context.  
 
 > [!NOTE]
-> The recommended table-level access method described here does not apply during preview to Microsoft Sentinel Detection Rules. These rules might have access to more tables than intended.
-
-In order to apply table-level RBAC for a user, two assignments shall be made:
+> We recommend using the method described here, which is currently in **preview**, to define table-level access. Alternatively, you can use the [legacy method of setting table-level read access](#legacy-method-of-setting-table-level-read-access), which has some limitations related to custom log tables. During preview, the recommended method described here does not apply to Microsoft Sentinel Detection Rules, which might have access to more tables than intended. Before using either method, see [Table-level access considerations and limitations](#table-level-access-considerations-and-limitations).
 
-1. Assign the user the ability to read the workspace details and to run a query without granting the ability to run a query on tables. This is done by assigning a special custom role on the workspace that has only the following actions:
-            - `Microsoft.OperationalInsights/workspaces/read`
-            - `Microsoft.OperationalInsights/workspaces/query/read`
-            - `Microsoft.OperationalInsights/workspaces/analytics/query/action`
-            - `Microsoft.OperationalInsights/workspaces/search/action`
-        
-2. Assign the user a read permissions on the specific table sub-resource. Any role that has */read will be sufficient such as **Reader** role or **Log Analytics Reader** role. As table is a sub-resource of workspace, the workspace admins can also perform action on a specific table.
+Granting table-level read access involves assigning a user two roles:
 
-> [!WARNING]
-> If the user has other assignments on the workspace, directly or via inheritence (e.g. user has Reader on the subscription that contains the workspace), the user will be able to access all tables in the workspace.
+- 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 table-level read access to a specific table:
 
-
-To create a [custom role](../../role-based-access-control/custom-roles.md) that lets specific users or groups read data from specific tables in a workspace:
-
-1. Create a custom role that grants users permission to execute queries in the Log Analytics workspace, based on the built-in Azure Monitor Logs **Reader** role:
+1. Create a [custom role](../../role-based-access-control/custom-roles.md) 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**.
 
@@ -334,26 +320,34 @@ To create a [custom role](../../role-based-access-control/custom-roles.md) that
 
        This opens the **Create a custom role** screen.
 
-    1. On the **Basics** tab of the screen, enter a **Custom role name** value and, optionally, provide a description.
+    1. On the **Basics** tab of the screen: 
+        1. Enter a **Custom role name** value and, optionally, provide a description.
+        1. Set **Baseline permissions** to **Start from scratch**. 
 
         :::image type="content" source="media/manage-access/manage-access-create-custom-role.png" alt-text="Screenshot that shows the Basics tab of the Create a custom role screen with the Custom role name and Description fields highlighted." lightbox="media/manage-access/manage-access-create-custom-role.png":::
 
-    1. Select the **JSON** tab > **Edit**::
+    1. Select the **JSON** tab > **Edit**:
 
-        1. In the `"actions"` section, add:
+        1. In the `"actions"` section, add these actions:
 
-            - `Microsoft.OperationalInsights/workspaces/read`
-            - `Microsoft.OperationalInsights/workspaces/query/read`
-            - `Microsoft.OperationalInsights/workspaces/analytics/query/action`
-            - `Microsoft.OperationalInsights/workspaces/search/action`
+            ```json
+            "Microsoft.OperationalInsights/workspaces/read",
+            "Microsoft.OperationalInsights/workspaces/query/read",
+            "Microsoft.OperationalInsights/workspaces/analytics/query/action",
+            "Microsoft.OperationalInsights/workspaces/search/action"    
+            ```
 
-        1. In the `"not actions"` section, add `Microsoft.OperationalInsights/workspaces/sharedKeys/read`.
+        1. In the `"not actions"` section, add: 
+        
+            ```json
+            "Microsoft.OperationalInsights/workspaces/sharedKeys/read"
+            ```
 
         :::image type="content" source="media/manage-access/manage-access-create-custom-role-json.png" alt-text="Screenshot that shows the JSON tab of the Create a custom role screen with the actions section of the JSON file highlighted." lightbox="media/manage-access/manage-access-create-custom-role-json.png":::    
 
     1. Select **Save** > **Review + Create** at the bottom of the screen, and then **Create** on the next page.   
 
-1. Assign your custom role to the relevant users or groups:
+1. Assign your custom role to the relevant user:
     1. Select **Access control (AIM)** > **Add** > **Add role assignment**.
 
        :::image type="content" source="media/manage-access/manage-access-add-role-assignment-button.png" alt-text="Screenshot that shows the Access control screen with the Add role assignment button highlighted." lightbox="media/manage-access/manage-access-add-role-assignment-button.png":::
@@ -369,45 +363,23 @@ To create a [custom role](../../role-based-access-control/custom-roles.md) that
 
         :::image type="content" source="media/manage-access/manage-access-add-role-assignment-select-members.png" alt-text="Screenshot that shows the Select members screen." lightbox="media/manage-access/manage-access-add-role-assignment-select-members.png":::
 
-    1. Search for and select the relevant user or group and click **Select**.
+    1. Search for and select a user and click **Select**.
     1. Select **Review and assign**.
+    
+1. Grant the user read access to a specific table:
 
-1. Grant the users or groups read access to specific tables in a workspace by calling the `https://management.azure.com/batch?api-version=2020-06-01` POST API and sending the following details in the request body:
-
-    ```json
-    {
-        "requests": [
-            {
-                "content": {
-                    "Id": "<GUID_1>",
-                    "Properties": {
-                        "PrincipalId": "<user_object_ID>",
-                        "PrincipalType": "User",
-                        "RoleDefinitionId": "/providers/Microsoft.Authorization/roleDefinitions/acdd72a7-3385-48ef-bd42-f606fba81ae7",
-                        "Scope": "/subscriptions/<subscription_ID>/resourceGroups/<resource_group_name>/providers/Microsoft.OperationalInsights/workspaces/<workspace_name>/Tables/<table_name>",
-                        "Condition": null,
-                        "ConditionVersion": null
-                    }
-                },
-                "httpMethod": "PUT",
-                "name": "<GUID_2>",
-                "requestHeaderDetails": {
-                    "commandName": "Microsoft_Azure_AD."
-                },
-                "url": "/subscriptions/<subscription_ID>/resourceGroups/<resource_group_name>/providers/Microsoft.OperationalInsights/workspaces/<workspace_name>/Tables/<table_name>/providers/Microsoft.Authorization/roleAssignments/<GUID_1>?api-version=2020-04-01-preview"
-            }
-        ]
-    }
-    ```
-
-    Where:
-    - You can generate a GUID for `<GUID 1>` and `<GUID 2>` using any GUID generator.
-    - `<user_object_ID>` is the object ID of the user to which you want to grant table read access.
-    - `<subscription_ID>` is the ID of the subscription related to the workspace.
-    - `<resource_group_name>` is the resource group of the workspace.
-    - `<workspace_name>` is the name of the workspace.
-    - `<table_name>` is the name of the table to which you want to assign the user or group permission to read data from.
+    1. From the **Log Analytics workspaces** menu, select **Tables**.  
+    1. Select the ellipsis ( **...** ) to the right of your table and select **Access control (IAM)**.
+        
+       :::image type="content" source="media/manage-access/table-level-access-control.png" alt-text="Screenshot that shows the Log Analytics workspace table management screen with the table-level access control button highlighted." lightbox="media/manage-access/manage-access-create-custom-role-json.png":::      
+    
+    1. On the **Access control (IAM)** screen, select **Add** > **Add role assignment**. 
+    1. Select the **Reader** role and select **Next**.    
+    1. Click **+ Select members** to open the **Select members** screen.
+    1. Search for and select the user and click **Select**.
+    1. Select **Review and assign**.
 
+    The user can now read data from this specific table.
 ### Legacy method of setting table-level read access
 
 The legacy method of table-level also uses [Azure custom roles](../../role-based-access-control/custom-roles.md) 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](#access-control-mode) regardless of the user's [access mode](#access-mode).
@@ -418,8 +390,6 @@ To define access to a particular table, create a [custom role](../../role-based-
 * 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:
@@ -457,13 +427,10 @@ Grant access to all tables except the _SecurityAlert_ table:
 ],
 ```
 
-#### Custom tables
+#### Limitations of the legacy method related to custom tables
 
 Custom tables store data you collect from data sources such as [text logs](../agents/data-sources-custom-logs.md) and the [HTTP Data Collector API](data-collector-api.md). To identify the table type, [view table information in Log Analytics](./log-analytics-tutorial.md#view-table-information).
 
-> [!NOTE]
-> Tables created by the [Logs ingestion API](../essentials/../logs/logs-ingestion-api-overview.md) don't yet support table-level RBAC.
-
 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:
 
 ```
@@ -474,11 +441,12 @@ Using the legacy method of table-level access, you can't grant access to individ
 ],
 ```
 
-### Considerations regarding table-level access
+### Table-level access considerations and limitations
 
-- 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.
+- 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.