Jenkins从公司内部网的工作站到达连接到公共互联网的大功率服务器。为了安全地支持这种广泛的安全和威胁配置文件，Jenkins提供了许多配置选项，用于启用，编辑或禁用各种安全功能。 从Jenkins 2.0开始，默认情况下启用了许多安全选项，以确保Jenkins环境保持安全，除非管理员明确禁用某些保护。 本节将介绍Jenkins管理员可用的各种安全选项，解释所提供的保护措施，并对其中某些功能进行权衡。 启用安全性 选中“ 启用安全性”复选框后，自Jenkins 2.0起是默认启用安全性复选框，用户可以使用用户名和密码登录，以执行匿名用户不可用的操作。哪些操作要求用户登录取决于所选择的授权策略及其配置; 默认情况下，匿名用户没有权限，并且登录的用户具有完全的控制权。对于任何非本地（测试）Jenkins环境，应始终启用此复选框。 Web UI的“启用安全性”部分允许Jenkins管理员启用，配置或禁用适用于整个Jenkins环境的关键安全功能。  NLP TCP端口 Jenkins使用TCP端口与通过JNLP协议启动的代理（如基于Windows的代理）进行通信。截至Jenkins 2.0，默认情况下此端口被禁用。 对于希望使用基于JNLP的代理的管理员，两个端口选项是： 随机：JNLP端口是随机选择的，以避免Jenkins主机发生冲突 。随机JNLP端口的缺点是在Jenkins主引导期间选择它们，这使得难以管理允许JNLP流量的防火墙规则。 固定：JNPP端口由Jenkins管理员选择，并且在Jenkins主控器的重新启动之间是一致的。这使得管理防火墙规则更容易，允许基于JNLP的代理连接到主服务器。 访问控制 访问控制是保护Jenkins环境免受未经授权的使用的主要机制。在Jenkins中配置访问控制需要两个方面的配置： 一个安全域，其通知Jenkins环境如何以及在哪里获取用户（或标识）的信息。也被称为“认证”。 授权配置，通知Jenkins环境，哪些用户和/或组在多大程度上可以访问Jenkins的哪些方面。 使用安全领域和授权配置，可以在Jenkins中配置非常轻松或非常刚性的身份验证和授权方案。 此外，一些插件（如 基于角色的授权策略） 插件可以扩展Jenkins的访问控制功能，以支持更细微的身份验证和授权方案。 安全领域 默认情况下Jenkins包括对几个不同安全领域的支持： 委托给servlet容器 用于委托身份验证运行Jenkins主服务器的servlet容器，如 Jetty。如果使用此选项，请参阅servlet容器的身份验证文档。 Jenkins自己的用户数据库 使用Jenkins自己的内置用户数据存储进行身份验证，而不是委派给外部系统。默认情况下，这将启用新的Jenkins 2.0或更高版本的安装，适用于较小的环境。 LDAP 将所有身份验证委托给配置的LDAP服务器，包括用户和组。对于已经配置了外部身份提供程序（如LDAP）的组织中的较大安装，此选项更为常见。这也支持Active Directory安装。 此功能由可能未安装在您的实例上的LDAP插件提供。 Unix用户/组数据库 将认证委托给Jenkins主服务器上的底层Unix操作系统级用户数据库。此模式还允许重新使用Unix组进行授权。例如，Jenkins可以配置为“ developers群组中的所有人都具有管理员访问权限”。为了支持此功能，Jenkins依赖于 PAM ，可能需要在Jenkins环境外配置。 插件可以提供额外的安全领域，这对于将Jenkins纳入现有身份系统可能是有用的，例如： ``` 活动目录 GitHub认证 Atlassian Crowd 2 ``` 授权 安全领域或认证表明谁可以访问Jenkins环境。另一个谜题是授权，这表明他们可以在Jenkins环境中访问什么。默认情况下，Jenkins支持几个不同的授权选项： 所有人都可以控制Jenkins 每个人都可以完全控制Jenkins，包括尚未登录的匿名用户。请勿将本设置用于本地测试Jenkins管理以外的任何其他设置。 传统模式 与`Jenkins<1.164`完全一样。也就是说，如果用户具有“admin”角色，他们将被授予对系统的完全控制权，否则（包括匿名用户）将仅具有读访问权限。不要将本设置用于本地测试Jenkins 管理以外的任何设置。 登录用户可以做任何事情 在这种模式下，每个登录的用户都可以完全控制Jenkins。根据高级选项，匿名用户可以读取Jenkins的访问权限，也可以不访问。此模式有助于强制用户在执行操作之前登录，以便有用户操作的审计跟踪。 基于矩阵的安全性 该授权方案可以精确控制哪些用户和组能够在Jenkins环境中执行哪些操作（请参见下面的屏幕截图）。 基于项目的矩阵授权策略 此授权方案是基于Matrix的安全性的扩展，允许在项目配置屏幕中单独为每个项目定义附加的访问控制列表（ACL）。这允许授予特定用户或组访问指定的项目，而不是Jenkins环境中的所有项目。使用基于项目的矩阵授权定义的ACL是加法的，使得在“配置全局安全性”屏幕中定义的访问权限将与项目特定的ACL组合。 基于矩阵的安全性和基于项目的矩阵授权策略由Matrix授权策略插件提供，可能不会安装在您的Jenkins上。 对于大多数Jenkins环境，基于Matrix的安全性提供最大的安全性和灵活性，因此建议将其作为“生产”环境的起点。  图1.基于矩阵的安全性 上面显示的表可以变得相当宽泛，因为每一列都表示由Jenkins核心或插件提供的权限。将鼠标悬停在权限上将显示有关权限的更多信息。 表中的每一行表示用户或组（也称为“角色”）。这包括名为“匿名”和“认证”的特殊条目。“匿名”条目表示授予访问Jenkins环境的所有未认证用户的权限。而“已认证”可用于向访问环境的所有经过身份验证的用户授予权限。 矩阵中授予的权限是加法的。例如，如果用户“kohsuke”在“开发人员”和“管理员”组中，则授予“kohsuke”的权限将是授予“kohsuke”，“开发人员”，“管理员” ，“认证”和“匿名”。 标记格式器 Jenkins允许用户输入许多不同的配置字段和文本区域，这可能会导致用户无意或恶意地插入不安全的HTML和/或JavaScript。 默认情况下，“ 标记格式化程序”配置设置为“ 纯文本”，将会转义不安全的字符，例如<和&其各自的字符实体。 使用安全的HTML标记格式化程序允许用户和管理员将有用的和信息的HTML片段注入到项目描述和其他地方。 跨站点请求伪造 跨站点请求伪造（或CSRF / XSRF）是一种漏洞，它允许未经授权的第三方通过模仿另一个经过身份验证的用户对Web应用程序执行请求。在Jenkins环境的上下文中，CSRF攻击可能允许恶意actor删除项目，更改构建或修改Jenkins的系统配置。为了防范此类漏洞，默认情况下，CSRF保护已启用，所有Jenkins版本自2.0以来。  启用该选项后，Jenkins将会在可能更改Jenkins环境中的数据的任何请求上检查CSRF令牌或“crumb”。这包括任何表单提交和对远程API的调用，包括使用“基本”身份验证的表单。 这是强烈建议这个选项不要被启用，包括私人，完全可信的网络运行情况。 注意事项 CSRF保护可能会对 Jenkins更高级的使用带来挑战，例如： 某些Jenkins功能（如远程API）在启用此选项时更难使用。 通过配置不正确的反向代理访问Jenkins可能会导致CSRF HTTP头被从请求中删除，导致受保护的操作失败。 未经使用CSRF保护测试的过时插件可能无法正常工作。 有关CSRF漏洞的更多信息，请参见 OWASP网站。 代理/主访问控制 在概念上，Jenkins的管理员和代理人可以被认为是一个凝聚力的系统，恰好在多个离散的过程和机器上执行。这允许代理向主进程请求可用的信息，例如文件的内容等。 对于Jenkins管理员可能启用由其他团队或组织提供的代理的较大或成熟的Jenkins环境，平面代理/主信任模型不足。 引入了代理/主访问控制系统，允许Jenkins管理员在Jenkins主服务器和连接的代理程序之间添加更精细的访问控制定义。  从Jenkins 2.0开始，该子系统默认启用。 自定义访问 对于可能希望允许从代理到Jenkins主机的某些访问模式的高级用户，Jenkins允许管理员从内置访问控制规则创建特定的豁免。  通过遵循上面突出显示的链接，管理员可以编辑命令和文件访问代理/主访问控制规则。 命令 Jenkins及其插件中的“命令”通过其完全限定的类名来标识。大多数这些命令旨在通过主机的请求在代理上执行，但是其中一些命令旨在通过代理的请求在主机上执行。 尚未更新的此子系统的插件可能不会对每个命令所属的类别进行分类，以便当代理请求主机执行不明确允许的命令时，Jenkins将错误地注意并拒绝执行该命令。 在这种情况下，Jenkins管理员可能会将某些命令列入白名单 ，以便在主服务器上执行。  高级 管理员也可以通过.conf 在目录中创建具有扩展名的文件来对类进行白名单JENKINS_HOME/secrets/whitelisted-callables.d/。这些.conf文件的内容应该在单独的行上列出命令名称。 该目录中的所有.conf文件的内容将被Jenkins读取并合并，default.conf在目录中创建一个列出所有已知安全命令的文件。该default.conf文件将每次Jenkins启动时重新编写。 Jenkins还管理一个文件gui.conf，在whitelisted-callables.d 目录中，通过Web UI添加的命令被写入。为了禁用管理员从Web UI更改列入白名单的命令的能力，请gui.conf在目录中放置一个空文件，并更改其权限，以便操作系统用户Jenkins运行时不能写入。 文件访问规则 文件访问规则用于验证从代理向主设备提交的文件访问请求。每个文件访问规则是一个三元组，它必须包含以下每个元素： allow/ deny：如果以下两个参数与正在考虑的当前请求匹配，则allow条目将允许执行请求，并且deny条目将拒绝该请求被拒绝，而不管稍后的规则如何。 操作：请求的操作的类型。存在以下6个值。操作也可以通过逗号分隔值组合。all表示所有列出的操作的值被允许或拒绝。 read：读取文件内容或列出目录条目 write：写文件内容 mkdirs：创建一个新的目录 create：在现有目录中创建一个文件 delete：删除文件或目录 stat：读取文件/目录的元数据，例如时间戳，长度，文件访问模式。 3.文件路径：指定与此规则匹配的文件路径的正则表达式。除了基本的正则表达式语法之外，它还支持以下令牌： <JENKINS_HOME>可以用作前缀来匹配主 JENKINS_HOME目录。 <BUILDDIR>可以用作前缀来匹配构建记录目录，比如/var/lib/jenkins/job/foo/builds/2014-10-17_12-34-56。 <BUILDID>匹配时间戳格式的构建ID，如 2014-10-17_12-34-56。 这些规则是按照顺序排列的，并被应用于规则上。例如，以下规则允许访问JENKINS_HOME 除secrets文件夹之外的所有文件： ``` # To avoid hassle of escaping every '\' on Windows, you can use / even on Windows. deny all <JENKINS_HOME>/secrets/.* allow all <JENKINS_HOME>/.* ``` 规则非常重要！以下规则被错误地写入，因为第二条规则永远不会匹配，并允许所有代理访问下列所有文件和文件夹JENKINS_HOME： ``` allow all <JENKINS_HOME>/.* deny all <JENKINS_HOME>/secrets/.* ``` 高级 管理员还可以通过.conf.在目录中创建扩展名的文件来添加文件访问规则 JENKINS_HOME/secrets/filepath-filters.d/。Jenkins本身30-default.conf在此目录中的引导时生成文件，其中包含默认值，被认为是Jenkins项目的兼容性和安全性之间的最佳平衡。为了禁用这些内置的默认值，请替换30-default.conf为操作系统用户Jenkins不能写入的空文件。 在每次启动时，Jenkins将以 字母顺序读取目录中的所有.conf文件filepath-filters.d，因此，以表示其加载顺序的方式命名文件是一种好习惯。 Jenkins还管理50-gui.conf，在filepath-filters/目录中，其中通过网络用户界面添加文件访问规则写入。为了禁止管理员从Web UI更改文件访问规则的能力，请将空50-gui.conf文件放在目录中，并更改其权限，以便操作系统用户Jenkins运行时不能写入。 禁用 虽然不推荐使用，但如果Jenkins环境中的所有代理程序都可以被认为与主机信任的程度相当“受信任”，则可能会禁用代理/主访问控制功能。 此外，Jenkins环境中的所有用户都应具有对所有已配置项目的访问级别。 管理员可以通过取消选中“ 配置全局安全性”页面上的框来禁用Web UI中的代理/主访问控制。或者，管理员可以使用内容JENKINS_HOME/secrets命名 并重新启动Jenkins 来创建一个文件。slave-to-master-security-kill-switchtrue 大多数Jenkins环境随着时间的推移需要他们的信任模型随着环境的增长而发展。请考虑安排定期的“检查”以查看是否应重新启用所有已禁用的安全设置。