木偶安全和networking拓扑

背景:

我终于留出了一些时间来join21世纪,看看木偶

就目前来看,我们版本控制在办公室内部保存的存储库中的所有服务器configuration。 当需要更新时,更改将被重新检入到回购站中,并手动推送到相关机器。 这通常意味着SFTP到远程计算机,然后从shell中移动文件到相应的权限。

所以我希望木偶将成为我们已经拥有的一个简单而又惊人的扩展。

现在我考虑我们目前必须合理安全的过程。 假设我们的内部networking总是比我们的数据中心的公共networking更安全。

  • 这个过程总是一种方式。 变化从一个安全的环境转到不安全的环境。

  • 主店在最安全的地方。 通过窃取configuration或发送恶意修改的风险大大降低。

题:

从我所了解的Puppet服务器/客户端模型来看,客户端直接从服务器端查询并取消更新。 stream量是SSL封装的,所以不能被拦截或欺骗。 但是它与我们目前所做的不同,因为Puppet服务器需要在公共场所托pipe。 无论是集中式的,还是每个我们维护的数据中心站点。

所以我想知道:

  • 我是否从推拉转变为不必要的偏执?

  • 我在公共networking上集中存储所有这些信息是不必要的偏执狂?

  • 其他人如何维护多个networking – 每个站点单独的服务器?


2009年7月30日更新:

我想我的其他重大问题之一是放置,所以必须相信一台机器。 傀儡(s)将被防火墙,担保等。 但即使如此,任何有听音服务的公共机器都有一定规模的攻击面。

据推测,如果主人有权更新任何一个傀儡客户的任何文件,那么妥协将最终导致所有客户的妥协。 可以这么说,“国王之王”。

  • 这个假设是否正确?

  • 有什么办法可以减轻吗?

因为我有时会将密码存储在模块中的variables中,为了能够部署应用程序而无需手动完成configuration,这意味着我无法在公共服务器上正常放置我的木偶回购。 这样做意味着攻击puppetmaster将允许获得我们所有服务器上所有不同应用程序的一些应用程序或db密码。

所以我的傀儡大师在我们的办公室专用networking,我不在服务器上运行puppetd守护进程。 当我需要部署时,我从私有networking使用SSH到服务器,创build隧道和远程调用puppetd。
诀窍不是设置远程隧道和木偶客户端连接到puppetmaster,而是连接到一个接受http connect的代理,并且可以到达私人networking上的puppetmaster服务器。 否则木偶会因为与证书的主机名冲突而拒绝提取

# From a machine inside privatenet.net : ssh -R 3128:httpconnectproxy.privatenet.net:3128 \ -t remoteclient.publicnetwork.net \ sudo /usr/sbin/puppetd --server puppetmaster.privatenet.net \ --http_proxy_host localhost --http_proxy_port 3128 \ --waitforcert 60 --test –-verbose 

它适合我,希望它可以帮助你

我们有两个网站,我们的办公室和我们的可乐。 每个网站都有自己的傀儡大师。 我们build立了一个具有以下结构的svn仓库:

 root/office root/office/manifests/site.pp root/office/modules root/colo root/colo/manifests/site.pp root/colo/modules root/modules 

每个站点下的modules目录是一个svn:externals目录,返回到顶层模块目录。 这意味着他们共享完全相同的模块目录。 然后我们确保绝大多数我们编写的类都在modules目录下,并被这两个站点使用。 这有很好的优势,迫使我们一般思考,而不是把一个class级绑定到一个特定的网站。

至于安全性,我们将我们的puppetmaster(以及我们的其他networking)托pipe在我们的防火墙之后,所以我们不关心集中存储configuration。 puppetmaster只会发送configuration给它信任的主机。 显然你需要保持服务器的安全。

我不能判断你的偏执狂有多必要,这很大程度上取决于你的环境。 但是,我可以放心地说,现有configuration的两个主要点仍然适用。 您可以确保您的更改从安全的环境(您办公室的存储库)遍历到不太安全的环境,无论您的木偶大师在哪里。 你把这个过程从SFTP转换到一堆服务器上,手动把文件放到SFTP中去,给puppetmaster,让puppet分发这些文件并把它们放在正确的地方。 您的主店仍然是存储库,您的风险得到缓解。

我不相信推或拉本身就比其他模式更安全。 Puppet在保证传输过程中的安全方面做了很多工作,同时也validation了客户端和服务器的身份,以确保双向的信任。

至于多个networking – 我们处理一个中央“主”傀儡大师,在每个地点的卫星傀儡大师作为中央主人的客户。

一种devise方法是在系统的每个站点都有一个puppetmaster,并使用部署工具来推动对puppetmasters的更改。 (使用Git钩子也可以)。

这将保持您对公共networking服务的关注,因为傀儡networkingstream量只是内部的。

也可以将清单推送给每个服务器,让puppet客户端parsing清单并应用相关的configuration。

虽然你说“外在”,我真的怀疑任意的人需要连接到你的傀儡大师。 你总是可以投入一个VPN。 我的一个朋友曾经问我:“如果连接是安全的,你需要担心协议的安全性吗? 虽然我不同意这种态度,但额外的一层永远不会伤害我的个人偏执狂。 此外,它的隧道隧道的乐趣。

cfengine的作者马克·伯吉斯(Mark Burgess)和一位大学教授(这个傀儡似乎欠了它的遗产)写了很多关于推拉的文章。 他声称拉本来就更加安全。 如果你看看cfengine网站,他们在17年内只有1次networking安全事件。 Burgess声称这是因为拉式devise。 我认为一个妥协点是不可避免的。 我会更关心这一点的攻击路线。

如果你愿意,你可以在没有中央大师的情况下运行木偶。 我见过的一种方法是使用git存储库,并且只有在标记由gpg密钥的预设列表之一签名时才会合并和部署更新。 人们甚至计算出如何获得存储configuration(例如,用于在另一个服务器上处理的资源上在中央服务器上设置nagios监视)。

因此,如果中央git服务器被入侵,其他服务器将不会再应用任何更新。 gpg密钥将在系统pipe理员笔记本电脑或其他东西,以及一些撤销密钥的方式。

阅读更多在http://current.workingdirectory.net/posts/2011/puppet-without-masters/