Red Hat Ansible Automation Platform 强化指南

Ansible Automation Platform 是一个模块化平台，包括自动化控制器、自动化中心、Event-Driven Ansible 控制器和 Insights for Ansible Automation Platform。

对于具有可用性要求的大型生产环境，本指南建议使用 Red Hat Enterprise Linux 上的 Red Hat Ansible Automation Platform 参考架构 文档中的说明部署本指南第 2.1 节中所述的组件。虽然某些变化可能对您的特定技术要求有意义，但遵循参考架构会导致受支持的生产环境就绪环境。

图 2.1. 参考架构概述

event-Driven Ansible 是 Ansible Automation Platform 2.4 的一个新功能，在图 1 中详述的参考架构时不可用：最初编写了参考架构概述。目前，支持的配置是单个自动化控制器、单一自动化中心和带有外部（安装程序管理的）数据库的 Ansible 控制器节点。对于对 Event-Driven Ansible 感兴趣的机构，建议根据 Ansible Automation Platform 安装指南中的配置 来安装。当需要 Event-Driven Ansible 特定强化配置时，本文档提供了额外的说明。

对于可能不需要完整参考架构的较小的生产环境，本指南建议使用专用 PostgreSQL 数据库服务器部署 Ansible Automation Platform，无论是由安装程序管理还是在外部提供。

Ansible Automation Platform 需要访问网络以集成外部辅助服务，并管理目标环境和资源，如主机、其他网络设备、应用程序、云服务。Ansible Automation Platform 计划指南中的网络 端口和协议 部分描述了 Ansible Automation Platform 组件如何与网络进行交互，以及使用哪些端口和协议，如下图所示：

图 2.2. Ansible Automation Platform 网络端口和协议

在规划与 Ansible Automation Platform 相关的防火墙或云网络安全组配置时，请参阅 Ansible Automation Platform 规划指南中的网络 端口和协议 部分，以了解防火墙或安全组中需要打开哪些网络端口。

有关使用负载均衡器的更多信息，以及与 Ansible Automation Platform 兼容的服务的传出流量要求。请参阅红帽知识库文章 Ansible Automation Platform 2 服务防火墙中需要打开哪些端口？对于互联网连接的系统，本文档还定义了 Ansible Automation Platform 可以配置为使用的服务的传出流量要求，如 Ansible Automation hub、Red Hat Insights for Red Hat Ansible Automation Platform、Ansible Galaxy、registry.redhat.io 容器镜像 registry 等。

对于互联网连接的系统，本文档还定义了 Ansible Automation Platform 可以配置为使用的服务的传出流量要求，如 Red Hat Automation hub、Insights for Ansible Automation Platform、Ansible Galaxy、registry.redhat.io 容器镜像 registry 等。

将 Ansible Automation Platform 组件使用的端口的访问限制为受保护的网络和客户端。强烈推荐以下限制：

在计划访问 Ansible Automation Platform 用户界面或 API 时，请注意用户帐户可以是本地的，也可以映射到外部身份验证源，如 LDAP。本指南建议尽可能，所有主用户帐户都应映射到外部身份验证源。使用外部帐户源可消除在此上下文中使用权限时的错误源，并尽可能减少维护专门在 Ansible Automation Platform 内一组完整的用户的时间。这包括分配给个人个人以及非个人实体的帐户，如用于外部应用程序集成的服务帐户。保留任何本地管理员帐户，如默认的"admin"帐户，用于紧急访问或"breakNote"场景，其中外部身份验证机制不可用。

对于运行 Ansible Automation Platform 服务的 Red Hat Enterprise Linux 服务器上的用户帐户，请遵循您的机构策略，以确定单个用户帐户是否是本地或来自外部身份验证源。只有有效需要对 Ansible Automation Platform 组件本身执行维护任务的用户才应被授予对底层 Red Hat Enterprise Linux 服务器的访问权限，因为服务器将具有包含加密密钥和服务密码的配置文件。由于这些个人必须具有维护 Ansible Automation Platform 服务的特权访问权限，因此尽量减少对底层 Red Hat Enterprise Linux 服务器的访问至关重要。不要向不受信任的用户授予对 root 帐户或本地 Ansible Automation Platform 服务帐户(awx、pulp、postgres)的 sudo 访问权限。

自动化控制器使用凭证向作业验证对作业的请求，与清单源同步，并从版本控制系统中导入项目内容。自动化控制器管理三组 secret：

强烈建议您实施特权访问或凭证管理解决方案来保护凭证。组织应审计 的使用，并提供对、访问和特权升级的其他编程控制。

