27. 安全性¶
以下部分将帮助您了解 Ansible Tower 如何处理文件系统安全性以及如何让您控制它。
所有剧本都是通过 awx 文件系统用户执行的。对于运行的作业，Ansible Tower 默认情况下通过 Linux 命名空间和 chroot 提供作业隔离。这种投影确保作业只能从该作业模板的项目目录和 /opt 等常用位置访问剧本和角色。默认情况下，剧本无法访问其他项目的角色、剧本或数据。
如果您需要禁用此保护（不建议），您可以编辑 /etc/tower/conf.d/custom.py 并将 AWX_PROOT_ENABLED 设置为 False。
注意
在这种情况下，剧本可以访问文件系统及其所有含义；因此，有权编辑剧本的用户 **必须** 是可信的。
为了凭据安全，用户可以选择上传锁定 SSH 密钥并将解锁密码设置为“ask”。您也可以选择让系统提示他们输入 SSH 凭据或 sudo 密码，而不是让系统将它们存储在数据库中。
27.1. 剧本访问和信息共享¶
默认情况下，Tower 的多租户安全性会阻止剧本读取项目目录之外的文件。Bubblewrap 用于将 Tower 作业进程与系统其他部分隔离，因为它重量轻且维护了进程隔离系统。
默认情况下，bubblewrap 已启用，但可以在 Tower 用户界面中的配置 Tower - 作业设置 屏幕中关闭。
启用时，进程隔离将用于以下作业类型
作业模板 - 从常规作业模板启动作业
临时命令 - 对清单中的一个或多个主机启动临时命令
默认情况下，进程隔离会从上述任务中隐藏以下目录
/etc/tower- 为了防止公开 Tower 配置/etc/ssh- 为了防止公开识别主机私钥和公钥对的系统配置/var/lib/awx- 除了正在使用的当前项目（对于常规作业模板）/var/log/tmp（或系统的临时目录） - 除了进程自己的临时文件
您可以使用配置 Tower 屏幕或设置文件自定义在运行剧本时隐藏或公开的内容。有关更多信息，请参阅下一部分 Bubblewrap 功能和变量。
27.1.1. Bubblewrap 功能和变量¶
Ansible Tower 中的 bubblewrap 功能限制了剧本在剧本运行期间可用于查看和使用的 Tower 文件系统上的目录。在某些情况下，您可能需要自定义 bubblewrap 设置。为了微调 bubblewrap 的使用，可以设置某些变量。
要禁用或启用对运行作业（仅限剧本运行）的 bubblewrap 支持，请确保您以管理员用户身份登录
从左侧导航栏中单击设置 (
) 图标。单击 **作业** 选项卡。
在 **启用作业隔离** 中，将切换按钮选择更改为 **关闭** 以禁用 bubblewrap 支持，或选择 **开启** 以启用它。
默认情况下，Tower 将使用系统的 tmp 目录（默认情况下为 /tmp）作为其暂存区。这可以在配置 Tower 屏幕的 **作业执行路径** 字段中更改，或者通过更新设置文件中的以下条目更改
AWX_PROOT_BASE_PATH = "/opt/tmp"
如果系统上还有其他敏感信息需要隐藏，您可以在配置 Tower 屏幕的 **要从隔离作业中隐藏的路径** 中指定这些信息，或者通过更新设置文件中的以下条目指定
AWX_PROOT_HIDE_PATHS = ['/list/of/', '/paths']
如果需要公开某些目录，可以在“配置 Tower”屏幕上的“向隔离作业公开的路径”中指定，也可以在设置文件中的以下条目中更新这些目录。
AWX_PROOT_SHOW_PATHS = ['/list/of/', '/paths']
注意
可能需要添加到
AWX_PROOT_SHOW_PATHS中的主要文件是/var/lib/awx/.ssh，如果您的剧本需要使用其中定义的密钥或设置。
以上字段可以在“作业设置”窗口中找到。
如果在设置文件中进行了更改，请确保在保存更改后使用 ansible-tower-service restart 命令重启服务。
27.2. 基于角色的访问控制¶
基于角色的访问控制 (RBAC) 集成在 Tower 中，允许 Tower 管理员委派对服务器清单、组织等的访问权限。管理员还可以集中管理各种凭据，允许最终用户利用所需的密钥，而无需将该密钥公开给最终用户。RBAC 控制允许 Tower 帮助您提高安全性并简化管理。
RBAC 最容易理解的是角色，角色精确地定义了谁或什么可以查看、更改或删除特定功能正在设置的“对象”。RBAC 是向用户或团队授予角色的做法。
关于 Tower 的 RBAC 设计，您应该熟悉几个主要概念：角色、资源和用户。用户可以是角色的成员，这使他们可以访问与该角色关联的任何资源，或访问与“子级”角色关联的任何资源。
角色本质上是一组功能。用户通过分配给他们的角色或通过角色层次结构继承的角色，获得对这些功能和 Tower 资源的访问权限。
角色将一组功能与一组用户相关联。所有功能都源自角色中的成员身份。用户仅通过分配给他们的角色或通过他们通过角色层次结构继承的角色来获得功能。角色的所有成员都拥有授予该角色的所有功能。在一个组织内，角色相对稳定，而用户和功能既多又可能快速发生变化。用户可以拥有多个角色。
27.2.1. 角色层次结构和访问权限继承¶
假设您有一个名为“SomeCompany”的组织，并希望允许两个人“Josie”和“Carter”访问该组织的所有相关设置。您应该让这两个人成为该组织的 admin_role 成员。
通常，系统中会有很多角色，您希望某些角色包含其他角色的所有功能。例如，您可能希望系统管理员能够访问组织管理员能够访问的所有内容，组织管理员能够访问项目管理员能够访问的所有内容，等等。
此概念称为“角色层次结构”。
父级角色获得授予任何子级角色的所有功能。
角色成员自动获得他们所属角色以及任何子级角色的所有功能。
角色层次结构通过允许角色具有“父级角色”来表示。角色拥有的任何功能都隐式授予任何父级角色（或这些父级的父级，等等）。
通常，系统中会有很多角色，您希望某些角色包含其他角色的所有功能。例如，您可能希望系统管理员能够访问组织管理员能够访问的所有内容，组织管理员能够访问项目管理员能够访问的所有内容，等等。我们将此概念称为“角色层次结构”，它通过允许角色具有“父级角色”来表示。角色拥有的任何功能都隐式授予任何父级角色（或这些父级的父级，等等）。当然，角色可以有多个父级，功能隐式授予所有父级。
RBAC 控制还使您能够明确允许用户和用户团队对特定主机集运行剧本。用户和团队仅限于他们被授予功能的剧本集和主机集。并且，使用 Tower，您可以创建或导入所需数量的用户和团队 - 手动创建用户和团队，或从 LDAP 或 Active Directory 导入它们。
RBAC 最容易理解的是谁或什么可以查看、更改或删除特定功能正在确定的“对象”。
27.2.2. 应用 RBAC¶
以下部分介绍如何在您的环境中应用 Tower 的 RBAC 系统。
27.2.2.1. 编辑用户¶
编辑用户时，Tower 系统管理员可以将用户指定为系统管理员（也称为超级用户）或系统审计员。
系统管理员隐式继承 Tower 环境中所有对象的全部功能（读/写/执行）。
系统审计员隐式继承 Tower 环境中所有对象的只读功能。
27.2.2.2. 编辑组织¶
编辑组织时，系统管理员可以指定以下角色：
一个或多个用户作为组织管理员。
一个或多个用户作为组织审计员。
以及一个或多个用户（或团队）作为组织成员。
属于组织的团队/用户可以看到他们的组织管理员。
组织管理员隐式继承该 Tower 组织中所有对象的全部功能。
组织审计员隐式继承该 Tower 组织中所有对象的只读功能。
27.2.2.3. 编辑组织中的项目¶
编辑组织中他们作为管理员的项目时，系统管理员和组织管理员可以指定：
一个或多个用户/团队作为项目管理员。
一个或多个用户/团队作为项目成员。
以及一个或多个用户/团队可以从 SCM 更新项目，这些用户/团队是该组织的成员。
属于项目的团队/用户可以看到他们的项目管理员。
项目管理员隐式继承从 SCM 更新项目的功能。
管理员还可以指定一个或多个用户/团队（来自该项目的成员）可以在作业模板中使用该项目。
27.2.2.4. 在组织中创建清单和凭据¶
现在，通过角色处理授予使用、读取或写入凭据的所有访问权限。您不再为凭据设置“团队”或“用户”。相反，您使用 Tower 的 RBAC 系统来授予所有权、审计员或使用角色。
系统管理员和组织管理员可以在他们具有管理权限的组织中创建清单和凭据。
无论是编辑清单还是凭据，系统管理员和组织管理员都可以指定一个或多个用户/团队（来自该组织的成员）以授予该清单或凭据的使用功能。
系统管理员和组织管理员可以指定一个或多个用户/团队（来自该组织的成员）具有更新（动态或手动）清单的功能。管理员还可以对清单执行临时命令。
27.2.2.5. 编辑作业模板¶
系统管理员、组织管理员和项目管理员可以在他们具有管理权限的项目中创建和修改该项目的新作业模板。
编辑作业模板时，管理员（Tower、组织和项目）可以在组织中选择他们具有使用功能的清单和凭据，或者他们可以保留这些字段为空白，以便在运行时选择它们。
此外，他们可以指定一个或多个用户/团队（来自该项目的成员）对该作业模板具有执行功能。执行功能有效，无论用户/团队对作业模板中指定的清单或凭据授予了哪些明确功能。
27.2.2.6. 用户视图¶
用户可以：
查看他们所属的任何组织或项目。
创建仅属于他们自己的凭据对象。
查看和执行他们被授予执行功能的任何作业模板。
如果用户被授予执行功能的作业模板未指定清单或凭据，则用户将在运行时被提示在他们拥有或被授予使用功能的组织的清单和凭据中进行选择。
作为作业模板管理员的用户可以对作业模板进行更改；但是，要更改作业模板中使用的清单、项目、剧本或凭据，用户还必须对当前正在使用或正在设置的项目和清单具有“使用”角色。
27.2.3. 角色¶
如本文档前面所述，现在通过角色处理授予使用、读取或写入凭据的所有访问权限，并且角色是为资源定义的。
27.2.3.1. 内置角色¶
下表列出了 RBAC 系统角色以及关于该角色在 Tower 中的权限定义的简要说明。
系统角色 |
它可以做什么 |
|---|---|
系统管理员 - 系统范围的单例 |
管理系统的所有方面 |
系统审计员 - 系统范围的单例 |
查看系统的全部方面 |
临时角色 - 清单 |
在清单上运行临时命令 |
管理员角色 - 组织、团队、清单、项目、作业模板 |
管理定义的组织、团队、清单、项目或作业模板的所有方面 |
审计员角色 - 全部 |
查看定义的组织、项目、清单或作业模板的所有方面 |
执行角色 - 作业模板 |
运行分配的作业模板 |
成员角色 - 组织、团队 |
用户是已定义组织或团队的成员 |
读取角色 - 组织、团队、库存、项目、作业模板 |
查看已定义组织、团队、库存、项目或作业模板的各个方面 |
更新角色 - 项目 |
从配置的源代码管理系统更新项目 |
更新角色 - 库存 |
使用云源更新系统更新库存 |
所有者角色 - 凭据 |
拥有和管理此凭据的所有方面 |
使用角色 - 凭据、库存、项目 |
在作业模板中使用凭据、库存或项目 |
单例角色是一种特殊角色，它授予系统范围的权限。 Ansible Tower 目前提供两个内置单例角色，但目前不支持创建或自定义单例角色。
27.2.3.2. 常见团队角色 - “角色”¶
Tower 支持人员通常致力于确保 Tower 的可用性，并以一种平衡可支持性和易用性的方式进行管理。 通常，Ansible Tower 支持人员会将“组织所有者/管理员”分配给用户，以允许他们创建新的组织并添加其团队的成员，以便他们获得相应的访问权限。 这可以最大限度地减少对个人的支持，更多地专注于维护服务的正常运行时间并协助使用 Ansible Tower 的用户。
以下是 Tower 组织管理的一些常见角色
系统角色
(适用于组织)
|
普通用户
角色
|
描述
|
所有者
|
团队负责人 -
技术负责人
|
该用户有权控制其组织中其他用户的访问权限。
他们可以添加/删除用户并授予用户对项目、库存和作业模板的特定访问权限。
该用户还具有创建/删除/修改组织的项目、
模板、库存、团队和凭据的任何方面的权限。
|
审计员
|
安全工程师 -
项目经理
|
此帐户可以以只读模式查看组织的所有方面。
这可能适合检查和维护合规性的用户。
这也可能是管理或
将作业数据从 Ansible Tower 发送到其他数据收集器的服务帐户的理想角色。
|
成员 -
团队
|
所有其他用户
|
默认情况下，这些用户作为组织成员不会获得对组织任何方面的访问权限。
为了授予他们访问权限，相应的组织所有者需要
将他们添加到相应的团队，并授予他们对组织的项目、库存和作业模板的每个组件的管理员、执行、使用、更新、临时
权限。
|
成员 -
团队“所有者”
|
高级用户 -
首席开发人员
|
组织所有者可以通过团队界面，在任何组件上提供“管理员”权限，
包括他们的组织的项目、库存和作业模板。 这些用户能够
修改和使用已授予访问权限的相应组件。
|
成员 -
团队“执行”
|
开发人员 -
工程师
|
这将是最常见的权限，它允许组织成员执行
作业模板并读取特定组件的权限。 此权限适用于模板。
|
成员 -
团队“使用”
|
开发人员 -
工程师
|
此权限适用于组织的凭据、库存和项目。
此权限允许用户在他们的作业模板中使用相应的组件。
|
成员 -
团队“更新”
|
开发人员 -
工程师
|
此权限适用于项目。 允许用户对项目运行 SCM 更新。
|
27.3. 角色的功能：编辑和创建¶
Ansible Tower 3.3 中引入了新的组织“资源角色”功能，它们特定于某些资源类型，例如工作流。 成为此类角色的成员通常会提供两种类型的权限，以工作流为例，如果用户被授予组织“Default”的“工作流管理员角色”
此用户可以在组织“Default”中创建新的工作流
用户可以编辑“Default”组织中的所有工作流
唯一例外是作业模板，拥有该角色与创建权限无关（更多详细信息请参见其自身部分）。
27.3.1. 资源角色与组织成员角色的独立性¶
特定于资源的组织角色独立于组织角色管理员和成员。 拥有“Default”组织的“工作流管理员角色”不会允许用户查看组织中的所有用户，但拥有“Default”组织的“成员”角色则会。 这两种类型的角色是独立分配的。
27.3.1.1. 编辑作业模板所需的权限¶
用户只需拥有作业模板管理员角色即可编辑不会影响作业运行的字段（非敏感字段）。 但是，要编辑会影响作业模板中作业运行的字段，用户需要以下权限
对作业模板的管理员角色
对相关项目的使用角色
对相关库存的使用角色
引入了“组织作业模板管理员”角色，但如果用户没有对作业模板使用的项目/库存的“使用”角色，仅拥有此角色不足以编辑组织内的作业模板。
为了将完整的作业模板控制权（在组织内）委派给用户或团队，您需要授予团队或用户所有 3 个组织级角色
作业模板管理员
项目管理员
库存管理员
这将确保用户（或拥有这些角色的团队中的所有用户）能够完全访问修改组织中的作业模板。 如果作业模板使用来自另一个组织的库存或项目，拥有这些组织角色的用户可能仍然没有权限修改该作业模板。 为了清楚地管理权限，最佳实践是不混合来自不同组织的项目/库存。
27.3.1.2. RBAC 权限¶
每个角色都应该有一个内容对象，例如，组织管理员角色有一个组织的内容对象。 要委派角色，您需要对内容对象拥有管理员权限，但也有一些例外情况，这些例外情况会使您能够重置用户的密码。
父级是组织。
允许是此新权限将明确允许的内容。
范围是将在此新角色上创建的父级资源。 示例：Organization.project_create_role。
假设资源的创建者应获得该资源的管理员角色。 如果有资源创建不也意味着资源管理的任何实例，它们将被明确指出。
以下是与每种管理员类型相关的规则
项目管理员
允许：创建、读取、更新、删除任何项目
范围：组织
用户界面：项目添加屏幕 - 组织
库存管理员
父级：组织管理员
允许：创建、读取、更新、删除任何库存
范围：组织
用户界面：库存添加屏幕 - 组织
注意
与使用角色一样，如果您为用户授予项目管理员和库存管理员权限，则允许他们为您的组织创建作业模板（而不是工作流）。
凭据管理员
父级：组织管理员
允许：创建、读取、更新、删除共享凭据
范围：组织
用户界面：凭据添加屏幕 - 组织
通知管理员
父级：组织管理员
允许：分配通知
范围：组织
工作流管理员
父级：组织管理员
允许：创建工作流
范围：组织
组织执行
父级：组织管理员
允许：执行 JT 和 WFJTs
范围：组织
以下是一个示例场景，展示了一个组织及其角色，以及每个角色可以访问的资源
