人偶安全和网络拓扑

背景：

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

到目前为止，我们对办公室内部存储库中的所有服务器配置进行版本控制。需要进行更新时，将更改重新签到存储库中，然后手动将其推送到有问题的计算机上。这通常意味着将SFTP移至远程计算机，然后将具有相关权限的文件从Shell移到适当位置。

因此，我希望Puppet将成为我们现有内容的简单而又令人惊奇的扩展。

现在，我考虑我们目前必须相当安全的过程。假设我们的内部网络将始终比数据中心中的公共网络更加安全。

• 该过程始终是一种方式。变更从安全的环境遍历到不安全的环境，反之亦然。

• 总店位于最安全的地方。通过窃取配置或发出恶意修改而造成危害的风险大大降低了。

题：

根据我对Puppet服务器/客户端模型的了解，客户端直接从服务器轮询并提取更新。流量是用SSL包装的，因此无法被拦截或欺骗。但这与我们目前的做法有所不同，因为Puppet服务器需要托管在公共位置。可以集中管理，也可以每个中心维护一个。

所以我想知道：

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

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

• 其他人如何维护多个网络-每个站点使用单独的服务器？

更新30/07/09：

我猜想我的另一个大问题是必须信任一台机器。人偶管理员将被防火墙保护，固定等。但是即使如此，任何具有侦听服务的公共计算机都具有一定规模的攻击面。

据推测，如果主服务器有权更新任何一个clients客户端上的任何文件，那么这种妥协最终将导致其所有客户端的妥协。可以说是“王国之王”。

• 这个假设正确吗？

• 有什么办法可以减轻它？

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

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

# 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

它对我有用，希望对您有帮助

我们有两个站点，我们的办公室和我们的colo。每个站点都有其自己的puppetmaster。我们建立了一个具有以下结构的svn存储库：

root/office
root/office/manifests/site.pp
root/office/modules
root/colo
root/colo/manifests/site.pp
root/colo/modules
root/modules

每个站点下的模块目录是一个svn：externals目录，该目录返回到顶级模块目录。这意味着它们共享完全相同的模块目录。然后，我们确保所编写的绝大多数类都在modules目录下，并且被两个站点使用。这具有迫使我们进行一般思考而不将类与特定站点绑定的优点。

至于安全性，我们将我们的puppetmaster（以及我们网络的其余部分）托管在防火墙之后，因此我们不必担心集中存储配置。puppetmaster只会将配置发送到它信任的主机。显然，您需要确保该服务器的安全。

我无法判断您的妄想症有多严重，这在很大程度上取决于您的环境。但是，我可以自信地说现有配置的两个主要方面仍然可以适用。您可以确保将更改从安全的环境（办公室中的存储库）遍历到安全性较低的环境，无论您的人偶管理员位于哪里。您将过程从SFTP更改为一堆服务器，然后手动将文件放置到适当的位置，再将SFTP放置到puppetmaster，然后让Puppet分发文件并将它们放置在正确的位置。您的主存储仍然是存储库，可以减轻您的风险。

我不认为推或拉在本质上比其他模型更安全。Puppet在保护传输中的配置以及验证客户端和服务器以确保建立双向信任方面做得非常出色。

至于多个网络-我们通过一个中央“主”木偶管理员来处理它，每个位置都有卫星人造人，作为中央主控制器的客户端。

一种设计方法是在系统的每个站点本地都有一个puppetmaster，并使用部署工具将更改推送到puppetmasters。（将git和git hooks一起使用也可以）。

这将保留您对公用网络上的侦听服务的关注，因为network网络通信仅是内部的。

也可以将清单推送到每个服务器，并让p客户端解析清单并应用相关的配置。

尽管您说的是“外部”，但我真的怀疑，是否有任意人需要连接到您的人偶大师。您可以随时将VPN加入。我的一个朋友曾经问我“如果连接安全，您是否需要担心协议的安全性？” 虽然我不同意这种态度，但额外的一层永远不会伤害我，并且肯定会对我的个人偏执产生奇迹。此外，它对隧道的乐趣。

cfengine的作者兼大学教授Mark Burgess（木偶似乎应归功于其遗产）已经撰写了大量关于推拉的文章。他声称拉力本质上更安全。如果您查看cfengine网站，则他们在17年中仅发生过1次网络安全事件。伯吉斯声称这是由于拉动设计。我认为妥协是不可避免的。我将更关注到这一点的攻击途径。

如果需要，您可以在没有中央主机的情况下运行人偶。我见过的一种方法是使用git存储库，并且只有在标签由gpg键的预设列表之一签名的情况下，脚本才会合并和部署更新。人们甚至想出了如何获取存储的配置（用于例如从另一台服务器上处理的资源在中央服务器上设置nagios监视）。

因此，如果中央git服务器遭到入侵，其他服务器将不再应用它的更新。gpg密钥将在sys admin笔记本电脑上或其他某种方式上，以及某种撤销密钥的方式。

在http://current.workingdirectory.net/posts/2011/puppet-without-masters/了解更多信息