9. 基于角色的访问控制

基于角色的访问控制 (RBAC) 构建在 AWX 中，允许管理员委派对服务器库存、组织等的访问权限。管理员还可以集中管理各种凭据，允许最终用户在不向最终用户公开任何秘密的情况下利用所需的秘密。RBAC 控制允许 AWX 帮助您提高安全性并简化管理。

本章分为两部分：最新的 RBAC 模型 (DAB RBAC) 和 现有的 RBAC 实现。

9.1. DAB RBAC

本节描述了 RBAC 的最新变化，包括使用 django-ansible-base (DAB) 库来增强现有角色，并允许创建自定义角色。但是，后端系统的内部实现发生了变化，但尚未反映在 AWX UI 中。后端的变化维护了一个兼容性层，因此 API 中的“旧”角色暂时仍然存在，直到完全兼容的 UI 替换现有角色。

新功能，特别是自定义角色，可以通过直接的 API 客户端或 API 浏览器实现，但 AWX UI 中的展示可能无法反映 API 中所做的更改。

新的 DAB 版本的 RBAC 允许创建自定义角色，可以通过 /api/v2/role_definitions/ 端点完成。然后，这些角色只能使用新的端点 /api/v2/role_user_assignments/ 和 /api/v2/role_team_assignments/ 进行分配。

如果您不想允许自定义角色，可以将设置 ANSIBLE_BASE_ALLOW_CUSTOM_ROLES 更改为 False。目前这仍然是一个基于文件的设置。

新的“添加”权限是此更改的主要亮点。您可以创建一个自定义组织角色，允许用户创建所有（或部分）类型的资源，并将其应用于特定组织。因此，用户无需被允许编辑所有项目，而是可以创建新项目，创建后，他们将自动获得其创建对象的管理员角色。

9.1.1. 团队的资源访问权限

本节提供了在新的 UI 中管理各个资源内的团队角色的参考以及相应的 API 调用。

访问资源的 **团队访问** 选项卡以管理团队角色。

../_images/rbac_jt_team_access.png

要从 API 获取团队角色分配的列表

GET /api/v2/role_team_assignments/?object_id=<template_id>&content_type__model=jobtemplate

列的排列方式是团队名称出现在第一列。角色名称位于 summary_fields.role_definition.name 下

要撤销 API 中团队的角色分配

DELETE /api/v2/role_team_assignments/<role_id_from_list_API_above>/

9.1.1.1. 添加角色

从 **团队访问** 选项卡中点击 **添加角色** 按钮会打开 **添加角色** 向导，您可以在其中选择要添加角色的团队。

../_images/rbac_team_access_add-roles.png

要从服务端点列出团队

GET /api/v2/teams

控制器 UI 中向导的下一步是将角色应用于选定的团队。

../_images/rbac_team_access_apply-roles.png

要列出 API 中选定资源类型可用的角色定义，请发出以下命令，但将下面的 content_type 替换为与资源类型匹配的内容

GET /api/v2/role_definitions/?content_type__model=jobtemplate

最后，检查您的选择，然后点击 **保存** 以保存您的更改。

../_images/rbac_team_access_add-roles-review.png

要在 API 中将角色分配给选定的团队，您必须通过引用与 object_id 关联的控制器中的团队 ID 和资源 ID，将单个角色分别分配给各个团队。

向此资源 (jobtemplate.id，本例中) 发出 POST 请求

POST /api/v2/role_team_assignments/

以下显示了为上面发出的 POST 请求发送的有效负载示例

{"team": 25, "role_definition": 4, "object_id": "10"}

当更改通过 UI 成功应用时，将显示一条消息以确认更改

../_images/rbac_team_access_add-roles-success.png

9.1.2. 用户的资源访问权限

本节提供了在新的 UI 中管理各个资源内的用户角色的参考以及相应的 API 调用。

访问资源的 **用户访问** 选项卡以管理用户角色。

../_images/rbac_jt_user_access.png