您可以通过确保自动化凭证是唯一的并只存储在自动化控制器中来进一步保护自动化凭证。OpenSSH 等服务可以配置为只允许来自特定地址的连接的凭证。从系统管理员用来登录服务器的用户，使用不同的凭据进行自动化。虽然直接访问应尽可能限制，但可用于灾难恢复或其他临时管理目的，从而可以更轻松地进行审核。

不同的自动化作业可能需要在不同级别上访问系统。例如，您可以有低级系统自动化来应用补丁并执行安全基线检查，同时具有更高级别的自动化部署应用程序。通过将不同的密钥或凭证用于不同的自动化部分，可以最小化任何一个关键漏洞的影响。这也允许轻松进行基准审核。

可见性和分析是企业安全和零信任架构的重要支密。日志记录是捕获操作和审核的关键。您可以使用 Red Hat Enterprise Linux 安全强化指南中的内置的 审计 支持来管理日志记录和审核。控制器的内置日志记录和活动流支持自动化控制器和自动日志中的所有更改，以满足审计目的。如需更多信息，请参阅自动化控制器文档中的 日志记录和聚合 部分。

本指南建议您配置 Ansible Automation Platform 和底层 Red Hat Enterprise Linux 系统，以集中收集日志和审核，而不是在本地系统中查看它。自动化控制器必须配置为使用外部日志记录来从控制器服务器中的多个组件编译日志记录。发生的事件必须与时间相关，才能进行准确的诊断分析。这意味着，控制器服务器必须配置有 NTP 服务器，服务器也由日志记录聚合器服务以及控制器的目标。相关性必须满足某些行业容错要求。换句话说，可能有不同的要求，不同日志事件的时间戳不得因 X 秒大于 X 秒而不同。此功能应该在外部日志记录服务中可用。

日志记录的另一个关键功能是使用加密来保护日志工具的完整性。日志数据包括成功记录系统活动所需的所有信息（如日志记录、日志设置和日志报告）。攻击者通常会替换日志工具，或将代码注入现有工具，以便从日志中隐藏或擦除系统活动。要解决这个风险，日志工具必须经过加密签名，以便您可以识别何时修改、操作或替换日志工具。例如，验证日志工具没有被修改、操作或替换的方法是对工具文件使用 checksum 哈希。这样可确保工具的完整性没有被破坏。

在常见用例中应用 NIST Cybersecurity Framework，需要使用 Ansible Automation Platform 来满足安全策略要求，例如：

这可以通过网络安全框架的 5 个步骤完成：

Ansible Automation Platform 的安全性依赖于底层 Red Hat Enterprise Linux 服务器的配置。因此，每个 Ansible Automation Platform 组件的底层 Red Hat Enterprise Linux 主机都必须根据您的机构使用的 安全强化 Red Hat Enterprise Linux 8 或 安全强化 （取决于使用什么操作系统）以及任何安全配置集要求(CIS、STIG、HIPAA 等)以及您的机构使用的任何安全配置集要求(CIS、STIG、HIPAA 等)。

请注意，应用 STIG 或其他安全配置集的某些安全控制可能会与 Ansible Automation Platform 支持要求冲突。虽然 Automation controller STIG considerations 部分列出了一些示例，但这不是一个完整的列表。要维护受支持的配置，请务必讨论与安全审核员的任何此类冲突，以便了解并批准 Ansible Automation Platform 要求。

Ansible Automation Platform 安装程序可以从其中一个基础架构服务器运行，如自动化控制器，或者从可通过 SSH 访问 Ansible Automation Platform 基础架构服务器的外部系统运行。Ansible Automation Platform 安装程序也不用于安装，而是用于后续第二天操作，如备份和恢复，以及升级。本指南建议从专用外部服务器执行安装和第二天操作，此处称为安装主机。这样做消除了登录其中一个基础架构服务器以运行这些功能的需求。安装主机必须仅用于管理 Ansible Automation Platform，且不得运行任何其他服务或软件。

安装主机必须是已安装和配置的 Red Hat Enterprise Linux 服务器，根据 Red Hat Enterprise Linux 的安全强化 以及与您的机构相关的任何安全配置文件(CIS、STIG 等)。获取 Ansible Automation Platform 安装程序，如 自动化平台规划指南中所述，按照 Automation Platform 安装指南中所述 创建安装程序清单文件。此清单文件用于升级、添加基础架构组件和由安装程序执行第二天操作，因此在安装后保留 文件以备将来使用。

