我正在研究像Puppet这样的配置管理软件。我主要担心的是阻止所有内部服务器的单一入口点。以这种情况为例。
不知何故，访问进入主配置服务器。然后，用户就可以获得相对容易的访问权限来操纵或最终获得对主控制的其他服务器的访问权。
主要目标是防止单点进入网络，即使所述主配置不可用于公共互联网。
tl; dr如何防止单点访问主/代理配置管理设置中的所有其他服务器？
答案 0 :(得分：0)
如果您正在考虑将定义Puppet规则的任务委派给其他人（例如技术人员），您可以创建一个Puppet master（Master A），让测试机器连接到Master A，然后让它们提交Git或SVN的代码。
你控制第二个Puppet master（Master B），你从Git或SVN中提取代码。网络中的所有机器都连接到Master B.一旦您对代码感到满意，您可以让Puppet将其推送到您的所有机器。
这样，只能在Master B上访问所有机器配置，只有你可以处理和访问。
答案 1 :(得分：0)
您无法使用默认配置。
Puppet的设计方式是让代理联系主人。即使您在多个防火墙后面，您也需要允许代理进入内部网络。即使您经常允许从DMZ到内部网络的连接，您仍可能需要在开放的互联网中管理机器。 Puppet需要的是打开你的内部网络到开放的互联网。
这种客户端拉动设计的风险在于，如果您可以通过代理攻击机器，您可以联系主服务器，如果主服务器有任何漏洞，您可以入侵它并从中攻击您可以控制所有计算机代理商，您还可以将攻击安装到内部网络中。因此，如果Puppet主通信通道中的漏洞与代理一起被利用，那么Puppet就会变成一个攻击载体（一个巨大的攻击载体，因为您可能使用它管理所有基础架构，并允许从外部访问LAN）。
采用主推设计，这可以最小化，因为主设备将是一个单点保护，并且将位于安全的内部网络中，连接仅从内部到外部。
PuppetLabs（http://projects.puppetlabs.com/issues/2045）中有一个待处理的功能请求（4年！），名为 puppetmaster中的推送功能。阅读有关该功能请求的评论并查找以下评论之类的内容让我想知道Puppet开发人员是否真的了解问题是什么：
最终，它并不是那么高优先级 - 几乎所有打开端口到主暴露的风险也通过让主设备伸出并联系客户端来暴露。拟议模型的实际风险几乎没有变化。
然而，当开发人员意识到问题时，其他人正在设计他们自己的解决方案（如https://github.com/tomas-edwardsson/puppet-push）。
更新的 我发现了BerndStrößenreuther的一篇题为如何将您的环境转变为Puppet托管环境的最佳实践的演示文稿，可在http://stroessenreuther.info/pub/Puppet_getting_started.pdf以PDF格式提供
他建议建立从主服务器到代理的ssh连接，并打开反向隧道，以便代理可以连接到主服务器。这些连接可以定期在cron作业中启动。通过这种方式，您无需为传入连接打开内部网络，但代理可以访问主数据。
现在，关于拉动机制，它似乎是一个糟糕的设计，但实际上必须允许非常自动化的环境工作。例如，在弹性网络（如EC2 with autoscaling）中，服务器自动启动和停止，服务器需要能够立即自行配置，因此它们启动并且他们做的第一件事是联系主服务器以进行更新组态。如果你必须定期将配置推送到每个服务器，那将更难，因为他们需要等待主服务器（秒，分钟或小时;这在某些应用程序中是不可接受的）。