要从 API 获取用户角色分配的列表

GET /api/v2/role_user_assignments/?object_id=<template_id>&content_type__model=jobtemplate

列的排列方式是用户名出现在第一列。角色名称位于 summary_fields.role_definition.name 下

要撤销 API 中用户的角色分配

DELETE /api/v2/role_user_assignments/<role_id_from_list_API_above>/

9.1.2.1. 添加角色

从 **用户访问** 选项卡中点击 **添加角色** 按钮会打开 **添加角色** 向导，您可以在其中选择要添加角色的用户。

../_images/rbac_user_access_add-roles.png

要从服务端点列出团队

GET /api/v2/users

控制器 UI 中向导的下一步是将角色应用于选定的团队。

../_images/rbac_user_access_apply-roles.png

要列出 API 中选定资源类型可用的角色定义，请发出以下命令，但将下面的 content_type 替换为与资源类型匹配的内容

GET /api/v2/role_definitions/?content_type__model=jobtemplate

最后，检查您的选择，然后点击 **保存** 以保存您的更改。

../_images/rbac_user_access_add-roles-review.png

要在 API 中将角色分配给选定的用户，您必须通过引用与 object_id 关联的控制器中的用户 ID 和资源 ID，将单个角色分别分配给各个用户。

向此资源 (jobtemplate.id，本例中) 发出 POST 请求

POST /api/v2/role_user_assignments/

以下显示了为上面发出的 POST 请求发送的有效负载示例

{"user": 25, "role_definition": 4, "object_id": "10"}

当更改通过 UI 成功应用时，将显示一条消息以确认更改

../_images/rbac_team_access_add-roles-success.png

9.1.3. 自定义角色a

在 DAB RBAC 模型中，超级用户有权创建、修改和删除自定义角色。

要创建自定义角色，请从 UI 中的 **角色** 资源中点击 **创建角色** 按钮，并提供新角色的详细信息

  • **名称**：必填

  • **描述**：根据需要输入任意描述（可选）

  • **资源类型**：必填。从下拉菜单中选择资源类型（每个角色只允许一种资源类型）。这相当于 content_type 在 OPTIONS /api/v2/role_definitions 中进行选择。

  • 根据所选的资源类型选择权限。（Alan 将提供包含基于内容类型的可用权限的字典的端点（UI 可以使用此端点在客户端维护静态可读的可翻译文本）待定）

修改自定义角色只允许您更改权限，但不允许更改内容类型。

要删除自定义角色

DELETE /api/v2/role_definitions/:id

9.2. 传统 RBAC 模型

顾名思义，RBAC 是基于角色的，角色包含一个权限列表。这是一个以域为中心的概念，其中组织级角色可以授予您对该域中所有内容的权限（例如 update_project），包括该组织中的所有项目。

关于 AWX 的 RBAC 设计，您应该熟悉几个主要概念——角色、资源和用户。用户可以是角色的成员，这赋予他们对与该角色关联的任何资源或与“后代”角色关联的任何资源的特定访问权限。

角色本质上是一个权限列表。用户通过他们被分配的角色或通过角色层次结构继承的角色获得对这些功能和 AWX 资源的访问权限。

角色将一组功能与一组用户关联。所有功能都来自角色成员资格。用户仅通过他们被分配的角色或通过他们通过角色层次结构继承的角色获得功能。角色的所有成员都拥有授予该角色的所有功能。在一个组织中，角色相对稳定，而用户和功能都很多，而且可能快速变化。用户可以拥有多个角色。

9.2.1. 角色层次结构和访问继承

假设您有一个名为“SomeCompany”的组织，并且想要允许两个人“Josie”和“Carter”访问该组织的所有设置。您应该将两个人都设为该组织的 admin_role 成员。

user-role-relationship

通常，您将在系统中拥有许多角色，并且您希望某些角色包含其他角色的所有功能。例如，您可能希望系统管理员能够访问组织管理员拥有的一切，组织管理员能够访问项目管理员拥有的一切，依此类推。

