31. 安全性¶
以下部分将帮助您了解 automation controller 如何处理并控制文件系统的安全性。
所有 playbook 都是通过 awx 文件系统用户执行的。对于运行的作业，automation controller 通过使用 Linux 容器提供作业隔离。此预测可确保作业只能访问该作业模板的项目目录中的 playbook、角色和数据。
为了确保凭证安全性，用户可以选择上传锁定的 SSH 密钥，并将解锁密码设置为“询问”。您也可以选择让系统提示他们输入 SSH 凭证或 sudo 密码，而不是让系统将其存储在数据库中。
31.1. Playbook 访问和信息共享¶
|At|使用自动化执行环境和 Linux 容器可防止 playbook 读取其项目目录之外的文件。
默认情况下，公开给容器内 ansible-playbook 进程的唯一数据是当前使用的项目。
You can customize this in the Job Settings and expose additional directories from the host into the container. Refer the next section, Isolation functionality and variables for more information.
31.1.1. Isolation functionality and variables¶
Automation controller 使用容器技术将作业相互隔离。默认情况下，只有当前项目公开给运行作业模板的容器。
您可能会发现，您需要自定义 playbook 运行以公开其他目录。要微调作业隔离的使用，可以设置某些变量。
默认情况下，automation controller 将使用系统的 tmp 目录（默认为``/tmp`` ）作为其临时区域。这可以在作业设置屏幕的 Job Execution Path 字段中进行修改，也可以在位于 /api/v2/settings/jobs 的 REST API 中更改：
AWX_ISOLATION_BASE_PATH = "/opt/tmp"
The host trusted cert store is exposed to execution environments by default:
AWX_ISOLATION_SHOW_PATHS = [
'/etc/pki/ca-trust:/etc/pki/ca-trust:O',
'/usr/share/pki:/usr/share/pki:O',
]
如果应该从主机向运行 playbook 的容器公开任何其他目录，您可以在 Jobs 设置 scren 的 Paths to Expose to Isolated Jobs 字段中指定，或者在位于 /api/v2/settings/jobs 的 REST API 中指定它们：
AWX_ISOLATION_SHOW_PATHS = ['/list/of/', '/paths']
注解
如果 playbook 需要使用在
/var/lib/awx/.ssh中定义的密钥或设置，则需要把它做为主文件添加到AWX_ISOLATION_SHOW_PATHS。
以上字段可在 Jobs Settings 窗口中找到：
31.2. 基于角色的访问控制¶
Role-Based Access Controls (RBAC) are built into automation controller and allow administrators to delegate access to server inventories, organizations, and more. Administrators can also centralize the management of various credentials, allowing end users to leverage a needed secret without ever exposing that secret to the end user. RBAC controls allow the controller to help you increase security and streamline management.
可以将 RBAC 想象为角色，它们精确定义了，对于一个特定的功能，谁或什么可以被看到、更改或删除一个"对象"。RBAC 是向用户或团队授予角色的方法。
There are a few main concepts that you should become familiar with regarding automation controller's RBAC design--roles, resources, and users. Users can be members of a role, which gives them certain access to any resources associated with that role, or any resources associated with "descendant" roles.
A role is essentially a collection of capabilities. Users are granted access to these capabilities and the controller's resources through the roles to which they are assigned or through roles inherited through the role hierarchy.
角色将一组权限与一组用户相关联。所有权限都来自于角色中的成员资格。用户只通过为其分配的角色或通过从角色层次结构继承的角色来获得权限。角色的所有成员均具有授予该角色的所有权限。在一个机构中，角色相对稳定，而用户和权限不仅数量众多，而且可能快速变化。用户可以具有多个角色。
31.2.1. 角色层次结构和访问权限继承¶
假设您有一个名为“SomeCompany”的机构，并想向“Josie”和“Carter”两个人授予访问权限来管理与该机构相关的所有设置。您应该让两个人都成为该机构的 admin_role 成员。
通常，系统会有很多角色，并且您会希望某些角色包含其他角色的所有权限。例如，您可能希望系统管理员可以访问机构管理员可访问的所有内容，而机构管理员又可以访问项目管理员可访问的所有内容，等等。
这个概念被称为“角色层次关系”：
父角色获取赋予任何子角色的所有权限
角色的成员可以自动获取他们所属角色以及任何子角色的所有权限。
角色层次结构的代表是允许角色具有“父角色”。角色具有的任何权限都会被隐式授予任何父角色（或那些父角色的父级等等）。
通常，系统会有很多角色，并且您会希望某些角色包含其他角色的所有权限。例如，您可能希望系统管理员可以访问机构管理员可访问的所有内容，而机构管理员又可以访问项目管理员可访问的所有内容，等等。我们将这个概念称为“角色层次结构”，其代表是允许角色具有“父角色”。角色具有的任何权限都会被隐式授予任何父角色（或那些父角色的父级等等）。当然角色可以具有多个父角色，权限会被隐式授予所有父角色。
RBAC controls also give you the capability to explicitly permit User and Teams of Users to run playbooks against certain sets of hosts. Users and teams are restricted to just the sets of playbooks and hosts to which they are granted capabilities. And, with automation controller, you can create or import as many Users and Teams as you require--create users and teams manually or import them from LDAP or Active Directory.
最简单的方式是将 RBAC 想成是谁或什么可以看到、更改或删除正在为其确定特定权限的“对象”。
31.2.2. 应用 RBAC¶
The following sections cover how to apply automation controller's RBAC system in your environment.
31.2.2.1. 编辑用户¶
When editing a user, a automation controller system administrator may specify the user as being either a System Administrator (also referred to as the Superuser) or a System Auditor.
System administrators implicitly inherit all capabilities for all objects (read/write/execute) within the automation controller environment.
System Auditors implicitly inherit the read-only capability for all objects within the automation controller environment.
31.2.2.2. 编辑机构¶
编辑机构时，系统管理员可指定以下角色：
一个或多个用户作为机构管理员
一个或多个用户作为机构审核员
以及一个或多个用户（或团队）作为机构成员
属于某个机构的成员的用户/团队可以查看其机构管理员。
Users who are organization administrators implicitly inherit all capabilities for all objects within that automation controller organization.
Users who are organization auditors implicitly inherit the read-only capability for all objects within that automation controller organization.
31.2.2.3. 编辑机构中的项目¶
在编辑机构中的项目时，该机构的系统管理员和机构管理员可指定：
一个或多个作为项目管理员的用户/团队
一个或多个作为项目成员的用户/团队
以及可以从 SCM 更新项目的一个或多个用户/团队，均来自属于该机构成员的用户/团队。
作为项目成员的用户可以查看其项目管理员。
项目管理员隐式继承了从 SCM 更新项目的权限。
管理员也可以指定一个或多个可在作业模板中使用该项目的用户/团队（来自属于该项目成员的用户/团队）。
31.2.2.4. 在机构中创建清单和凭证¶
All access that is granted to use, read, or write credentials is now handled through roles. You no longer set the “team” or “user” for a credential. Instead, you use automation controller's RBAC system to grant ownership, auditor, or usage roles.
系统管理员和机构管理员可根据其管理权限在机构内部创建清单和凭证。
无论是编辑清单还是凭证，系统管理员和机构管理员都可以指定一个或多个用户/团队（来自属于该机构成员的用户/团队）以授予该清单或凭证的使用权限。
系统管理员和机构管理员可指定一个或多个用户/团队（来自属于该机构成员的用户/团队），使它们具有（动态或手动）更新清单的权限。管理员也可以为清单执行临时命令。
31.2.2.5. 编辑作业模板¶
系统管理员、机构管理员和项目管理员可以根据其管理权限在一个项目中为该项目创建并修改新的作业模板。
When editing a job template, administrators (automation controller, organization, and project) can select among the inventory and credentials in the organization for which they have usage capabilities or they may leave those fields blank so that they will be selected at runtime.
另外，他们还可指定具有该作业模板执行权限的一个或多个用户/团队（来自属于该项目成员的用户/团队）。无论针对作业模板中指定的清单或凭证为用户/团队授予了何种显式权限，其执行权限都有效。
31.2.2.6. 用户视图¶
用户可以：
查看他们所属的任何机构或项目
创建只属于他们自己的凭证对象
查看并执行他们被授予执行权限的任何作业模板
如果某个用户获得执行功能的作业模板没有指定清单或凭证，则会在运行时提示用户在他们拥有的机构中的清单和凭证中选择，或者获得使用功能。
作为作业模板管理员的用户可以对作业模板进行更改；但是，若要更改作业模板中使用的清单、项目、playbook 或凭证，用户还必须具有目前正在使用或正在设置的项目和清单的“使用”角色。
31.2.3. 角色¶
如本文档前面所述，为使用、读取或写入凭证授予的所有访问权限现在都通过角色处理，角色是为资源定义的。
31.2.3.1. 内置角色¶
The following table lists the RBAC system roles and a brief description of the how that role is defined with regard to privileges in automation controller.
系统角色 |
它可以执行什么操作 |
|---|---|
系统管理员 (System Administrator) - 系统范围单例 |
管理系统的所有方面 |
系统审核员 (System Auditor) - 系统范围单例 |
查看系统的所有方面 |
临时角色 (Ad Hoc Role) - 清单 |
对清单运行临时命令 |
管理员角色 (Admin Role) - 机构、团队、清单、项目、作业模板 |
管理定义的机构、团队、清单、项目或作业模板的所有方面 |
审核员角色 (Auditor Role) - 所有 |
查看定义的机构、项目、清单或作业模板的所有方面 |
执行角色 (Execute Role) - 作业模板 |
运行分配的作业模板 |
成员角色 (Member Role) - 机构、团队 |
Manages all of the settings associated with that Organization or Team |
读取角色 (Read Role) - 机构、团队、清单、项目、作业模板 |
查看定义的机构、团队、清单、项目或作业模板的所有方面 |
更新角色 (Update Role) - 项目 |
从配置的源控制管理系统更新项目 |
更新角色 (Update Role) - 清单 |
使用云源更新系统更新清单 |
所有者角色 (Owner Role) - 凭证 |
拥有并管理此凭证的所有方面 |
使用角色 (Use Role) - 凭证、清单、项目 |
在作业模板中使用凭证、清单或项目 |
单例角色 (Singleton Role) 是一个授予系统范围权限的特殊角色。automation controller 当前提供两个内置的单例角色，但目前不支持创建或自定义单例角色。
31.2.3.2. 常见团队角色 -“Personas”¶
Automation controller support personnel typically works on ensuring that the controller is available and manages it a way to balance supportability and ease-of-use for users. Often, automation controller support will assign “Organization Owner/Admin” to users in order to allow them to create a new Organization and add members from their team the respective access needed. This minimizes supporting individuals and focuses more on maintaining uptime of the service and assisting users who are using automation controller.
Below are some common roles managed by the automation controller Organization:
系统角色
（针对机构）
|
常见用户
角色
|
描述
|
所有者 (Owner)
|
团队领导 -
技术领导
|
这个用户可以控制其机构中其他用户的访问权限。
他们可以添加/删除并授予用户对项目、清单和作业模板的特定访问权限。
此用户也可以创建/删除/修改机构项目、
模板、清单、团队和凭证的任何方面。
|
审核员 (Auditor)
|
安全工程师 -
项目经理
|
这个帐户可以在只读模式下查看机构的所有方面。
这可能很适合负责签入和维护合规性的用户。
这个角色也可能很适合负责管理
ships job data from automation controller to some other data collector.
|
成员 -
团队（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：机构
以下是一个示例场景，显示了一个机构及其角色，以及每个角色可以访问哪些资源：
