31. 安全性¶
以下部分将帮助您了解 automation controller 如何处理并控制文件系统的安全性。
All playbooks are executed via the awx file system user. For running jobs, automation controller offers job isolation via the use of Linux containers. This projection ensures jobs can only access playbooks, roles, and data from the Project directory for that job template.
为了确保凭证安全性，用户可以选择上传锁定的 SSH 密钥，并将解锁密码设置为“询问”。您也可以选择让系统提示他们输入 SSH 凭证或 sudo 密码，而不是让系统将其存储在数据库中。
31.1. Playbook 访问和信息共享¶
Automation controller's use of automation execution environments and Linux containers prevents playbooks from reading files outside of their project directory.
By default, the only data exposed to the ansible-playbook process inside the container is the current project being used.
You can customize this and expose additional directories from the host into the container, using the Configure Tower screen. Refer the next section, Isolation functionality and variables for more information.
31.1.1. Isolation functionality and variables¶
Automation controller uses container technology to isolate jobs from each other. By default, only the current project is exposed to the container running a job template.
You may find that you need to customize your playbook runs to expose additional directories. To fine tune your usage of job isolation, there are certain variables that can be set.
By default, automation controller will use the system's tmp directory (/tmp by default) as its staging area. This can be changed in the Job Execution Path field of the Jobs settings screen, or in the REST API at /api/v2/settings/jobs:
AWX_ISOLATION_BASE_PATH = "/opt/tmp"
If there are any additional directories that should specifically be exposed from the host to the container that playbooks run in, you can specify those in the Paths to Expose to Isolated Jobs
field of the Jobs setting scren, or in the REST API at /api/v2/settings/jobs:
AWX_ISOLATION_SHOW_PATHS = ['/list/of/', '/paths']
注解
The primary file you may want to add to
AWX_ISOLATION_SHOW_PATHSis/var/lib/awx/.ssh, if your playbooks need to use keys or settings defined there.
以上字段可在 Jobs Settings 窗口中找到：
31.2. 基于角色的访问控制¶
基于角色的访问控制 (RBAC) 内置在 Tower 中，并允许 Tower 管理员委托对服务器清单、机构等的访问权限。管理员也可以集中管理各种凭证，让最终用户可以利用所需的 secret，同时无需向最终用户公开该 secret。借助 RBAC 控制，Tower 可帮助您提高安全性并简化管理。
可以将 RBAC 想象为角色，它们精确定义了，对于一个特定的功能，谁或什么可以被看到、更改或删除一个"对象"。RBAC 是向用户或团队授予角色的方法。
您应该熟悉有关 Tower 的 RBAC 设计的一些主要概念，包括角色、资源和用户。用户可以成为角色的成员，获得对与该角色关联的资源或与“子代”角色关联的任何资源的某些访问权限。
角色基本上是权限的集合。用户可以通过为其分配的角色或通过从角色层次结构继承的角色获得对这些权限和 Tower 资源的访问。
角色将一组权限与一组用户相关联。所有权限都来自于角色中的成员资格。用户只通过为其分配的角色或通过从角色层次结构继承的角色来获得权限。角色的所有成员均具有授予该角色的所有权限。在一个机构中，角色相对稳定，而用户和权限不仅数量众多，而且可能快速变化。用户可以具有多个角色。
31.2.1. 角色层次结构和访问权限继承¶
假设您有一个名为“SomeCompany”的机构，并想向“Josie”和“Carter”两个人授予访问权限来管理与该机构相关的所有设置。您应该让两个人都成为该机构的 admin_role 成员。
通常，系统会有很多角色，并且您会希望某些角色包含其他角色的所有权限。例如，您可能希望系统管理员可以访问机构管理员可访问的所有内容，而机构管理员又可以访问项目管理员可访问的所有内容，等等。
这个概念被称为“角色层次关系”：
父角色获取赋予任何子角色的所有权限
角色的成员可以自动获取他们所属角色以及任何子角色的所有权限。
角色层次结构的代表是允许角色具有“父角色”。角色具有的任何权限都会被隐式授予任何父角色（或那些父角色的父级等等）。
通常，系统会有很多角色，并且您会希望某些角色包含其他角色的所有权限。例如，您可能希望系统管理员可以访问机构管理员可访问的所有内容，而机构管理员又可以访问项目管理员可访问的所有内容，等等。我们将这个概念称为“角色层次结构”，其代表是允许角色具有“父角色”。角色具有的任何权限都会被隐式授予任何父角色（或那些父角色的父级等等）。当然角色可以具有多个父角色，权限会被隐式授予所有父角色。
RBAC 控制还可让您明确允许用户和用户团队针对特定主机组运行 playbook。用户和团队仅限运行他们被授予了权限的 playbook 和主机组。此外，在 Tower 中，您可以创建或导入所需数量的用户和团队，既可以手动创建用户和团队，也可以从 LDAP 或 Active Directory 导入它们。
最简单的方式是将 RBAC 想成是谁或什么可以看到、更改或删除正在为其确定特定权限的“对象”。
31.2.2. 应用 RBAC¶
以下部分论述了如何在您的环境中应用 Tower 的 RBAC 系统。
31.2.2.1. 编辑用户¶
编辑用户时，Tower 系统管理员可指定用户为*系统管理员*（也称超级用户）或*系统审核员*。
系统管理员会隐式地继承 Tower 环境中所有对象的所有权限（读/写/执行）。
系统审核员会隐式地继承 Tower 环境中所有对象的只读权限。
31.2.2.2. 编辑机构¶
编辑机构时，系统管理员可指定以下角色：
一个或多个用户作为机构管理员
一个或多个用户作为机构审核员
以及一个或多个用户（或团队）作为机构成员
属于某个机构的成员的用户/团队可以查看其机构管理员。
作为机构管理员的用户隐式继承了该 Tower 机构中所有对象的所有权限。
作为机构审核员的用户隐式继承了该 Tower 机构中所有对象的只读权限。
31.2.2.3. 编辑机构中的项目¶
在编辑机构中的项目时，该机构的系统管理员和机构管理员可指定：
一个或多个作为项目管理员的用户/团队
一个或多个作为项目成员的用户/团队
以及可以从 SCM 更新项目的一个或多个用户/团队，均来自属于该机构成员的用户/团队。
作为项目成员的用户可以查看其项目管理员。
项目管理员隐式继承了从 SCM 更新项目的权限。
管理员也可以指定一个或多个可在作业模板中使用该项目的用户/团队（来自属于该项目成员的用户/团队）。
31.2.2.4. 在机构中创建清单和凭证¶
为使用、读取或写入凭证授予的所有访问权限现在都通过角色处理。您不再为凭证设置“团队”或“用户”。取而代之，您将使用 Tower 的 RBAC 系统授予所有权、审核者或使用角色。
系统管理员和机构管理员可根据其管理权限在机构内部创建清单和凭证。
无论是编辑清单还是凭证，系统管理员和机构管理员都可以指定一个或多个用户/团队（来自属于该机构成员的用户/团队）以授予该清单或凭证的使用权限。
系统管理员和机构管理员可指定一个或多个用户/团队（来自属于该机构成员的用户/团队），使它们具有（动态或手动）更新清单的权限。管理员也可以为清单执行临时命令。
31.2.2.5. 编辑作业模板¶
系统管理员、机构管理员和项目管理员可以根据其管理权限在一个项目中为该项目创建并修改新的作业模板。
在编辑作业模板时，管理员（Tower、机构及项目）可在他们具有使用权限的机构中的清单和凭证中进行选择，或者他们可以将这些字段留空以便在运行时进行选择。
另外，他们还可指定具有该作业模板执行权限的一个或多个用户/团队（来自属于该项目成员的用户/团队）。无论针对作业模板中指定的清单或凭证为用户/团队授予了何种显式权限，其执行权限都有效。
31.2.2.6. 用户视图¶
用户可以：
查看他们所属的任何机构或项目
创建只属于他们自己的凭证对象
查看并执行他们被授予执行权限的任何作业模板
如果某个用户获得执行功能的作业模板没有指定清单或凭证，则会在运行时提示用户在他们拥有的机构中的清单和凭证中选择，或者获得使用功能。
作为作业模板管理员的用户可以对作业模板进行更改；但是，若要更改作业模板中使用的清单、项目、playbook 或凭证，用户还必须具有目前正在使用或正在设置的项目和清单的“使用”角色。
31.2.3. 角色¶
如本文档前面所述，为使用、读取或写入凭证授予的所有访问权限现在都通过角色处理，角色是为资源定义的。
31.2.3.1. 内置角色¶
下表列出了 RBAC 系统角色以及如何根据 Tower 中的权限定义角色的要描述。
系统角色 |
它可以执行什么操作 |
|---|---|
系统管理员 (System Administrator) - 系统范围单例 |
管理系统的所有方面 |
系统审核员 (System Auditor) - 系统范围单例 |
查看系统的所有方面 |
临时角色 (Ad Hoc Role) - 清单 |
对清单运行临时命令 |
管理员角色 (Admin Role) - 机构、团队、清单、项目、作业模板 |
管理定义的机构、团队、清单、项目或作业模板的所有方面 |
审核员角色 (Auditor Role) - 所有 |
查看定义的机构、项目、清单或作业模板的所有方面 |
执行角色 (Execute Role) - 作业模板 |
运行分配的作业模板 |
成员角色 (Member Role) - 机构、团队 |
用户是定义的机构或团队的成员 |
读取角色 (Read Role) - 机构、团队、清单、项目、作业模板 |
查看定义的机构、团队、清单、项目或作业模板的所有方面 |
更新角色 (Update Role) - 项目 |
从配置的源控制管理系统更新项目 |
更新角色 (Update Role) - 清单 |
使用云源更新系统更新清单 |
所有者角色 (Owner Role) - 凭证 |
拥有并管理此凭证的所有方面 |
使用角色 (Use Role) - 凭证、清单、项目 |
在作业模板中使用凭证、清单或项目 |
单例角色 (Singleton Role) 是一个授予系统范围权限的特殊角色。automation controller 当前提供两个内置的单例角色，但目前不支持创建或自定义单例角色。
31.2.3.2. 常见团队角色 -“Personas”¶
Tower 支持人员通常会努力确保 Tower 可用，并以一种平衡可支持性和用户易用性的方式进行管理。通常，Ansible Tower 支持人员会为用户分配“机构所有者/管理员”，以便他们能够创建一个新的机构，并为其团队中的成员添加所需的相应访问权限。这样可尽量减小支持人员的数量，并使他们更多地专注于维护服务的正常运行时间，以及为使用 Ansible Tower 的用户提供协助。
以下是 Tower 机构管理的一些常见角色：
系统角色
（针对机构）
|
常见用户
角色
|
描述
|
所有者 (Owner)
|
团队领导 -
技术领导
|
这个用户可以控制其机构中其他用户的访问权限。
他们可以添加/删除并授予用户对项目、清单和作业模板的特定访问权限。
此用户也可以创建/删除/修改机构项目、
模板、清单、团队和凭证的任何方面。
|
审核员 (Auditor)
|
安全工程师 -
项目经理
|
这个帐户可以在只读模式下查看机构的所有方面。
这可能很适合负责签入和维护合规性的用户。
这个角色也可能很适合负责管理
Ansible Tower 中的作业数据或者将其发送到其他数据收集器的服务帐户。
|
成员 -
团队（team）
|
所有其他用户
|
默认情况下，这些用户作为机构成员不会获得对机构任何方面的任何访问权限
。要向他们授予访问权限，相应的机构所有者需要
将他们添加其各自团队中，并为他们授予
对机构项目、清单和作业模板的每个组件的管理员、执行、使用、更新、临时权限。
|
成员 -
团队“所有者”
|
超级用户 -
主要开发人员
|
机构所有者可以通过团队界面提供对其机构任何组件（包括项目、清单和作业模板）
的“管理”权限。这些用户可以
修改并利用其获得了访问权限的相应组件。
|
成员 -
团队“执行”
|
开发人员 -
工程师
|
这会是最常用的角色，可为机构成员授予执行
作业模板的权限以及对特定组件的读取权限。此权限适用于模板。
|
成员 -
团队“使用”
|
开发人员 -
工程师
|
此权限适用于机构的凭证、清单和项目。
此权限为用户授予对其作业模板中相应组件的权限。
|
成员 -
团队“更新”
|
开发人员 -
工程师
|
此权限适用于项目。允许用户对项目运行 SCM 更新。
|
31.3. 角色的功能：编辑和创建¶
automation controller 3.3 引入了新的机构“资源角色”功能，它们特定于某种资源类型，例如工作流。成为这种角色的成员通常会提供两种类型的权限，对于工作流的情况，会为用户授予机构“Default”的“workflow admin role”：
此用户可以在机构“Default”中创建新的工作流
用户可以编辑“Default”机构中的所有工作流
一个例外是在作业模板中，拥有该角色与创建权限无关（相关部分介绍了更多详情）。
31.3.1. 资源角色和机构成员资格角色的独立性¶
资源特定的机构角色与机构的管理员和成员角色无关。拥有“Default”机构的“workflow admin role”不允许用户查看该机构中的所有用户，但在“Default”机构中拥有“member”角色则允许。这两个类型的角色是相互独立委托的。
31.3.1.1. 编辑作业模板所需的权限¶
用户只凭作业模板管理员角色便可以编辑不会影响作业运行的字段（非敏感字段）。但是，要编辑影响作业模板中的作业运行的字段，用户需要以下权限：
作业模板的 admin 角色
相关项目的 use 角色
相关清单的 use 角色
之前引入了一个“organization job template admin”角色，但如果用户对作业模板使用的项目/清单没有使用角色，则此角色本身不足以编辑该机构内的作业模板。
为了将（某个机构中的）*full* 作业模板控制委托给用户或团队，您需要授予该团队或用户所有 3 个机构级别角色：
任务模板管理员
项目管理员
清单管理员
这将确保用户（或属于具有这些角色的团队成员的所有用户）具有修改机构中的作业模板的完全访问权限。如果作业模板使用其他机构中的清单或项目，则具有这些机构角色的用户可能仍无权修改该作业模板。为了清楚地管理权限，最好不要混用来自不同机构的项目/清单。
31.3.1.2. RBAC 权限¶
每个角色都应该有一个内容对象，例如，机构管理员角色的内容对象为机构。若要委托角色，您需要对内容对象具有管理员权限，但有些例外情况导致您需要能够重置用户的密码。
Parent 是机构。
Allow 是这个新权限明确允许执行的操作。
Scope 是创建这个新角色时所基于的父资源。例如：Organization.project_create_role。
目前的假定是资源的创建者应被赋予该资源的管理员角色。在有些情况下，如果资源创建并未同时隐含资源管理，则将显式地调出它们。
下面是与每个管理员类型关联的规则：
项目管理员
Allow：创建、读取、更新、删除任何项目
Scope：机构
User Interface：项目添加屏幕 - 机构
清单管理员
Parent：机构管理员
Allow：创建、读取、更新、删除任何清单
Scope：机构
User Interface：清单添加屏幕 - 机构
注解
和 Use 角色一样，如果您授予用户“项目管理员”和“清单管理员”，它允许他们为您的机构创建作业模板（而非工作流）。
凭证管理员
Parent：机构管理员
Allow：创建、读取、更新、删除共享凭证
Scope：机构
User Interface：凭证添加屏幕 - 机构
通知管理员
Parent：机构管理员
Allow：通知的分配
Scope：机构
工作流管理员
Parent：机构管理员
Allow：创建工作流
Scope：机构
机构执行
Parent：机构管理员
Allow：执行 JT 和 WFJT
Scope：机构
以下是一个示例场景，显示了一个机构及其角色，以及每个角色可以访问哪些资源：
