我正在研究像Puppet这样的配置管理软件。我最关心的是防止我们所有内部服务器的单一入口点。以以下场景为例:
以某种方式获得了进入主配置服务器的访问权限。从那里，用户将能够相对容易地访问操作或最终访问由主服务器控制的其他服务器。
主要目标是防止单点进入网络，即使所述主配置对公共互联网不可用。
在主/代理配置管理设置中，如何防止对所有其他服务器的单点访问?如果您正在考虑将定义Puppet规则的任务委托给其他人(例如:，你可以创建一个Puppet master (master a)，有一个测试机器连接到master a，然后让他们提交代码到Git或SVN。
您控制第二个Puppet master (master B)，您从Git或SVN中提取代码。网络上所有的机器都连接到Master B.一旦你对代码满意，你可以让Puppet把它推送到你所有的机器上。
这样，只能访问主B上的所有机器配置，只有您可以处理和访问。
不能使用默认配置。
设计Puppet的方式是让代理与主人联系。即使您在多个防火墙后面，您也需要允许代理进入您的内部网络。即使您通常允许从DMZ到内部网络的连接，您可能仍然需要管理开放internet中的计算机。Puppet需要的是将你的内部网络开放到开放的internet。
这种客户端拉式设计的风险在于，如果你可以用代理入侵一台机器，你就可以联系主机，如果主机有任何漏洞，你就可以入侵它，从它们可以控制所有有代理的机器，而且你可以对你的内部网络发动攻击。因此，如果在与代理的Puppet主通信通道中利用漏洞，那么Puppet就成为一个攻击向量(一个巨大的攻击向量，因为您可能使用它管理所有基础设施，并且您已经允许从外部访问您的LAN)。
通过主推设计，这可以最小化，因为主推将是一个单点保护，并且将在安全的内部网络中，连接仅从内部到外部。
在PuppetLabs (http://projects.puppetlabs.com/issues/2045)中有一个未决的功能请求(4年前!)标题为将puppetmaster中的功能推送到客户端。阅读对该特性请求的评论，并发现类似以下评论的东西，使我怀疑Puppet开发人员是否真正理解问题所在:
最终，它的优先级也不是那么高——几乎所有向主端开放端口所暴露的风险都是由主端伸出并联系客户端所暴露的。建议的模型的实际风险几乎没有变化。
然而，当开发人员意识到这个问题时，其他人正在设计他们自己的解决方案(如https://github.com/tomas-edwardsson/puppet-push)。
更新:我找到了Bernd Strößenreuther的一篇题为关于如何将您的环境转变为Puppet托管环境的最佳实践的演讲，可在http://stroessenreuther.info/pub/Puppet_getting_started.pdf以PDF形式获得
他建议从主服务器到代理服务器建立ssh连接，并打开反向隧道，使代理服务器可以连接到主服务器。这些连接可以在cron作业中定期启动。通过这种方式，您不必为传入连接打开内部网络，但代理可以访问主数据。
现在，关于拉动机制，它可能看起来像一个糟糕的设计，但实际上它是允许非常自动化的环境工作的必要条件。例如，在自动启动和停止服务器的弹性网络(如具有自动缩放功能的EC2)中，服务器需要能够立即配置自己，因此它们启动后要做的第一件事就是联系主服务器以更新配置。如果您必须定期将配置推送到每个服务器，这将更加困难，因为它们需要等待主服务器(秒、分钟或小时);