Documentation

12. Secret 处理和连接安全

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

12.1. Secret 处理

automation controller 管理三组 secret:

  • 用于本地 automation controller 用户的用户密码

  • 用于 automation controller 操作的 secret(数据库密码、消息总线密码等)

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

12.1.1. 用于本地 automation controller 用户的用户密码

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

12.1.2. 用于 automation controller 操作使用的 secret 处理

automation controller 包含以下在操作中使用的 secret:

  • /etc/tower/SECRET_KEY

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

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

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

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

    • 用于连接至 automation controller 组件服务的密码

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

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

注解

如果 secrets 系统停机,则控制器将无法获取信息,并可能会导致失败,当服务被恢复后,这个失败可以被修复。我们强烈建议您在该系统中使用一些冗余功能。

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

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

  2. 使用您安装的清单(与您运行备份/恢复的清单相同),运行 setup.sh -k

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

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

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

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

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

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

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

12.2. 连接安全性

12.2.1. 内部服务

automation controller 作为内部操作的一部分连接到以下服务:

  • PostgreSQL 数据库

  • Redis 键/值存储

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

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

12.2.2. 外部访问

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

12.2.3. 受管的节点

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