jenkins用户手册-15-进程内脚本认证

Jenkins平台及其部分插件支持用户在系统内运行Groovy脚本，这些脚本的执行功能由以下几种方式提供支持：

. 脚本控制台功能

. Jenkins通道机制

. 扩展版邮件插件

. Groovy插件，该插件在“执行系统Groovy脚本”（Execute system Groovy script）这一操作步骤中被调用

. 1.6版本及以上版本的JobDSL插件

为防止Jenkins受到恶意脚本的影响，上述插件在执行用户提交的脚本时，均运行于一个Groovy沙箱环境中。这种机制有效限制了脚本对系统内部接口的访问权限。管理员可以通过“内置脚本认证”（In-process Script）页面，借助脚本安全插件对潜在危险的方法进行管理，并尽可能地在Jenkins运行环境中允许使用安全的操作方式。

入门指南

脚本安全插件是 Post-install Setup Wizard，该插件会自动完成安装过程，但初始状态下并未包含任何附加的脚本或操作功能。

注：部分早期版本的插件可能存在安全隐患。建议用户前往脚本安全插件页面，查看相关的安全警告列表，以确保所使用的脚本为最新且符合安全标准的版本。

系统内置脚本的安全性主要依赖于两种机制来保障：Groovy沙箱以及脚本认证。其中，Groovy沙箱作为Jenkins通道默认启用的功能之一，允许用户提交脚本化和声明性管道任务，而无需管理员提前进行干预。另一方面，脚本认证机制则赋予管理员权限，使其可以对特定脚本进行审批或拒绝，并且可授权沙箱中的脚本执行额外的方法。

通常情况下，将Groovy沙箱与安全脚本的认证方法签名列表相结合使用效果更佳。因此强烈建议管理员，在无特殊需求的情况下，尽量避免更改这些默认设置。

Groovy 沙箱

为减少对管理员人工操作的依赖性，默认情况下大部分脚本都会运行在Groovy沙箱环境中，这包括所有Jenkins管道任务。该沙箱仅允许执行那些被认定为足够安全、无需信任即可访问的方法子集。采用Groovy沙箱运行的脚本能受到一致性的限制条件约束，这意味着由管理员编写的通道同样会受到非管理用户的权限控制。

当某个脚本尝试调用沙箱中未经过授权的方法或特性时，该脚本将立即终止运行。以下是一个Jenkins通道中可能出现的情况示例：

上述通道在未经过管理员通过内置脚本认证页面对方法签名进行验证之前，将不会被触发执行。

除对方法签名实施认证之外，用户还具备彻底关闭Groovy沙箱的选项，如以下示例所示。若要停用沙箱功能，则需对整个脚本内容进行审查，并由管理员进行人工核准。

脚本授权

管理员可手动验证完整脚本或方法签名，从而赋予其更高的操作自由度，以满足更复杂进程内脚本的需求。当Groovy沙箱功能被关闭，或调用的方法超出内置列表范围时，脚本安全插件将对管理员所管理的已授权脚本及方法清单进行核查。

针对需在Groovy沙箱之外运行的脚本，管理员须在进程内授权页面完成所有相关脚本的审批操作：

当使用Groovy沙箱执行脚本时，若涉及尚未获得授权的签名方法，Jenkins系统将阻止其运行。在脚本得以执行之前，必须由管理员对相应的方法签名进行审批确认。

通过设定权限验证机制

脚本授权提供了三种选择：通过、驳回以及“假定权限验证通过”。前两种选项的含义显而易见，但第三种则需要对内部数据脚本可访问的范围及Jenkins函数内部如何执行权限验证有更深入的理解。

以一个调用hudson.model.AbstractItem.getParent()方法的脚本为例，该方法本身并无潜在威胁，其作用是返回一个包含当前运行流水线或任务所在文件夹或根目录的对象。随后，该方法会调用hudson.model.ItemGroup.getItems()，而getItems()方法将列出根目录或文件夹中的内容，此操作需要Job/读取权限。

这可能意味着如果授权hudson.model.ItemGroup.getItems()方法的签名，则脚本有可能规避系统内置的权限检查机制。

相反，当执行脚本的用户具备相应操作权限，例如Job/读取权限时，选择Approve assuming permissions check通常更为合理。此选项将使脚本执行引擎允许带有签名的方法通过验证。