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