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