Puppet 安全和网络拓扑

Question

背景：

我终于留出一些时间加入 21 世纪，看看 Puppet。

就目前而言，我们在办公室内部保存的存储库中对所有服务器配置进行版本控制。当需要进行更新时，更改会被检回存储库并手动推送到有问题的机器上。这通常意味着 SFTP 到远程机器，然后将文件从 shell 移动到具有相关权限的位置。

所以我希望 Puppet 将成为我们已有的简单而惊人的扩展。

现在我考虑我们目前必须合理安全的流程。假设我们的内部网络总是比我们数据中心的公共网络相对更安全。

• 过程总是一种方式。变化从安全的环境到不安全的环境，而不会反过来。

• 主存储在最安全的地方。通过窃取配置或发送恶意修改的危害风险大大降低。

题：

根据我对 Puppet 服务器/客户端模型的理解，客户端直接从服务器轮询和拉取更新。流量是 SSL 包装的，因此不能被拦截或欺骗。但它与我们目前所做的不同，因为 Puppet 服务器 [s] 需要托管在公共位置。要么集中，要么针对我们维护的每个数据中心站点。

所以我想知道：

• 我是否对从推到拉的变化感到不必要的偏执？

• 我是否对在公共网络上集中存储所有这些信息感到不必要的偏执？

• 其他人如何维护多个网络——每个站点都有单独的服务器？

---

09 年 7 月 30 日更新：

我想我的另一个大问题是必须信任一台机器。puppetmaster(s) 将被防火墙保护，安全等。但即便如此，任何具有侦听服务的公共机器都有一定规模的攻击面。

据推测，如果 master 有权更新任何一个 puppet 客户端上的任何文件，那么它的妥协最终会导致其所有客户端的妥协。可以说是“国王到王国”。

• 这个假设正确吗？

• 有什么办法可以缓解吗？

Answer 1

因为我有时将密码存储在我的模块中的变量中，以便能够在不必手动完成配置的情况下部署应用程序，这意味着我无法将我的 puppet 存储库放在公共服务器上。这样做意味着攻击 puppetmaster 将允许获得我们所有服务器上所有不同应用程序的一些应用程序或数据库密码。

所以我的 puppetmaster 在我们办公室的专用网络中，我不在服务器上运行 puppetd ​​守护进程。当我需要部署时，我使用 ssh 从私有网络到服务器，创建隧道并远程调用 puppetd。
诀窍不是设置远程隧道和 puppet 客户端来连接到 puppetmaster，而是设置到一个接受http 连接并可以访问私有网络上的 puppetmaster 服务器的代理。否则 puppet 会因为主机名与证书冲突而拒绝拉取

# From a machine inside privatenet.net :
ssh -R 3128:httpconnectproxy.privatenet.net:3128 \
    -t remoteclient.publicnetwork.net \
    sudo /usr/sbin/puppetd --server puppetmaster.privatenet.net \
    --http_proxy_host localhost --http_proxy_port 3128 \
    --waitforcert 60 --test –-verbose

对我有用，希望能帮到你

Answer 2

我无法判断你的偏执有多么必要，这很大程度上取决于你的环境。不过，我可以自信地说，您现有配置的两个要点仍然适用。您可以确保您的更改从安全环境（您办公室的存储库）转移到安全性较低的环境，无论您的 puppetmaster 位于何处。您将流程从 SFTP 更改为一堆服务器并手动将文件放置到位，改为 SFTP 到您的 puppetmaster，让 Puppet 分发文件并将它们放置在正确的位置。您的主存储仍然是存储库，并且您的风险得到了缓解。

我不认为推或拉本质上比其他模型更安全。Puppet 在保护传输中的配置以及对客户端和服务器进行身份验证以确保存在双向信任方面做得很好。

至于多个网络 - 我们通过一个中央“主”傀儡大师来处理它，每个位置的卫星傀儡大师充当中央大师的客户端。