1

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

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

这是我想要的（至少对于 Ant，我们现在没有使用 Maven/Ivy）：

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

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

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

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

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

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

更新 2：信任是一个有趣的词。我们是否认为任何开发人员都可能尝试任何恶意行为？没有。但是，我敢打赌，在一年中使用开发人员更新的构建脚本构建了 30 个项目，将会有几个实例（1）意外破坏项目工作区之外的文件系统区域，以及（2）构建需要花费大量时间才能弄清楚的腐败。我们相信我们所有的开发人员不会搞砸吗？没有。我不相信自己到那个水平，这是肯定的。

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

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

4

3 回答 3

2

这可能不是您可以更改的，但是如果您不能信任开发人员，那么您将遇到更大的问题，那么他们可以或不能对您的构建机器做什么。

你可以用不同的方式来解决这个问题，如果你不能相信将要运行的东西，你可能需要一个专门的人作为构建大师来验证不仅对你的 SCM 所做的更改，而且还要执行构建.

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

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

这将防止人们在 Ant 中请求关闭构建系统以获取不在源代码控制中的资源。

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

于 2009-07-23T18:34:47.363 回答
1

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

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

于 2009-07-24T07:47:14.833 回答
0

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

于 2009-07-23T18:17:03.000 回答