Ansible 安全最佳实践

Question

我将把 Ansible 引入我的数据中心，我正在寻找一些关于在何处定位控制机器以及如何管理 SSH 密钥的安全最佳实践。

问题一：控制机

我们当然需要一台控制机器。控制机器上保存了公共 SSH 密钥。如果攻击者可以访问控制机器，它就有可能访问整个数据中心（或 Ansible 管理的服务器）。那么数据中心有专用控制机好还是远程控制机好（比如我的笔记本电脑远程连接数据中心）？

如果最佳做法是使用我的笔记本电脑（当然，它可能会被盗，但我可以将我的公钥安全地在线保存在云中或离线保存在便携式加密设备上），如果我需要使用一些 Web 界面，该怎么办？ Ansible，像 Ansible Tower、Semaphore、Rundeck 或 Foreman，需要安装在数据中心的中央机器上？如何保护它并避免它成为“单点攻击”？

问题 2：SSH 密钥

假设我需要使用 Ansible 来制作一些需要由 root 执行的任务（比如安装软件包或类似的东西）。我认为最好的做法是不要在受控服务器上使用 root 用户，而是为 Ansible 添加一个具有 sudo 权限的普通用户。但是，如果 Ansible 需要执行几乎所有任务，则它需要通过 sudo 访问每个命令。那么，最好的选择是什么：

• 让 Ansible 使用 root 用户（其公钥保存在 ~/.ssh/authorized_keys
• 创建一个专用于 Ansible 的非特权用户，并具有 sudo 访问权限
• 让 Ansible 用户通过指定密码的 sudo 运行每个命令（每个使用 Ansible 控制服务器的系统管理员都需要知道这是唯一的）
• 让 Ansible 用户在不指定任何密码的情况下通过 sudo 运行每个命令
• 任何其他提示？

Answer 1

堡垒主机（ansible 控制中心）属于一个单独的子网。它不应该从外部直接访问，也不应该从托管服务器直接访问！

您的笔记本电脑是最不安全的设备。一封愚蠢的邮件，一个愚蠢的 Flash 漏洞，一个愚蠢的访客 Wifi，然后它就被盗用了。

对于服务器，根本不允许通过 ssh 进行 root 访问。许多审计对此嗤之以鼻。

对于 ansible，让每个管理员在每个目标服务器上使用自己的个人帐户，并让他们使用密码 sudo。这样就不会在两个人之间共享密码。您可以检查谁在每台服务器上做了什么。个人帐户是否允许使用密码、ssh 密钥登录或两者都需要，这取决于您。

澄清ansible 不需要使用单个目标登录名。每个管理员都可以而且应该有个人目标登录名。

旁注：如果有密码，请尽量不要创建名为某个单词（如“ansible”或“admin”或“cluster”或“management”或“operator”）的帐户。具有密码的帐户唯一好名称是人名，例如“jkowalski”。只有人类才能对通过帐户执行的操作负责，并对密码保护不当负责，“ansible”不能。

Answer 2

> 问题一：控制机

在 Userify（完全披露：我们实际上提供软件来管理 ssh 密钥），我们一直在处理这个问题，因为我们还运行着最大的 SSH 密钥仓库。我们通常推荐本地安装而不是使用云，因为您增加了控制，减少了您的表面积，您可以真正将其锁定到已知的受信任网络。

需要记住的重要一点是，在这样一个正确构建的系统中，真的不应该有任何可以泄露给攻击者的重要秘密。如果有人驾驶叉车进入您的数据中心并带走您的服务器，他们将不会得到很多，除了一些高度散列的密码，可能是一些高度加密的文件，以及一些没有相应私钥的公钥。换句话说，没有那么多。

正如您所指出的，这里真正的威胁媒介是如果攻击者获得了该机器的控制权并使用它来部署他们自己的用户帐户和（公共）密钥会发生什么。这对几乎所有云平台（例如：Linode）都是一种风险。你应该最专注于防止对控制平面的访问，这意味着最小化攻击面（只暴露几个端口，并尽可能地锁定这些端口），最好使用能够抵御特权升级和各种攻击的软件（ SQL 注入、XSS、CSRF 等）启用对控制平面的 2FA/MFA 访问，并尽可能专注于锁定该控制平面。

那么数据中心有专用控制机好还是远程控制机好（比如我的笔记本电脑远程连接数据中心）？

这是肯定更好有一个专用的控制机器在安全的数据中心，因为你可以隔离并锁定，以防止/最小化被盗或未经授权的访问的风险。

如果最好的做法是用我的笔记本电脑（这可能会被窃取，当然，但我有我的公钥安全地在便携式加密后设备上的云或离线在线保存），如果我需要使用一些网络接口什么用Ansible，如 Ansible Tower、Semaphore、Rundeck 或 Foreman，它们需要安装在数据中心的中央机器上？

您不需要运行任何 Web 界面或辅助控制平面来管理您的密钥（甚至是 Userify），直到您变得足够大以开始进入管理问题（由于大量用户和跨服务器的不同授权级别或需要额外的权限）为可能不了解或无法访问 Ansible 来更新密钥的用户提供帮助。最初的 Userify 只不过是一堆 shell 脚本（今天它们可能是 Ansible，可能！）而且这完全没有错，直到您开始需要额外的管理控制和人们管理/轮换他们的简单方法自己的钥匙。（当然，如果你到了那一点，请看看 Userify！）

