如何在Hudson中构建Sandbox Ant

Question

我正在评估Hudson构建系统，作为一个集中的“无菌”构建环境，用于具有非常分布式开发的大型公司（从地理和管理角度来看）。一个目标是确保构建仅仅是源控件树和构建脚本（也是该树的一部分）的内容的函数。这样，我们可以确定放入生产环境的代码实际上源自我们的源代码控制系统。

Hudson似乎提供了一个ant脚本，其中包含分配给调用Hudson服务器本身的用户的全部权限。因为我们希望允许各个开发组在没有管理员干预的情况下修改他们的构建脚本，所以我们想要一种方法来将构建过程沙箱化为（1）限制由错误构建脚本引起的潜在危害，以及（2）避免所有游戏可能会将恶意代码插入构建中。

这就是我认为我想要的（至少对于Ant，我们现在不使用Maven / Ivy）：

• Ant构建脚本只能访问其工作区目录
• 它只能从源树中读取（这样可以信任svn更新，不会插入其他代码）。
• 或许可以允许对构建类路径所需的某些目录（Ant分发，JDK等）进行读访问。

我可以想到三种方法来实现这个：

1. 编写一个使用Java安全模型约束访问的ant包装器
2. 为每个构建创建一个用户并分配上述权限。在此用户空间中启动构建。
3. （已更新）使用Linux“Jails”可以避免为每个构建过程创建新用户帐户的负担。我对这些知之甚少，但我们将在最近使用RedHatEL发行版的Linux机器上运行我们的构建。

我是否正确地考虑了这个问题？其他人做了什么？

更新：这家伙考虑了chroot监狱的想法：

https://www.thebedells.org/blog/2008/02/29/l33t-iphone-c0d1ng-ski1lz

更新2：信任是一个有趣的词。我们是否认为任何开发者都可能尝试恶意攻击？不。但是，我敢打赌，通过开发人员更新的构建脚本，在一年的时间内建立了30个项目，将会有以下几个实例：（1）项目工作区外的文件系统区域意外崩溃，以及（2）构建需要花费大量时间才能搞清楚的腐败。我们是否相信所有开发人员都不会陷入困境？不。我不相信自己到那个级别，这是肯定的。

关于恶意代码插入，真正的目标是，如果有人认为可能发生了这样的事情，就能够排除考虑的可能性。

此外，通过控制，开发人员可以修改自己的构建脚本并对其进行测试，而不必担心灾难。这将导致更多构建“创新”和更高级别的质量，由构建过程（单元测试执行等）强制执行。

Answer 1

这可能不是你可以改变的东西，但是如果你不能相信开发人员，那么你就会遇到一个更大的问题，那么他们能够或不能对你的构建机器做些什​​么。

你可以用不同的方式解决这个问题，如果你不相信将要运行的东西，你可能需要一个专门的人来充当构建大师来验证你的SCM的变化，而且执行构建。

然后，您有一个明确的构建责任路径，在构建之后不会被修改，并且只来自该构建系统。

另一个选择是防止来自构建计算机的出站请求仅允许某些资源（如SCM服务器）和其他可操作的网络资源（如电子邮件，操作系统更新等）。

这可以防止人们在Ant中向请求提供请求，而不是源代码控制中的资源。

使用Hudson时，您可以设置主/从配置，然后不允许在主服务器上执行构建。如果将Slaves配置为虚拟机，可以轻松创建和恢复，那么您不必担心会弄乱构建环境。如果您对这些Slaves应用防火墙，那么它应该可以解决您的隔离需求。

Answer 2

我建议您有1个Hudson主实例，这是每个人查看/配置/构建项目的入口点。然后你可以设置多个Hudson从属服务器，它们很可能是虚拟机或（如果可能的话，不是100％确定）只是在同一台机器上没有特权的用户。

完成此设置后，您可以将构建绑定到特定节点，这些节点不允许（通过虚拟机边界或Linux文件系统权限）修改其他工作区。

Answer 3

哈德森将建造多少个项目？考虑到你所表达的安全问题，也许一个Hudson实例会太大。您是否考虑过分发Hudson实例 - 每个团队一个。这完全避免了许可问题。