对安装主机的访问必须仅限于负责管理 Ansible Automation Platform 基础架构的人员。随着时间的推移，它将包含敏感信息，如安装程序清单（其中包含 Ansible Automation Platform 的初始登录凭据）、用户提供的 PKI 密钥和证书的副本、备份文件等。如果需要基础架构管理和维护，还必须使用安装主机通过 SSH 登录 Ansible Automation Platform 基础架构服务器。

安装清单文件定义了 Ansible Automation Platform 基础架构的架构，并提供了很多变量，可用于修改基础架构组件的初始配置。如需有关安装程序清单的更多信息，请参阅 Ansible Automation Platform 安装指南。

下表列出了一些与安全相关的变量，以及它们的建议值用于创建安装清单。

在负载均衡器用于多个控制器或 hub 的参考架构中，SSL 客户端连接可以在负载均衡器终止，或传递给单独的 Ansible Automation Platform 服务器。如果 SSL 在负载均衡器终止，本指南建议流量从负载均衡器重新加密到单个 Ansible Automation Platform 服务器，以确保使用端到端加密。在这种情况下，表 2.3 中列出的 *_disable_https 变量会保留默认值 "false"。

默认情况下，Ansible Automation Platform 为平台的基础架构组件创建自签名 PKI 证书。如果现有的 PKI 基础架构可用，必须为自动化控制器、私有自动化中心、Event-Driven Ansible 控制器和 postgres 数据库服务器生成证书。将证书文件复制到安装程序目录中，以及用于验证证书的 CA 证书。

使用以下清单变量，以使用新证书配置基础架构组件。

当使用负载均衡器部署多个自动化控制器时，web_server_ssl_cert 和 web_server_ssl_key 会为每个控制器共享。要防止主机名不匹配，证书的通用名称(CN)必须与负载均衡器使用的 DNS FQDN 匹配。这在部署多个私有自动化中心和 automationhub_ssl_cert 和 automationhub_ssl_key 变量时也适用。如果您的机构策略为每个服务都需要唯一的证书，每个证书都需要一个 Subject Alt Name (SAN)，它与用于负载均衡服务的 DNS FQDN 匹配。要在每个自动化控制器上安装唯一的证书和密钥，安装清单文件中的证书和密钥变量必须定义为每个主机变量，而不是在 [all:vars] 部分中。例如：

[automationcontroller]
controller0.example.com web_server_ssl_cert=/path/to/cert0 web_server_ssl_key=/path/to/key0
controller1.example.com web_server_ssl_cert=/path/to/cert1 web_server_ssl_key=/path/to/key1
controller2.example.com web_server_ssl_cert=/path/to/cert2 web_server_ssl_key=/path/to/key2

[automationhub]
hub0.example.com automationhub_ssl_cert=/path/to/cert0 automationhub_ssl_key=/path/to/key0
hub1.example.com automationhub_ssl_cert=/path/to/cert1 automationhub_ssl_key=/path/to/key1
hub2.example.com automationhub_ssl_cert=/path/to/cert2 automationhub_ssl_key=/path/to/key2

安装清单文件包含多个敏感变量，主要用于设置 Ansible Automation Platform 使用的初始密码，它们通常以纯文本形式保存在清单文件中。为防止未经授权的查看这些变量，您可以将这些变量保存在加密的 Ansible vault 中。要做到这一点，进入安装程序目录并创建 vault 文件：

系统将提示您输入新 Ansible vault 的密码。不要丢失 vault 密码，因为每次需要访问 vault 文件时都需要它，包括在第二天操作和执行备份过程中。您可以通过将 vault 密码存储在加密的密码管理器中或根据您的组织策略安全地存储密码来保护 vault 密码。

在密码库中添加敏感变量，例如：

admin_password: <secure_controller_password>
pg_password: <secure_db_password>
automationhub_admin_password: <secure_hub_password>
automationhub_pg_password: <secure_hub_db_password>
automationhub_ldap_bind_password: <ldap_bind_password>
automationedacontroller_admin_password: <secure_eda_password>
automationedacontroller_pg_password: <secure_eda_db_password>

确保安装清单文件中不存在这些变量。要将新的 Ansible 库与安装程序搭配使用，请使用命令 ./setup.sh -e @vault.ymlcategories-unmarshal--ask-vault-pass 来运行。

对于使用 Defense Information Systems Agency (DISA)安全技术实施指南(STIG)作为其整体安全策略的一部分，现在提供了 用于 Ansible Automation Platform 自动化控制器的 STIG。STIG 目前仅涵盖 Ansible Automation Platform 的自动化控制器组件。将 STIG 应用到自动化控制器时，需要注意很多注意事项。

