Documentation

14. Secret 处理和连接安全

本文档描述了 Red Hat Ansible Tower 如何以安全的方式处理 secret 和连接。

14.1. Secret 处理

Ansible Tower 管理三组 secret：

  • 用于本地 Ansible Tower 用户的用户密码

  • 用于 Ansible Tower 操作的 secret（数据库密码、消息总线密码等）

  • 用于自动化的 secret（SSH 密钥、云凭证、外部密码存储库凭证等）

14.1.1. 用于本地 Ansible Tower 用户的用户密码

Ansible Tower 使用 SHA256 哈希通过 PBKDF2 算法来哈希处理本地 Ansible Tower 用户密码。通过外部帐户机制（LDAP、SAML、OAuth 和其他）进行身份验证的用户不会存储任何密码或 secret。

14.1.2. 用于 Ansible Tower 操作使用的 secret 处理

Ansible Tower 包含以下在操作中使用的 secret：

  • /etc/tower/SECRET_KEY

    • 用于加密数据库中自动化 secret 的 secret 键（参见下面的）。如果 SECRET_KEY 被更改或者未知，则无法访问数据库中的加密字段。

  • /etc/tower/tower.{cert,key}

    • Ansible Tower web 服务的 SSL 证书和密钥。默认安装自签名的证书/密钥；客户可提供适合本地的证书和密钥。

  • 数据库密码在 /etc/tower/conf.d/postgres.py 中，消息总线密码在/etc/tower/conf.d/channels.py 中

    • 用于连接至 Ansible Tower 组件服务的密码

这些 secret 都存储在 Ansible Tower 服务器上，因为它们都是需要由 Ansible Tower 服务以自动方式读取。所有 secret 都受到 Unix 权限的保护，并限制为 root 和 Ansible Tower 服务用户 awx。

如果需要隐藏这些 secret，则从中读取这些 secret 的文件会被做为 Python 进行解析。这些文件可以调整为通过其它机制获取这些 secret，只要这种机制在服务启动时可用。此操作是客户提供的修改，可能需要在每次升级时重新应用这些修改。红帽支持和红帽咨询会有此类修改的示例。

如果出于某种原因，您认为为您生成的 SECRET_KEY Tower 已被破坏，需要重新生成，您可以从安装程序运行一个工具，它和 Tower 备份和恢复工具非常相似。要生成新的密钥，请执行以下操作：

  1. 在执行其它操作前备份您的 Tower 数据库！ 按照本指南的 Backing Up and Restoring Tower 部分所述步骤操作。

  2. 使用您安装的清单（与您运行备份/恢复的清单相同），运行 setup.sh -k。

之前密钥的备份副本保存在 /etc/tower/ 中。

14.1.3. 用于自动化使用的 secret 处理

Ansible Tower 在数据库中存储各种用于自动化的 secret 或自动化生成的 secret。这些 secret 包括：

  • 所有凭证类型（密码、密钥、验证令牌、secret 云凭证）的所有 secret 字段

  • Ansible Tower 设置中定义的外部服务的 secret 令牌和密码

  • “密码”类型调查字段条目

要加密 secret 字段，Tower 使用 CBC 模式的 AES 与 256 位密钥进行加密、PKCS7 补丁和 HMAC 使用 SHA256 进行身份验证。加密/解密过程从 SECRET_KEY（上述）生成 AES-256 位加密密钥，模型字段的字段名称和数据库分配的自动递增记录 ID。因此，如果密钥生成过程中使用的任何属性发生更改，Tower 无法正确解密 secret。|at|设计为 SECRET_KEY 在 playbooks |at| 启动中不可读取，这些 secret 也不可由 Tower 用户读取，没有 secret 字段值通过 Ansible Tower REST API 可用。如果在 playbook 中使用 secret 值，我们建议使用任务上的 Ansible Tower，以便不会意外登录。

14.2. 连接安全性

14.2.1. 内部服务

Ansible Tower 作为内部操作的一部分连接到以下服务：

  • 本地 memcached

  • PostgreSQL 数据库

  • RabbitMQ 消息总线

到 memcached 的连接通过本地 unix 套接字进行，仅限于 awx 服务用户。

与 PostgreSQL 数据库的连接是通过 TCP 的密码身份验证完成的，可以是通过本地或远程（外部数据库）。这个连接可以使用 PostgreSQL 构建的 SSL/TLS 支持，作为安装程序支持的原生配置。SSL/TLS 协议由默认的 OpenSSL 配置来配置。

与 RabbitMQ 消息总线的连接是本地链接(Tower -> local RabbitMQ)和远程连接（本地 RabbitMQ 到其他 RabbitMQ 集群成员）。这个连接可以使用安装程序原本配置的 TLS 1.2。

14.2.2. 外部访问

Ansible Tower 通过标准端口上的标准 HTTP/HTTPS 访问。默认情况下会安装自签名的证书/密钥；客户可提供适合本地的证书和密钥。SSL/TLS 算法支持是在 /etc/nginx/nginx.conf 配置文件中配。默认情况下会使用“中间”配置文件，并可由客户配置。客户每次更新都必须重新应用客户的更改。

14.2.3. 受管的节点

作为自动化的一部分，Ansible Tower 也连接到受管机器和服务。所有连接到受管机器的连接都是通过指定的标准安全机制完成，如 SSH、WinRM、SSL/TLS 等——其中每项都继承了系统配置中有关功能的配置（如系统 OpenSSL 配置）。