这个概念被称为“角色层次结构”。

  • 父角色获得任何子角色所赋予的所有功能。

  • 角色成员自动获得其所成员角色的所有功能，以及任何子角色的所有功能。

角色层次结构通过允许角色具有“父角色”来表示。角色拥有的任何功能都会隐式授予其任何父角色（或这些父角色的父角色，等等）。

rbac-role-hierarchy

通常，系统中会有很多角色，并且您希望某些角色包含其他角色的所有功能。例如，您可能希望系统管理员拥有组织管理员拥有的所有权限，组织管理员拥有项目管理员拥有的所有权限，等等。我们将此概念称为“角色层次结构”，它通过允许角色具有“父角色”来表示。角色拥有的任何功能都会隐式授予其任何父角色（或这些父角色的父角色，等等）。当然，角色可以有多个父角色，并且功能会隐式授予所有父角色。

rbac-heirarchy-morecomplex

RBAC 控制还允许您显式地允许用户和用户团队针对某些主机集运行剧本。用户和团队被限制在他们被授予权限的剧本集和主机集。而且，使用 AWX，您可以创建或导入所需的任意数量的用户和团队——手动创建用户和团队，或从 LDAP 或 Active Directory 导入。

RBAC 最容易从谁或什么可以查看、更改或删除正在确定特定功能的“对象”的角度来理解。

9.2.2. 应用 RBAC

以下部分介绍如何在您的环境中应用 AWX 的 RBAC 系统。

9.2.2.1. 编辑用户

编辑用户时，AWX 系统管理员可以将用户指定为系统管理员（也称为超级用户）或系统审计员。

  • 系统管理员隐式继承 AWX 环境中所有对象的全部功能（读/写/执行）。

  • 系统审计员隐式继承 AWX 环境中所有对象的只读功能。

9.2.2.2. 编辑组织

编辑组织时，系统管理员可以指定以下角色

  • 一个或多个用户作为组织管理员

  • 一个或多个用户作为组织审计员

  • 以及一个或多个用户（或团队）作为组织成员

属于某个组织的用户/团队可以查看其组织管理员。

组织管理员隐式继承该 AWX 组织中所有对象的全部功能。

组织审计员隐式继承该 AWX 组织中所有对象的只读功能。

9.2.2.3. 编辑组织中的项目

在编辑其为管理员的组织中的项目时，系统管理员和组织管理员可以指定

  • 一个或多个用户/团队作为项目管理员

  • 一个或多个用户/团队作为项目成员

  • 以及一个或多个用户/团队可以从 SCM 更新项目，这些用户/团队是该组织的成员。

项目成员可以查看其项目管理员。

项目管理员隐式继承从 SCM 更新项目的权限。

管理员还可以指定一个或多个用户/团队（来自该项目的成员）可以在作业模板中使用该项目。

9.2.2.4. 在组织中创建清单和凭据

授予使用、读取或写入凭据的所有访问权限都通过角色进行处理，这些角色使用 AWX 的 RBAC 系统授予所有权、审计员或使用角色。

系统管理员和组织管理员可以在其管理权限下的组织中创建清单和凭据。

无论是编辑清单还是凭据，系统管理员和组织管理员都可以指定一个或多个用户/团队（来自该组织的成员）以获得该清单或凭据的使用权限。

系统管理员和组织管理员可以指定一个或多个用户/团队（来自该组织的成员）拥有更新（动态或手动）清单的权限。管理员还可以对清单执行临时命令。

9.2.2.5. 编辑作业模板

系统管理员、组织管理员和项目管理员可以在其管理权限下的项目中为该项目创建和修改新的作业模板。

编辑作业模板时，管理员（AWX、组织和项目）可以在组织中拥有使用权限的清单和凭据中选择，或者他们可以将这些字段留空，以便在运行时选择它们。