如何保护它并避免它成为“单点攻击”？

好吧，当然要查看网络上的所有资源以锁定事物，但最重要的是从一个安全的基础开始：

1. 从一开始就考虑到安全性来构建您的解决方案。选择传统上问题较少的技术（即数据库或语言），然后将安全编码放在首位。清理所有传入数据，即使是来自受信任用户的数据。偏执是一种美德。

2. 最终，一切都被打破了。发生这种情况时尽量减少损害：正如您已经指出的那样，尽量减少对秘密材料的处理。

3. 保持简单。除非您确定它会显着且可证明地提高您的安全性，否则不要使用最新的奇特事物。例如，我们选择了 X25519/NaCl (libsodium) 而不是 AES 作为我们的加密层（我们加密静止和运动中的所有内容），因为它最初是由我们信任的人（DJB 等人）设计和编写的，并得到了全世界的审查- 著名的研究人员，如 Schneier 和 Google 的安全团队。使用较新的趋于简单的东西，因为简单会使隐藏深层错误变得更加困难。

4.符合安全标准。即使您不属于 PCI 或 HIPAA 安全规则等安全制度，请通读这些标准并找出如何满足它们或至少是非常强大的补偿控制。这将有助于确保您真正符合“最佳实践”。

5.引入外部/独立渗透测试并运行漏洞赏金，以确保您持续遵循这些最佳实践。一切看起来都很棒，直到您得到一些聪明且积极性高的人的支持……一旦完成，您将对您的解决方案充满信心。

问题 2：SSH 密钥 什么是最佳选择：让 Ansible 使用 root 用户（将其公钥保存在~/.ssh/authorized_keys/ 让 Ansible 用户通过 sudo 指定密码来运行每个命令（这是每个系统管理员都需要知道的唯一密码）它使用 Ansible 来控制该服务器）

尽量避免在服务器上使用密码，即使是 sudo。那是在处理秘密，最终会破坏你的安全（你真的不能很容易地在机器之间改变 sudo 密码，你必须将它存储在某个地方，密码意味着你不能真正进行服务器到服务器的自动化，这是正是它的全部内容。此外，如果您将 SSH 保留为默认设置，则可以强制使用这些密码，这会使密钥变得毫无意义。此外，请避免出于任何目的使用 root 用户，尤其是远程登录。

创建一个专用于 Ansible 的具有 sudo 访问权限的非特权用户/让 Ansible 用户通过 sudo 运行每个命令而无需指定任何密码

确切地。您可以审核回 ansible 的非特权用户，具有 sudo 角色。理想情况下，创建一个标准用户，专用于具有 sudo 访问权限（无密码）的服务器到服务器/ansible 通信。

... 注意，如果您使用的是 Userify，我建议的做法是为 ansible 创建一个 Userify 用户（如果您有多个 ansible 控制机器，您也可以按项目甚至服务器组进行分解），生成控制服务器上的 SSH 密钥，并在其 Userify 配置文件页面中提供其公钥。（这个文本框本质上变成了/home/ansible/.ssh/authorized_keys）。您应该将 ansible 系统帐户与其他服务器到服务器系统帐户（例如远程备份帐户、机密管理等）分开。然后邀请您的人员，他们也可以创建和管理自己的密钥，一切都保持分开。但是，就像锁定 Ansible 控制服务器一样，尝试以相同的方式锁定您的 Userify 服务器（或您部署的任何解决方案）。

任何其他提示？

我认为你肯定会以正确的方式解决这个问题并提出正确的问题。如果您想讨论此类事情，请给我发电子邮件（userify 中的第一个点姓氏），无论您最终追求什么方向，我都很乐意与您交谈。祝你好运！

Answer 3

答案一：控制机

两者兼而有之，您可以使用笔记本电脑通过堡垒主机连接到服务器。就像是：

Host private1
  IdentityFile ~/.ssh/rsa_private_key
  ProxyCommand ssh user@bastion -W %h:%p

Host bastion
  IdentityFile ~/.ssh/bastion_rsa_key

有关堡垒主机的更多信息

您拥有堡垒服务器的密钥，然后是其背后主机的单独密钥。（我个人会使用 gpg-agent/ssh-agent）

答案 2：身份验证

我不确定“ansible”特定最佳实践与任何其他 ssh 连接最佳实践有何不同但不，您希望以自己的身份运行 ansible，而不是服务帐户和 root 帐户。

以下身份验证的组合：

• 每个用户的 ssh 密钥（集中存储）
• Kerberos身份验证
• 多因素身份验证（Yubikeys、Duo、GoogleAuth 等）
• Fail2ban / 帐户锁定
• 集中记录和警报
• 集中式身份验证（FreeIPA、LDAP、IdM、MS AD）
• 使用内部 CA 签署 ssh 密钥

其他想法：

• 始终将机密/私人信息存储在 ansible-vault 中。
• Ansible 不需要 SUDO/Root 才能运行，除非您正在执行的操作需要 sudo/root。
• Ansible 可以通过多种不同的方式提升权限

最后，你没有提到windows。所以我只能假设你没有使用这个。但是，在这种情况下，我将使用委托选项让您的笔记本电脑使用堡垒主机 (delegate_to bastion.hostname.fqdn:) 和 kerberos/winrm https 和 kerberos 票证。

如果你错过了，计算的最佳实践，永远不要以 root 身份做任何事情，总是使用命名帐户