自动化控制器 STIG 概述文档指出它要与 Red Hat Enterprise Linux 8 的 STIG 一起使用。此版本的自动化控制器 STIG 在 Red Hat Enterprise Linux 9 可用前发布，因此在应用自动化控制器 STIG 时，Red Hat Enterprise Linux 8 应该用作底层主机操作系统。某些 Red Hat Enterprise Linux 8 STIG 控制将与 Ansible Automation Platform 安装和操作冲突，如以下部分所述。

Red Hat Community of practice 创建了一组通过集合提供的自动化内容，以管理 Ansible Automation Platform 基础架构和配置作为代码。这可通过 Infrastructure as Code (IaC)或 Configuration as Code (CaC)实现平台本身的自动化。虽然这种方法的许多优点很明显，但需要考虑一些关键的安全隐患。

以下 Ansible 内容集合可用于使用基础架构作为代码方法管理 Ansible Automation Platform 组件，它们都在 Ansible Automation Hub 中找到：

许多企业使用 CI/CD 平台来配置管道或其他方法来管理这类基础架构。但是，原生使用 Ansible Automation Platform，可以将 Webhook 配置为原生链接基于 Git 的存储库。这样，Ansible 可以直接响应 git 事件来触发作业模板。这从整个过程中删除了对外部 CI 组件的需要，从而减少了攻击面。

这些实践允许对所有基础架构和配置进行版本控制。应用 Git 最佳实践以确保在同步到 Ansible Automation Platform 前正确检查代码质量。相关的 Git 最佳实践包括：

IaC 还鼓励使用外部 vault 系统，无需将任何敏感数据存储在存储库中，或者根据需要处理单独的 vault 文件。有关使用外部 vault 系统的更多信息，请参阅本指南中的 2.3.2.3 外部凭证库注意事项。

作为管理员，您可以使用内置到自动化控制器的基于角色的访问控制(RBAC)来委派对服务器清单、机构等的访问权限。管理员也可以集中管理各种凭证，允许最终用户利用所需的 secret，而无需向最终用户公开该 secret。RBAC 控制允许您控制器帮助您提高安全性并简化管理。

RBAC 是向用户或团队授予角色的方法。RBAC 易于认为是角色(Role)，它精确定义了谁、更改或删除要为其设置特定功能的"对象"。

您应该熟悉自动化控制器的 RBAC 设计的一些主要概念，包括角色、资源和用户。用户可以是角色的成员，授予他们对与该角色关联的任何资源或与"子代"角色关联的任何资源的某些访问权限。

角色基本上是一个能力集合。通过为其分配的角色或通过通过角色层次结构继承的角色，授予用户对这些功能和控制器资源的访问权限。

角色将一组能力与一组用户相关联。所有功能都源自角色内的成员资格。用户仅通过为其分配的角色或通过角色层次结构继承的角色获得权限。角色的所有成员都具有授予该角色的所有权限。在一个机构中，角色相对稳定，而用户和能力有很多且可能会快速变化。用户可以有许多角色。

有关角色层次结构、访问权限继承、角色、权限、用户角色、角色创建等的更多详情，请参阅基于角色的访问控制。

以下是具有角色和资源权限的机构示例：

图 2.3. 自动化控制器中的 RBAC 角色范围

用户访问权限基于管理系统对象（用户、组、命名空间）的权限，而不是单独为特定用户分配权限。您可以为您创建的组分配权限。然后，您可以为这些组分配用户。这意味着，组中的每个用户都有分配给该组的权限。

在 Automation Hub 中创建的组，其范围可以包括系统管理员所需进行的任务，包括负责管理内部集合、配置用户访问和存储库管理。这些组可具有组织并上传内部开发的内容至 Automation Hub 的权限。如需更多信息，请参阅 Automation hub 权限 以实现一致性。

可以启用只查看访问，以进一步锁定私有自动化中心。通过启用只查看访问权限，您可以授予用户查看私有自动化 hub 上的集合或命名空间的访问权限，而无需进行登录。View-only 访问权限允许您与未授权用户共享内容，同时限制他们只能查看或下载源代码的权限，而无需编辑私有自动化中心上的任何内容。编辑 Red Hat Ansible Automation Platform 安装程序中的清单文件，为您的私有自动化中心启用只查看访问。

所有升级的系统版本不能比当前要升级到的版本低两个主要版本。例如，要升级到自动化控制器 4.3，您必须首先在版本 4.1.x 上，因为没有从 3.8.x 或更早版本直接升级路径。如需更多信息，请参阅 升级到 Ansible Automation Platform。要运行自动化控制器 4.3，还必须有 Ansible 2.12 或更高版本。