这些最佳实践反映了由经验丰富的 Looker 组成的跨职能团队分享的建议。这些数据洞见是我们在与 Looker 客户合作多年的过程中积累的，涵盖从实施到长期成功的各个方面。这些做法适用于大多数用户和情况，但在实施时，请务必根据自己的判断。
本页面为 Looker 实例的管理员提供了设置内容访问权限控制的引导式示例。我们将逐步介绍实现流程，从新项目开始，然后介绍模型、模型集、权限集、组、角色和用户属性。
首先，我们通过一个类比来了解 Looker 在这种情况下的主要功能：
项目就像一个家。模型是住宅中充满特定内容的房间。
模型集是一组房间或单个房间（卧室、厨房）。
权限集是一种活动核对清单，用于指定用户可以在房间内执行哪些活动（吃饭、玩耍、睡觉）。
群组是一种将具有共同特征（成人、儿童、访客）的用户组合在一起的方法。
角色是指如何为不同房间的一组人提供活动核对清单。
用户属性是用于打开住宅中特殊物品（茶壶、电动工具）的钥匙。
场景
以下示例展示了一个拥有财务、销售和产品团队的初创公司。首席执行官是我们唯一的管理员，她希望每个团队只能看到与其相关的内容，但每个团队的副总裁应该可以访问所有团队的内容。她希望为标准员工、经理和副总裁分配不同的功能访问权限。
- 标准员工应该能够查看和探索自己模型中的数据。
- 经理应拥有标准访问权限，还可以下载和安排内容投放。
- 副总裁应拥有几乎所有权限，但少数权限仅供首席执行官使用。
首席执行官希望销售人员能够查看自己活动的数据，但不能查看其他销售人员的具体销售数据。不过，销售经理应该能够查看每位销售人员的数据。最后，她希望为使用该模型的标准员工隐去一些包含敏感信息的财务字段。
组织结构图如下：
下图显示了示例创业公司的组织结构：
- 首席执行官
- 财务副总裁
- 财务经理
- 会计师
- 销售副总裁
- 西区销售经理
- 销售人员 West
- 东部销售经理
- 销售人员（东部）
- 产品副总裁
- 产品经理
- Engineer
实现所需的访问权限控制将涉及以下步骤：
- 创建项目：项目是数据库连接与数据模型之间的结构性关联。
- 添加模型：决定向哪些用户显示哪些数据。
- 创建模型集：将相关模型归为一组。
- 创建权限集：明确定义用户可以在模型集中执行的操作。
- 创建群组：将类似用户归为一组。
- 创建角色：在模型集、权限集和群组之间建立关联。
- 修改内容访问权限：管理用户可以通过文件夹查看哪些信息中心和外观。
- 添加数据过滤条件：进一步过滤特定用户可以在模型中访问的数据。
1. 创建项目
我们首先需要创建一个项目，它是包含一个或多个模型的容器。如果您已设置项目，则可以跳过此步骤。或者，您也可以前往 LookML 项目页面，方法是选择 Looker 的开发部分中的项目，然后选择新建 LookML 项目以创建新项目。如需有关创建新项目的更详细说明，请参阅生成模型文档页面。
在新建项目页面上，我们将使用以下设置创建一个项目：
- 在名称部分，为项目指定名称。
- 在起点部分，我们选择根据数据库架构生成模型。
- 在连接下拉菜单中，选择数据库连接的名称。
- 在基于以下数据构建视图部分，在此示例中，我们选择 All Tables（所有表）选项，以便 LookML 生成器为数据库中的每个表创建一个视图文件。
为新项目配置所需设置后，选择创建项目。
创建项目后，您会进入项目的自动生成的 LookML 模型。此时，您需要使用配置 Git 按钮为项目设置版本控制。如需详细了解如何设置版本控制，请参阅设置和测试 Git 连接文档页面。
2. 添加模型
数据模型就像一个可自定义的数据库门户。每种模型都可能会向用户显示不同的数据。在我们的示例中，销售人员需要的数据不同于工程师，因此我们将添加单独的模型，以便向每种类型的用户显示数据库中的适当信息。
在 LookML 项目中，我们将添加新的 LookML 模型文件，并在其中添加所需的每个模型的名称（finance、sales 和 product）。请务必在每个模型文件中定义至少一个探索；这样，我们就可以在创建模型集时选择模型（否则，它们不会显示在选择中）。如需有关如何在模型文件中使用 explore 参数的更多参考信息，请参阅了解模型和视图文件文档页面。
成功添加模型后，我们仍需要对其进行配置。如需 配置模型，我们将返回到开发部分中的项目页面，该页面现在应在每个模型名称旁边显示红色文本“使用需要配置”。
在每个模型旁边，选择配置。我们将确保项目名称以及允许此模型使用的连接正确无误，然后保存。
所有模型都正确配置后，我们之前遇到的红色配置问题消息将不再显示。
请注意，在 Looker 中，向用户授予对某个模型的 see_lookml 或 develop 权限即会向其授予对该项目中所有模型的此权限。因此，如果您想对查看或开发 LookML 的权限进行分区，则应创建单独的项目。否则，您应只创建新模型。模型权限足以确保只有特定人员可以查询特定数据。
如需详细了解权限，请参阅我们关于角色的文档。
3. 创建模型集
现在，我们已经配置好每个部门的数据模型，接下来将为每个部门添加相应的模型，并将其添加到我们构建的模型集中。如需创建新的模型集，我们将前往管理面板中的角色页面，然后选择新建模型集。如需详细了解如何创建新的模型集，请参阅角色文档页面。
创建新的模型集后，它们会显示在角色页面的模型集部分，如以下示例屏幕截图所示：
4. 创建权限集
接下来，我们将使用刚刚创建的模型集创建权限集。如我们在设置场景时所述，我们希望有四个层级的权限与组织结构图中的四个层次级别相对应，并且更高级别应包含下级别的权限。在我们的场景中，我们将按如下方式识别权限集：
- 首席执行官已设置管理员权限。
- 副总裁具有受限管理员权限。
- 管理员已设置下载和分享权限。
- 标准员工具有查看和浏览权限。
如需创建新的权限集，我们将前往管理面板中的角色页面，然后选择新建权限集。我们将为每个权限层级选择适当的权限。一般而言，权限集应尽可能少重叠，每个权限集只应添加我们希望拥有此权限集的用户拥有的特定权限。这是因为我们会向部分用户授予多组权限，因此希望确切了解每组权限允许执行的操作。不过，由于树状结构，通常需要一些重叠。
在本例中，我们希望设置查看和探索权限，以允许用户查看内容、提问和保存实用功能块。因此，我们会向其授予与查看内容相关的权限（例如 see_looks 和 see_user_dashboards）、explore 权限和 save_content 权限。值得注意的例外情况是 see_lookml，我们可能只希望开发者拥有此权限；see_sql 则仅供同时了解 SQL 且有权查看数据库结构的用户使用。所有这些权限都严格受 access_data 分支的约束。我们不会授予树底部的任何 see 权限，因为它们是管理员权限。
对于下载和分享权限集，我们将添加与下载、安排、分享、创建公开外观（允许将外观分享给非 Looker 用户）和 see_schedules 相关的权限（由于他们可以创建时间表，因此他们也可以在管理控制台中查看时间表）。
在配置查看和探索权限集和下载和分享权限集时，所选的唯一字段是选择 access_data 分支下添加的子权限所需的父级权限。因此，由于具有下载和分享权限集的用户也将具有查看和探索权限集，因此无需在下载和分享权限集中添加 see_lookml_dashboards、see_user_dashboards 和 explore 等权限，因为这些权限不包含下载和分享权限集所需的任何子权限。
最后，对于受限管理员权限集，我们将在树的底部添加大多数管理员权限，但不包括首席执行官希望仅供她使用的 manage_models 和 sudo 权限。如下所示：
完成后，权限集将包含以下权限：
- 管理员：管理员权限集专为我们示例公司的首席执行官预留，包含所有权限。
- 受限管理员：受限管理员权限集包括
create_prefetches、login_special_email、manage_homepage、manage_spaces、see_alerts、see_datagroups、see_logs、see_pdts、see_queries、see_users和update_datagroups权限。 - 下载和分享：下载和分享权限集包括
access_data、create_public_looks、download_with_limit、download_without_limit、save_content、schedule_external_look_emails、schedule_look_emails、see_looks、see_schedules、send_outgoing_webhook、send_to_s3和send_to_sftp权限。 - 查看和探索：查看和探索权限集包括
access_data、create_table_calculations、explore、save_content、see_drill_overlay、see_lookml_dashboards、see_looks和see_user_dashboards权限。
您可以前往角色管理页面的权限集部分，查看属于现有权限集的权限。
5. 创建群组
下一步是创建群组并对用户进行分桶。我们将为每个部门的标准员工和经理创建群组，因为这些群组最终将与我们稍后创建的不同角色匹配。副总裁将位于自己的群组中，而首席执行官无需加入群组。完成后，群组页面应列出以下群组及其对应的群组 ID（由 Looker 自动生成）。例如：
| ID | 名称 |
|---|---|
| 1 | 所有用户 |
| 3 | 金融 |
| 4 | 销售 |
| 5 | 产品 |
| 7 | 销售经理 |
| 8 | 产品经理 |
| 9 | 财务经理 |
| 10 | 副总裁 |
创建群组后，我们需要将用户添加到这些群组中。如需了解如何将用户添加到群组，请参阅群组文档页面。
将用户添加到我们创建的群组时，请注意，由于我们对权限的结构进行了调整，因此更高级别的群组可能会包含在更低级别的群组中。例如，我们希望将副总裁添加到财务组，但不希望将销售经理添加到产品组。一种高效的方法是，先将用户添加到更高级别的群组（例如副总裁），然后再将他们作为一个群组添加到更低级别的群组。
6. 创建角色
现在，我们已经有了模型集、权限集和群组，接下来可以使用角色将它们组合在一起。每个角色都将具有一组权限和一组模型，并且可能包含一个或多个群组。由于角色必须包含模型集，因此我们将再次为每个部门的标准员工和经理创建角色。
- 标准角色：标准角色将包含查看和探索权限集以及相应的模型集。向该部门的标准群组和经理群组以及副总裁分配标准角色。例如，将标准财务角色分配给财务和财务经理群组，以及财务副总裁。
- 经理角色：经理角色将拥有下载和分享权限集以及相应的模型集。这些角色应分配给相应部门的管理员群组以及该部门的副总裁。
- 经理角色：经理角色将拥有下载和分享权限集以及相应的模型集。这些角色应分配给相应部门的管理员群组以及该部门的副总裁。
- 副总裁角色：副总裁角色将具有受限管理员权限集和全部模型集。此角色将分配给副总裁群组。
7. 修改内容访问权限
下一步是整理文件夹访问权限，以便每个群组都可以访问自己的内容（且仅限自己的内容）。以下是示例实例中的文件夹布局，您可以前往管理控制台中的内容访问页面查看该布局：
对文件夹的访问权限遵循分层继承规则。如需详细了解此功能的运作方式，请参阅我们关于访问权限级别和访问权限控制和权限管理的文档。
根据文件夹访问权限规则，我们希望向共享文件夹中的所有用户授予查看权限。我们将向每个群组授予对树中群组有权访问的文件夹上方父级文件夹的查看权限。这样，在向下遍历树时，如果我们不希望某个群组看到某个文件夹，则在授予访问权限时不会将该群组包含在内。
如果我们想控制哪些人可以看到某个文件夹，可以向该文件夹中的群组授予管理访问权限、修改访问权限级别。在我们的示例中，我们只希望首席执行官和副总裁拥有这些权限；其他所有人对所需文件夹的访问权限仅限于查看。
8. 使用用户属性添加数据访问权限限制
本部分介绍了阻止特定用户访问其有权访问的模型中的特定数据行或列的方法。请注意，我们的首席执行官希望销售人员能够查看自己个人活动的数据，但不能查看他人的活动数据。不过，销售经理应该能够查看每位销售人员的数据。为此，我们将利用用户属性和 sql_always_where 参数。
创建用户属性
首先，我们将创建一个名为 access_level 的新用户属性，并将其隐藏起来。这样，我们就可以为不同的群组定义访问权限层级。在创建用户属性时，我们将设置以下值：
- 名称：
access_level - 标签：访问权限级别
- 数据类型：字符串
- 用户访问权限：修改
- 隐藏值：否
在本例中，我们将不选中设置默认值复选框。
创建此字段时，我们将配置三种访问权限级别：基本、付费和完整。我们将分别为标准组、经理组和副总裁组分配这些级别。具体方法是在同一部分的 Group Values 标签页下执行。如需了解详情，请参阅用户属性文档的向用户群组分配值部分。
由于这些规则的顺序很重要，因此我们希望将最高的访问权限值放在列表顶部，以覆盖位于底部的较低访问权限值。用户属性文档页面中对此行为进行了进一步说明。
使用用户属性过滤行数据
我们假设已经有一个包含所有销售信息的“探索”正在构建中。我们会检查查询探索的用户的访问权限级别；如果访问权限级别为基本级别（我们已向所有标准销售人员授予此级别），则我们将始终按用户姓名过滤探索，这样每个销售人员只能看到自己名下的行。如果访问权限级别为 Premium 或 完整，则系统不会滤除相应查询。默认情况下，我们有一个名为 Name 的用户属性，即 Looker 用户的名称。探索的 LookML 将如下所示：
explore: sales_info {
sql_always_where: {% if {{_user_attributes['access_level']}} == "Basic" %}
${sales_info.name} = "{{_user_attributes['name']}}"
% endif %
;;
}
使用用户属性过滤列数据
最后，我们还希望对部分用户隐藏财经模型中的一些个人身份信息 (PII) 列。为此，我们可以使用我们创建的用户属性，以及用户属性文档页面上关于在 Looker 中应用数据库级权限的说明，仅向具有完整访问权限级别的用户授予查看个人身份信息 (PII) 字段的权限。
大功告成！我们已完成内容和数据访问权限控制设置，所有用户都可以自由探索 Looker。这样一来，我们可以确保他们只能看到我们允许他们看到的内容。