Puppet 防止配置管理主/代理设置中的单一入口点

我正在研究像Puppet这样的配置管理软件。我主要关心的是防止所有内部服务器都有一个单一的入口点。以这个场景为例

以某种方式，可以访问主配置服务器。从那里，用户将能够获得相对容易的操作权限，或最终获得对主服务器控制的其他服务器的访问权限

主要目标是防止单点进入网络，即使所述主配置不可用于公共互联网

---

tl；dr如何在主/代理配置管理设置中防止对所有其他服务器的单点访问？

如果您正在考虑将定义伪规则的任务委托给其他人（如技术人员），您可以创建伪主（主a），将测试机连接到主a，然后让他们将代码提交给Git或SVN

您控制第二个傀儡主控器（主控器B），从Git或SVN中提取代码。网络中的所有机器都连接到Master B。一旦您对代码感到满意，您可以让Puppet将其推送到所有机器上

---

这样，只能在主机B上访问所有机器配置，而只有您可以处理和访问主机B。

您不能使用默认配置

木偶的设计方式是让代理与主人联系。即使您在多个防火墙后面，也需要允许代理进入您的内部网络。即使您常规地允许从DMZ到内部网络的连接，您可能仍然需要在开放的internet中管理机器。Puppet需要的是向开放的internet开放您的内部网络

这种客户端拉式设计的风险在于，如果您可以使用代理入侵一台机器，您可以联系主机，如果主机存在任何漏洞，您可以入侵主机，并从主机上使用代理控制所有机器，此外，您还可以在内部网络中发起攻击。因此，如果在与木偶主通信通道中使用漏洞，那么傀儡就成为攻击向量（一个巨大的，就像你可以用它管理所有的基础设施，并且你可以从外部访问到局域网）。 通过主推设计，这可以最小化，因为主推将是一个单独的保护点，并且将位于安全的内部网络内，连接仅从内部到外部

PuppetLabs（）中有一个挂起的功能请求（4年前！），名为puppetmaster中的Push功能到客户端。阅读关于该功能请求的评论，并找到类似以下评论的内容，让我怀疑Puppet开发人员是否真的理解了问题所在：

归根结底，优先级也不高——几乎所有向主机打开端口的风险都会通过主机接触和联系客户机而暴露出来。拟议模型的实际风险几乎没有变化

然而，当开发人员意识到这个问题时，其他人正在设计他们自己的解决方案（如）

更新： 我发现Bernd Strößenreuther的一篇演讲题为“如何将您的环境转变为傀儡管理环境的最佳实践”，可在

他建议建立从主机到代理的ssh连接，并打开一个反向隧道，以便代理可以连接到主机。这些连接可以在cron作业中定期启动。通过这种方式，您不必为传入连接打开内部网络，但代理可以访问主数据

---

现在，关于拉动机制，它看起来可能是一个糟糕的设计，但实际上，允许非常自动化的环境工作是至关重要的。例如，在服务器自动启动和停止的弹性网络（如具有自动缩放功能的EC2）中，服务器需要能够立即进行自我配置，因此它们会启动，并且他们要做的第一件事就是联系主机以获取更新的配置。如果您必须定期将配置推送到每台服务器，这将更加困难，因为它们需要等待主机（秒、分钟或小时；这在某些应用程序中是不可接受的）。

谢谢！这其实不是个坏主意。但是，我主要关心的不是内部，而是有人访问Master B的可能性。您应该像保护生命一样保护服务器：）例如，如果不打算进行部署，您可以断开服务器与网络的连接，或者，将Master B设为笔记本电脑，我们最终决定尝试在Fabric（fabfile.org）中构建我们的部署/配置，它不允许中央管理服务器，使用github来版本代码/配置。因此，没有访问服务器的人已经无法发布部署脚本：）