这些最佳实践体现了由经验丰富的 Looker 跨职能团队分享的建议。这些见解源自我们与 Looker 客户合作的多年经验，从实施到长期成功，这些经验总结得出。我们编写的做法适用于大多数用户和情况，但在实现时，始终需要运用自己的最佳判断。
本页面为 Looker 实例管理员提供了一个设置内容访问权限控制的引导示例。我们将逐步介绍实现流程，首先创建一个新项目，然后继续介绍模型、模型集、权限集、组、角色和用户属性。
首先，我们通过类比的方式理解 Looker 在此上下文中的主要功能：
项目就像家。model模型是指家中摆满特定内容的房间。
模型集是一组房间或单个房间（卧室、厨房）。
权限集是一种活动核对清单，用于指定用户可以在房间中执行哪些操作（吃饭、玩乐、睡觉）。
群组是一种将具有共同特征（成人、儿童和房客）的人结合在一起的方式。
角色是指如何为用户群组提供不同分组会议的活动核对清单。
用户属性是用于打开家里的特殊物品（茶壶、电动工具）的键。
情况
下面是一个拥有财务、销售和产品团队的初创公司示例。首席执行官是我们唯一的管理员，她希望每个团队只能看到与他们相关的内容，但每个团队的副总裁都可以访问所有团队的内容。她希望标准员工、经理和副总裁能使用不同的功能。
- 标准员工应该能够通过自己的模型查看和探索数据。
- 管理员应具有标准权限，并且能够下载和安排内容。
- 副总裁应该拥有几乎所有权限，除了首席执行官专有的一些权限之外。
首席执行官希望销售人员能够查看自己活动的数据，但无法查看其他销售人员的个人销售数字。但是，销售经理应该能够查看每个销售人员的号码。最后，她想要为使用该模型的普通员工遮盖一些包含敏感信息的财务字段。
组织结构图如下所示：
上图显示了我们示例初创公司的以下组织结构：
- 首席执行官
- 财务副总裁
- 财务经理
- 会计师
- 销售副总裁
- 西部销售经理
- 销售人员西
- 销售经理（东部）
- 销售人员东部
- 产品副总裁
- 产品经理
- Engineer
实现所需的访问权限控制涉及以下步骤：
- 创建项目：项目是数据库连接和数据模型之间的结构联系。
- 添加模型：决定向哪些用户显示哪些数据。
- 创建模型集：将相关模型归为一组。
- 创建权限集：明确定义用户可以在模型集中执行的操作。
- 创建群组：将相似的用户归类到一起。
- 创建角色：在模型集、权限集和组之间创建连接。
- 修改内容访问权限：管理用户可以通过文件夹查看哪些信息中心和 Look。
- 添加数据过滤条件：进一步过滤特定用户在模型中可以访问的数据。
1. 创建项目
首先，我们需要一个项目，即一个或多个模型的容器。如果您已设置项目，可以跳过此步骤。否则，您可以通过在 Looker 的 Develop 部分中选择 Projects，然后选择 New LookML Project 来创建新项目，前往 LookML 项目页面。如需详细了解如何创建新项目，请参阅创建新的 LookML 项目文档页面。
在 New Project 页面上，我们将使用以下设置创建一个项目：
- 在名称部分中，为项目命名。
- 在起始点部分中，我们选择从数据库架构生成模型。
- 在连接下拉菜单中，选择数据库连接的名称。
- 在本示例中，在从以下对象构建视图部分中，我们选择所有表选项，以便 LookML 生成器为数据库中的每个表创建一个视图文件。
为新项目配置所需设置后，选择创建项目。
创建项目后，您将转到项目自动生成的 LookML 模型。此时，您需要使用 Configure Git 按钮为项目设置版本控制。如需详细了解如何设置版本控制，请参阅设置和测试 Git 连接文档页面。
2. 添加模型
数据模型就像是数据库的可自定义门户。model每种模型都可能会向用户显示不同的数据。在我们的示例中，销售人员需要的数据与工程师需要的数据不同，因此我们要添加单独的模型，以便向各类用户显示来自数据库的适当信息。
在我们的 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 权限，因为它们是管理员权限。
对于下载和共享权限集，我们将添加与下载、安排、共享、创建公开 Look（允许与非 Looker 用户共享 Look）和 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，这些 ID 是由 Looker 自动生成的。例如：
| ID | 名称 |
|---|---|
| 1 | 所有用户 |
| 3 | 财务 |
| 4 | 销售 |
| 5 | 产品 |
| 7 | 销售经理 |
| 8 | 产品经理 |
| 9 | 财务经理 |
| 10 | 副总裁 |
创建群组后，我们需要将用户添加到这些群组中。如需了解如何将用户添加到群组，请参阅群组文档页面。
当您将用户添加到我们创建的群组时，请注意，由于我们采用结构化权限的方式，较高层级的群组可能会包含在较低层级的群组中。例如，我们想在财务组中拥有副总裁，但不希望在产品组中拥有销售经理。解决此问题的一种有效方法是，首先将用户添加到较高层级的群组（例如 VP），以便将他们作为群组添加到较低层级。
6. 创建角色
现在，我们已经有了模型集、权限集和群组，接下来可以使用角色将它们整合在一起。每个角色都包含一个权限集和一个模型集，并且可能包含一个或多个组。由于角色必须包含一个模型集，因此我们再次为标准员工和各部门经理创建角色。
- 标准角色：标准角色将包含查看和探索权限集以及相应的模型集。将标准角色分配给该部门的标准群组和经理群组，以及副总裁。例如，将标准财务角色分配给财务和财务管理员群组，以及财务副总裁。
- 管理员角色：管理员角色拥有下载和分享权限集以及相应的模型集。这些角色应分配给相应部门的经理组，以及部门的 VP。
- 管理员角色：管理员角色拥有下载和分享权限集以及相应的模型集。这些角色应分配给相应部门的经理组，以及部门的 VP。
- VP 角色：VP 角色会拥有受限管理员权限集和所有模型集。此角色将分配给副总裁群组。
7. 修改内容访问权限
下一步是整理我们的文件夹访问权限，以便每个群组都可以访问自己的（且仅能访问自己的）内容。以下是示例实例中的文件夹布局，您可以转到管理控制台中的内容访问权限页面进行查看：
对文件夹的访问遵循分层继承规则。如需详细了解相关工作原理，请参阅有关访问权限级别以及访问权限控制和权限管理的文档。
根据文件夹访问规则，我们希望向共享文件夹中的所有用户授予查看权限。我们会向每个群组授予查看权限，使其可以访问树形结构中该群组有权访问的文件夹上方的父级文件夹。这样，当我们向下遍历树时，如果我们不希望某个群组查看某个文件夹，就不会在授予访问权限时包含该组。
我们可以为某个文件夹中的群组授予管理访问权限、修改权限，以便控制哪些用户可以查看该文件夹。在我们的示例中，我们只希望 CEO 和 VP 拥有这些权限；其他人只能查看他们所需的文件夹的查看权限。
8. 使用用户属性添加数据访问限制
本部分介绍用于防止特定用户访问其有权访问的模型中特定行或数据列的方法。请记住，我们的首席执行官希望销售人员能够查看他们自己的各项活动的数据，而不是其他人的活动数据。不过，销售经理应该能够查看每位销售人员的号码。为此，我们将利用用户属性和 sql_always_where 参数。
创建用户属性
首先，我们将创建一个名为 access_level 的新用户属性，该属性对用户隐藏。这样，我们就能为不同的群组定义访问权限层级。我们将在创建用户属性时设置以下值：
- 名称：
access_level - 标签：访问权限级别
- 数据类型：字符串
- 用户访问权限：修改
- 隐藏值：否
在本示例中，我们不要选中设置默认值复选框。
在创建该字段时，我们将配置三个访问权限级别：基本、高级和完整。我们会分别将这些级别分配给“标准”群组、“管理员”群组和“副总裁”群组。此操作在同一部分中的组值标签页下完成。如需了解详情，请参阅用户属性文档的为用户组分配值部分。
由于这些规则的顺序很重要，因此我们希望将最高访问权限值放在列表顶部，以覆盖靠近底部的访问权限值。此行为进一步说明了我们的用户属性文档页面。
使用用户属性过滤行数据
我们假设，已经有一个包含所有销售信息的探索正在构建中。我们将检查查询“探索”的用户的访问权限级别；如果访问权限级别为基本（我们已向所有标准销售人员授予该访问权限级别），我们将始终根据用户的姓名过滤“探索”，以便他们只能访问每位销售人员自己的行。如果访问权限级别是高级或完整，则该查询不会被滤除。默认情况下，我们有一个名为名称的用户属性，这是 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。这样，我们可以放心，他们只能看到我们允许他们看到的内容。