前言：
我们在每个地理网络位置都有缓存解析器。这些集群具有弹性，并且它们的位置减少了我们的服务器生成的内部请求的延迟。
这很好用。除了通过网络看到的大量请求是对相同记录的查找，这些请求是由不执行任何自己的 DNS 缓存的应用程序生成的。
问题：
背景：
我终于抽出一些时间加入 21 世纪，看看 Puppet。
就目前而言，我们在办公室内部保存的存储库中对所有服务器配置进行版本控制。当需要进行更新时，更改会重新检入存储库并手动推送到有问题的机器上。这通常意味着 SFTP'ing 到远程机器，然后从 shell 将文件移动到适当的位置，并具有相关权限。
因此，我希望 Puppet 能够成为我们现有产品的简单而惊人的扩展。
现在我考虑我们目前必须相当安全的过程。假设我们的内部网络总是比我们数据中心的公共网络相对更安全。
这个过程总是一种方式。变化从安全环境到不安全环境，绝不会反过来。
主存储在最安全的地方。通过窃取配置或发送恶意修改的危害风险大大降低。
问题：
根据我对 Puppet 服务器/客户端模型的理解，客户端会直接从服务器轮询和拉取更新。流量是 SSL 包装的，因此不能被拦截或欺骗。但这与我们目前所做的不同，因为 Puppet 服务器需要托管在公共位置。可以集中处理，也可以为我们维护的每个数据中心站点提供一个。
所以我想知道：
我是否对从推到拉的变化感到不必要的偏执？
我是否对将所有这些信息集中存储在公共网络上感到不必要的偏执？
其他人如何维护多个网络 - 每个站点的单独服务器？
2009 年 7 月 30 日更新：
我想我的另一个大问题是必须信任一台机器。puppetmaster(s) 将被防火墙、安全等。但即便如此，任何具有监听服务的公共机器都有一定规模的攻击面。
据推测，如果主人有权更新任何一个 puppet 客户端上的任何文件，那么它的妥协最终会导致它的所有客户端的妥协。可以说是“王国的国王”。
这个假设正确吗？
有什么办法可以缓解吗？