此外，他们可以指定一个或多个用户/团队（来自该项目的成员）对该作业模板具有执行权限。执行权限在用户/团队对作业模板中指定的清单或凭据获得的任何显式权限之外仍然有效。

9.2.2.6. 用户视图a

用户可以

  • 查看他们属于任何组织或项目

  • 创建只属于他们自己的凭据对象

  • 查看和执行他们被授予执行权限的任何作业模板

如果用户被授予执行权限的作业模板未指定清单或凭据，则系统将在运行时提示用户在他们拥有或被授予使用权限的组织中的清单和凭据中选择。

拥有作业模板管理员权限的用户可以更改作业模板；但是，要更改作业模板中使用的清单、项目、剧本、凭据或实例组，用户还必须拥有当前使用或正在设置的项目和清单的“使用”角色。

9.2.3. 角色

授予使用、读取或写入凭据的所有访问权限都通过角色进行处理，并且角色是为资源定义的。

9.2.3.1. 内置角色

下表列出了 RBAC 系统角色以及有关该角色在 AWX 中的权限定义方式的简要说明。

系统角色

它可以做什么

系统管理员 - 全系统单例

管理系统的各个方面

系统审计员 - 全系统单例

查看系统的各个方面

临时角色 - 清单

在清单上运行临时命令

管理员角色 - 组织、团队、清单、项目、作业模板

管理定义的组织、团队、清单、项目或作业模板的各个方面

审计员角色 - 所有

查看定义的组织、团队、清单、项目或作业模板的各个方面

执行角色 - 作业模板

运行分配的作业模板

成员角色 - 组织、团队

用户是定义的组织或团队的成员

读取角色 - 组织、团队、清单、项目、作业模板

查看定义的组织、团队、清单、项目或作业模板的各个方面

更新角色 - 项目

从配置的源代码管理系统更新项目

更新角色 - 清单

使用云源更新系统更新清单

所有者角色 - 凭据

拥有并管理该凭据的各个方面

使用角色 - 凭据、清单、项目、IG、CG

在作业模板中使用凭据、清单、项目、IG 或 CG

单例角色是一种特殊角色，它授予系统范围的权限。AWX 目前提供两个内置单例角色，但目前不支持创建或自定义单例角色的功能。

9.2.3.2. 通用团队角色 - “角色”

支持人员通常负责确保 AWX 的可用性，并以平衡可支持性和用户易用性的方式管理它。通常，支持人员会将“组织所有者/管理员”分配给用户，以允许他们创建新的组织并添加团队中的其他成员，从而获得所需的访问权限。这最大限度地减少了支持人员，并将重点更多地放在维护服务的正常运行时间和协助使用 AWX 的用户上。

以下是 AWX 组织管理的一些通用角色

系统角色
（对于组织）
普通用户
角色
描述
所有者
团队负责人 -
技术负责人
此用户有权控制组织中其他用户的访问权限。
他们可以添加/删除用户，并授予用户对项目、清单和作业模板的特定访问权限。
此用户还有权创建/删除/修改组织的项目、
模板、清单、团队和凭据的任何方面。
审计员
安全工程师 -
项目经理
此帐户可以以只读模式查看组织的所有方面。
这可能适合检查并维护合规性的用户。
这对于管理或
将作业数据从 AWX 发送到其他数据收集器的服务帐户来说也是一个不错的角色。
成员 -
团队
所有其他用户
默认情况下，这些用户作为组织成员不会获得组织任何方面的访问权限。
为了授予他们访问权限，相应的组织所有者需要
将它们添加到各自的团队，并授予它们管理、执行、使用、更新、临时
对组织的项目、库存和作业模板的每个组件的权限。
成员 -
团队“所有者”
高级用户 -
首席开发人员
组织所有者可以通过团队界面为任何组件提供“管理”权限
包括他们的组织，包括项目、库存和作业模板。这些用户能够
修改和使用授予访问权限的相应组件。
成员 -
团队“执行”
开发者 -
工程师
这将是最常见的权限，它允许组织成员执行
作业模板，并对特定组件拥有读取权限。此权限适用于模板。
成员 -
团队“使用”
开发者 -
工程师
此权限适用于组织的凭据、库存和项目。
此权限允许用户在作业模板中使用相应组件。
成员 -
团队“更新”
开发者 -
工程师
此权限适用于项目。允许用户能够对项目运行 SCM 更新。

