vagrant 和 puppet 安全 SSL 证书

vagrant 和 puppet 安全 SSL 证书

我对 vagrant 还很陌生,有谁对它(和 puppet)有更多了解,能解释一下 vagrant 如何处理在制作与实际生产机器处理相同节点定义的 vagrant 测试机器时所需的 ssl 证书吗?

我在主/客户端模式下运行 Puppet,并且希望启动 Puppet 生产节点的 Vagrant 版本,主要是为了测试新的 Puppet 代码。

如果我的生产机器是 sql.domain.com,我会启动一个 vagrant 机器,例如 sql.vagrant.domain.com。在 vagrant 文件中,我使用 puppet_server 配置程序,并为 puppet.puppet_node 条目提供“sql.domain.com”,以便它获得相同的 puppet 节点定义。

在 Puppet 服务器上,我在该节点条目上使用类似 /*.sql.domain.com/ 的正则表达式,以便 vagrant 机器和真实机器都可以在 Puppet 服务器上获取该节点条目。

最后,我在 puppet 的 autosign.conf 中启用 *.vagrant.domain.com 的自动签名,这样 vagrant 机器就被签名了。

到目前为止,一切都很好...

但是:如果我网络上的一台机器被 root,比如 unimportant.domain.com,那么如何阻止攻击者将该机器上的主机名更改为 sql.vagrant.domain.com,从中删除旧的 puppet ssl 证书,然后使用给定节点名称 sql.domain.com 重新运行 puppet ?新的 ssl 证书将由 puppet 自动签名,匹配节点名称正则表达式,然后这个被黑客入侵的节点将获得所有针对 sql 机器的重要信息?!

我能想到的一个解决方案是避免自动签名,将实际生产机器的已知 puppet ssl 证书放入 vagrant 共享目录中,然后让 vagrant ssh 作业将其移动到位。这样做的缺点是,我最终会将每台生产机器的所有 ssl 证书放在一个 git 存储库(我的 vagrant 存储库)中,从而放在每台开发人员的机器上——这可能是也可能不是问题,但这听起来不是正确的做法。

总结:其他人如何处理用于开发或测试生产机器克隆的 vagrant 和 puppet ssl 证书?

答案1

为可能遇到类似查询的其他人提供答案。我最终在主机专用网络配置中使用了 vagrant,并在主机上使用后路由伪装 (nat),以使主机专用网络也能与外界联系。

有一个 vagrant puppetmaster,它使用自动签名 - 鉴于它位于它自己的仅主机(vboxnet0)网络上,无论我为其编写代码的 vagrant puppet 客户端如何,它都能消除我遇到的大多数安全问题。

对于生产,真正的(非 vagrant)puppetmaster 仅具有 git 的生产分支,并且不允许任何自动签名。

相关内容