菜单
Grafana Cloud

创建数据源 LBAC 规则

数据源 LBAC 适用于使用基本身份验证创建的、支持 LBAC 的数据源。目前,托管/已供应的数据源无法配置 LBAC 规则。

开始之前

  • 确保您已设置权限在 Grafana Cloud 中创建 Loki 租户。
  • 确保您拥有 Grafana 的数据源管理员权限。
  • 确保您已在 Grafana 中设置团队。

为团队创建数据源 LBAC 规则

  1. 导航到您的数据源
  2. 导航到权限选项卡
    • 在此,您将找到数据源 LBAC 规则部分。
  3. 添加数据源 LBAC 规则
    • 在数据源 LBAC 规则部分为团队添加新规则。
  4. 为规则定义标签选择器
    • 为规则添加标签选择器。有关您可以指定的日志选择类型,请参阅文档。

LBAC 规则

LBAC 规则是一种 logql 查询,根据标签过滤日志或指标。每条规则都独立作为一个过滤器运行,与团队内的其他规则相互独立。

例如

  • 对于日志:`{namespace="dev", cluster="us-west-0"}` 过滤同时匹配 `namespace="dev"` 和 `cluster="us-west-0"` 的日志行。
  • 对于指标:`{job="api-server", region="europe"}` 过滤匹配 `job="api-server"` 和 `region="europe"` 的指标数据点。

创建包含多个命名空间的一条规则 `{namespace="dev", cluster="us-west-0"}` 将被视为 `namespace="dev"` **与** `cluster="us-west-0"`。为团队创建的两条规则 `{namespace="dev"}`、`{cluster="us-west-0"}` 将被视为 `namespace="dev"` **或** `cluster="us-west-0"`。

最佳实践

我们建议您仅为应使用该数据源的团队添加查询权限,并且仅管理员拥有管理员权限。

对于首次设置,我们建议为每个团队设置尽可能少的规则,并使其具有累加性,以保持简单。

为了验证规则,我们建议在探索视图中测试规则。这将允许您查看该规则将返回的指标或日志。

任务

任务 1:为每个团队设置一条规则

创建 LBAC 策略的一种常见用例是授予对带有特定标签的日志或指标的访问权限。例如,您可以创建一个包含所有带有 `namespace` 标签的日志行或指标的标签策略。

我们有两个团队,团队 A 和团队 B,具有 Query 权限。数据源访问设置为只有 Admin 角色具有 Admin 权限。

  • 团队 A 有一条规则 `namespace="dev"`。

  • 团队 B 有一条规则 `namespace="prod"`。

属于团队 A 的用户将有权访问匹配 `namespace="dev"` 的日志或指标。同时属于团队 A 和团队 B 的用户将有权访问匹配 `namespace="dev"` **或** `namespace="prod"` 的数据。

任务 2:设置一条规则为团队排除某个标签

创建 LBAC 策略的一种常见用例是排除带有特定标签的日志或指标。例如,您可以在创建访问策略时,通过添加带有 `secret!="true"` 的选择器来创建一个排除所有带有 `secret=true` 标签的标签策略。

我们有一个团队,团队 A,具有 Query 权限。数据源访问设置为只有 Admin 角色具有 Admin 权限。

  • 团队 A 有一条规则 `secret!="true"`。

属于团队 A 的用户将**无权**访问匹配 `secret!="true"` 的日志或指标。

任务 3:为团队设置多条规则

我们有两个团队,团队 A 和团队 B,具有 Query 权限。数据源访问设置为只有 Admin 角色具有 Admin 权限。

  • 团队 A 配置了规则 `cluster="us-west-0", namespace=~"dev|prod"`。

  • 团队 B 配置了规则 `cluster="us-west-0", namespace="staging"`。

仅属于团队 A 的用户将有权访问匹配 `cluster="us-west-0"` **并且**(`namespace="dev"` **或** `namespace="prod"`) 的日志。

仅属于团队 B 的用户将有权访问匹配 `cluster="us-west-0"` **并且** `namespace="staging"` 的日志。

属于团队 A 的用户有权访问 us-west-0 集群中命名空间为 `dev` 和 `prod` 的日志。属于团队 B 的用户有权访问 us-west-0 集群中的所有内容,除了命名空间 `prod`。因此,基本上,同时是团队 A 和团队 B 成员的用户有权访问 us-west-0 集群中的所有内容。

不属于任何具有 Editor/Viewer 角色的团队的用户将无权查询任何日志。

重要

属于某个团队的 `Admin` 用户将只能访问该团队的日志

不属于任何团队但具有 `Admin` 角色的用户将有权访问所有日志

任务 4:规则重叠

我们有两个团队,团队 A 和团队 B。

  • 团队 A 有一条规则 `namespace="dev"`。

  • 团队 B 有一条规则 `namespace!="dev"`。

属于团队 A 的用户将有权访问匹配 `namespace="dev"` 的日志。

属于团队 B 的用户将有权访问匹配 `namespace!="dev"` 的日志。

注意:同时属于团队 A 和团队 B 的用户将有权访问匹配 `namespace="dev"` **或** `namespace!="dev"` 的所有日志。

任务 5:为团队设置单条规则

我们有两个团队,团队 A 和团队 B。数据源访问设置为 Editor 和 Viewer 角色具有 Query 权限。

  • 团队 A 配置了规则 `namespace="dev"`。

  • 团队 B 没有配置规则。

属于团队 A 的用户将有权访问匹配 `namespace="dev"` 的日志。

同时属于团队 A 和团队 B 的用户将有权访问匹配 `namespace="dev"` 的日志。

不属于团队 A 但属于团队 B 的用户,如果是 Editor 或 Viewer,将有权访问所有日志(由于该用户具有查询权限)。

任务 6:用户 A 是 Admin 并属于团队 B

我们有团队 B,用户 A 属于团队 B 并具有 Admin 基本角色。

  • 团队 B 未分配角色

  • 团队 B 具有数据源的 Query 权限

  • 团队 B 有一条规则 `{ project_id="project-dev" }`

用户 A 只能访问匹配 `{ project_id="project-dev" }` 的数据源日志或指标。