9.3. 角色的功能：编辑和创建

组织的“资源角色”功能特定于某些资源类型，例如工作流。成为此类角色的成员通常会提供两种类型的权限，例如工作流，其中用户被赋予组织“默认”的“工作流管理员角色”

  • 此用户可以在组织“默认”中创建新的工作流

  • 用户可以编辑“默认”组织中的所有工作流

一个例外是作业模板，拥有该角色与创建权限无关（更多详细信息在它自己的部分）。

9.3.1. 资源角色和组织成员身份角色的独立性

特定于资源的组织角色独立于组织的管理员和成员角色。拥有“默认”组织的“工作流管理员角色”不会允许用户查看组织中的所有用户，但拥有“默认”组织的“成员”角色会。这两种类型的角色是独立委派的。

9.3.1.1. 编辑作业模板所需的权限

用户可以使用作业模板管理员角色单独编辑不影响作业运行的字段（非敏感字段）。但是，要编辑影响作业模板中作业运行的字段，用户需要以下内容

  • 对作业模板和容器组的**管理**角色

  • 对相关项目的**使用**角色

  • 对相关库存的**使用**角色

  • 对相关实例组的**使用**角色

引入了“组织作业模板管理员”角色，但如果用户没有对项目/库存/实例组的使用角色或对作业模板使用的容器组的管理角色，则拥有此角色本身不足以编辑组织内的作业模板。

为了将完整的作业模板控制权（在组织内）委托给用户或团队，您需要授予团队或用户所有 3 个组织级角色

  • 作业模板管理员

  • 项目管理员

  • 库存管理员

这将确保用户（或所有拥有这些角色的团队成员）能够完全访问组织中的作业模板。如果作业模板使用来自另一个组织的库存或项目，则拥有这些组织角色的用户可能仍然没有修改该作业模板的权限。为了明确管理权限，最佳实践是不混合来自不同组织的项目/库存。

9.3.1.2. RBAC 权限

每个角色都应该有一个内容对象，例如，组织管理员角色有一个组织的内容对象。要委托角色，您需要对内容对象拥有管理权限，但有一些例外会导致您能够重置用户的密码。

**父**是组织。

**允许**是此新权限将明确允许的内容。

**范围**是将在此新角色上创建的父资源。示例：Organization.project_create_role。

假设正在创建资源的用户应该被授予该资源的管理员角色。如果存在任何资源创建不也意味着资源管理的情况，则会明确说明。

以下是与每种管理员类型相关的规则

项目管理员

  • 允许：创建、读取、更新、删除任何项目

  • 范围：组织

  • 用户界面：项目添加屏幕 - 组织

库存管理员

  • 父：组织管理员

  • 允许：创建、读取、更新、删除任何库存

  • 范围：组织

  • 用户界面：库存添加屏幕 - 组织

注意

与**使用**角色一样，如果您授予用户项目管理员和库存管理员角色，则允许他们为您的组织创建作业模板（而不是工作流）。

凭据管理员

  • 父：组织管理员

  • 允许：创建、读取、更新、删除共享凭据

  • 范围：组织

  • 用户界面：凭据添加屏幕 - 组织

通知管理员

  • 父：组织管理员

  • 允许：分配通知

  • 范围：组织

工作流管理员

  • 父：组织管理员

  • 允许：创建工作流

  • 范围：组织

组织执行

  • 父：组织管理员

  • 允许：执行 JT 和 WFJTs

  • 范围：组织

以下是一个示例场景，显示了一个组织及其角色，以及每个角色可以访问哪些资源

../_images/rbac-multiple-resources-scenario.png