标准 automation controller 设置的安全性适用于自动部署典型的环境。但是，在管理特定操作系统环境、自动化和自动化平台时，可能需要一些额外的最佳实践才能确保其安全性。本文档介绍了在自动化环境中确保安全性的最佳实践。
应用程序的安全性会受底层系统安全性的影响。为了确保 Red Hat Enterprise Linux 的安全性，请参阅：
Red Hat Enterprise Linux 7：https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/
Red Hat Enterprise Linux 8：https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/index
Ansible 和 automation controller 的一个通用目的是提供一个自动化平台。这意味着，一旦启动了一个 Ansible playbook（通过控制器，或直接通过命令行），playbook、清单和 Ansible 的凭证将被视为可靠的来源。如果特定的安全政策需要针对特定 playbook 内容、作业定义或清单内容进行外部验证，这些过程必须在自动化操作启动（无论是通过控制器 Web UI 或控制器 API) 之前进行。
使用源控制、分支和强制代码审核是 Ansible 自动化的最佳方法。有很多工具可帮助以这种方式创建使用源控制的进程流。
在更高的级别上，有很多工具允许针对任意工作流创建批准和基于策略的操作，包括自动化。这些工具可通过控制器的 API 来使用 Ansible 执行自动化。
We recommend all customers of automation controller select a secure default administrator password at time of installation. See 更改控制器管理员密码 for more information.
automation controller 在某些已知端口上公开服务，比如 HTTP 流量使用端口 80，HTTPS 流量使用端口 443。我们建议您不要在开放互联网上公开 automation controller，这会显著降低安装的风险。
授予系统某些部分的访问权限可能会带来安全隐患。请应用以下方法帮助保证访问安全：
限制对系统管理帐户的访问最小化对维护一个安全系统至关重要。系统管理员/root 用户可以访问、编辑和破坏任何系统应用程序。因此，尽量使具有 root 访问权限的用户和人员保持最少。不要为不信任的用户分配对 root 或 awx`（控制器用户）的 `sudo 权限。当通过某些机制（如 sudo）为用户提供了受限的管理访问权限时，这些访问权限仍有可能进行大量操作。允许执行 shell 的命令，或可以修改文件的任何命令，都应该视为等同于具有完整的 root 访问权限。
在控制器中，任何控制器 ‘系统管理员’ 或 'superuser' 帐户都可以编辑、修改和更新控制器中的任何清单或自动化定义。这只应该分配给尽量少的、需要进行底层控制器配置和灾难恢复的用户。
根据最佳实践方案原则，除了用于管理目的之外，automation controller 不需要进行本地用户访问。非管理员用户不应该具有可以访问控制器所在系统的权限。
如果自动化凭证仅存储在控制器中，则可进一步加以保护。OpenSSH 等服务可以配置为只允许来自特定地址的连接使用凭证.。自动化使用的凭证可能与系统管理员用于灾难恢复或其他 ad-hoc 管理的凭证不同，以允许更轻松地进行审核。
不同的自动化任务可能需要对一个系统有不同的访问级别。例如，您可能需要进行底层的系统自动化来应用补丁或执行安全检查；也可能需要进行高层的自动化来部署应用程序。通过对不同的自动化操作使用不同的密钥或凭证，可以最小化一个关键安全漏洞对系统的不良影响，同时可简化基准审核。
控制器和其它地方提供了一些资源来确保安全平台。请考虑使用以下功能：
对于任何管理访问，对其进行审核和监视是非常关键的。对于整个系统来说，这可以通过内置的审计支持（https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/chap-system_auditing.html）以及内置的日志支持实现。
automation controller 使用内置的 Activity Stream 支持，它可以记录控制器内的所有更改，以及自动化日志。
最佳实践推荐集中进行日志收集和审核，而不是在本地系统中进行。建议将 automation controller 配置为在您的环境中使用任何 IDS 和/或日志/审核 (Splunk) 标准。automation controller 包括了内置的、针对 Elastic Stack, Splunk, Sumologic, Loggly 和其他系统的日志集成功能。详情请参阅 日志记录和聚合。
不要禁用 SELinux，也不要禁用控制器中现存的多用户限制机制。使用控制器的角色访问控制 (RBAC) 来代表运行自动化所需的最低级别权限。使用控制器的团队（Team）来为用户组分配权限，而不是单独为用户分配权限。详情请参阅 Automation Controller User Guide 中的 基于角色的访问控制 。
对于一个大型机构，在控制器中维护完整的用户会非常耗时，且容易出错。Automation controller 支持通过 LDAP 、SAML 2.0 和特定的:ref:OAuth providers <ag_social_auth> 连接到外部账户源。
控制器管理员可以利用 Django 在创建时通过 AUTH_PASSWORD_VALIDATORS 设置密码策略以验证 Tower 用户密码。在 custom.py 文件中（位于控制器实例的 /etc/tower/conf.d），添加以下代码块示例：
AUTH_PASSWORD_VALIDATORS = [
{
'NAME': 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator',
},
{
'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator',
'OPTIONS': {
'min_length': 9,
}
},
{
'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator',
},
{
'NAME': 'django.contrib.auth.password_validation.NumericPasswordValidator',
},
]
如需更多信息，除了上面发布的示例外，请参阅 Password management in Django。
重启控制器实例以使更改生效。详情请参阅 启动、停止和重启控制器。