Azure默认阅读器与内置监视阅读器

问题描述

我正在尝试从安全的角度来缩小监视数据的最佳范围。我的需求略有不同，所以我不想使用“安全读取器”角色（主要是因为安全读取器只能访问安全中心项以及基本资源和资源组查询）。因此，在阅读更多内容之后，我偶然发现了Monitor Reader角色，而只是Reader角色。我经历了JSON中提到的权限。但是我不确定JSON是否涵盖了所有差异。

例如，当我们谈论“监控阅读器”

{
  "assignableScopes": [
    "/"
  ],"description": "Can read all monitoring data.","id": "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/43d0d8ad-25c7-4714-9337-8ba259a9fe05","name": "43d0d8ad-25c7-4714-9337-8ba259a9fe05","permissions": [
    {
      "actions": [
        "*/read","Microsoft.OperationalInsights/workspaces/search/action","Microsoft.Support/*"
      ],"notActions": [],"dataActions": [],"notDataActions": []
    }
  ],"roleName": "Monitoring Reader","roleType": "BuiltInRole","type": "Microsoft.Authorization/roleDefinitions"
}

特权与我可以查询日志的期望基本相同。与“读者”角色相比

{
  "assignableScopes": [
    "/"
  ],"description": "Lets you view everything,but not make any changes.","id": "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/acdd72a7-3385-48ef-bd42-f606fba81ae7","name": "acdd72a7-3385-48ef-bd42-f606fba81ae7","permissions": [
    {
      "actions": [
        "*/read"
      ],"roleName": "Reader","type": "Microsoft.Authorization/roleDefinitions"
}

从逻辑的角度来看，如果两个用户都能够执行*/read，那么读者角色是否自动具有查询日志的资格？如果没有，那有什么不同？在访问可读数据方面，哪个角色更优越？

参考：https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#reader

PS：我确实了解自定义角色，但想更好地了解内置角色。

解决方法

从逻辑的角度来看，如果两个用户都能够执行* / read，那么Reader角色是否不具有自动查询日志的资格？

它们都能够执行*/read，但是Reader无法查询日志。

如果没有，那有什么不同？

区别在于Monitoring Reader可以执行Microsoft.OperationalInsights/workspaces/search/action和Microsoft.Support/*动作。

在访问可读数据方面，哪个角色更优越？

从角色定义的actions范围来看，显然Monitoring Reader在访问可读数据方面具有优势。