jenkins用户手册-10-管理之安全管理
安全管理
从企业内部网络中的工作站到接入开放网络的高性能服务器，均可部署Jenkins。为确保如此广泛范围内安全与敏感配置的传输过程得到有效控制，Jenkins提供了多样化的配置选项，以实现对各类安全功能的授权、编辑及禁用操作。
在Jenkins 2.0版本中，众多安全选项默认处于启用状态，旨在保障Jenkins运行环境的安全性，除非管理员主动关闭某些特定的安全防护机制。
本节将详细介绍Jenkins管理员可使用的各类安全配置选项，阐述所提供的防护措施，并分析关闭这些选项可能带来的利弊影响。
Web界面上提供的安全配置选项使管理员能够启用、调整或停用适用于所有Jenkins环境的关键安全功能。
全局配置
JNLP TCP 端口（JNLP TCP Port）
Jenkins 通过 TCP 协议端口与基于 JNLP 协议启动的 agent 实现通信，例如运行于 Windows 系统的 agent。在 Jenkins 2.0 版本中，默认情况下该端口处于禁用状态。
对于希望使用 JNLP 协议 agent 的管理员而言，存在两种可选的端口配置方式：
-
随机分配：JNLP 端口以随机方式选择，旨在避免与 Jenkins 主节点（master）产生冲突。然而，这种随机性也带来了管理上的挑战，因为防火墙规则需要根据主节点引导时所选择的端口进行调整，从而增加了配置复杂度。
-
固定分配：由管理员手动指定 JNLP 端口，并且在 Jenkins 主节点重启后仍保持不变。这种方式简化了防火墙策略的设置过程，使得基于 JNLP 的 agent 可以更便捷地连接到主节点。
访问控制
访问控制机制是防止未经授权访问 Jenkins 环境的关键手段。在 Jenkins 中配置访问控制主要涉及两个方面的设置：
-
安全域：用于定义 Jenkins 如何以及从何处获取用户或身份信息表。这一部分通常被称为“身份验证”。
-
授权配置：用于确定用户和/或组可以访问 Jenkins 的哪些部分以及其权限范围。
通过结合安全域与授权配置，可以在 Jenkins 中实现从较为宽松到高度严格的鉴权和授权策略。此外，一些插件如基于角色的授权策略插件可进一步扩展访问控制功能，支持更加精细的身份验证与授权机制。
安全域
默认情况下，Jenkins 支持多种不同的安全域类型。
Servlet 容器代理
针对运行于 Servlet 容器代理（如 Jetty）上的 Jenkins 主节点的身份验证方式，请参考 Servlet 容器身份验证的相关文档内容。
Jenkins 内置用户数据库
采用 Jenkins 自带的内置用户数据库进行身份验证而非依赖外部系统的方式，在 Jenkins 2.0 及以上版本中默认启用，并适用于规模较小的部署环境。
LDAP 配置
将所有身份验证请求委托给已配置的 LDAP 服务器处理，包括用户和组信息管理。此选项适用于已建立外部身份提供者的大型组织结构，并支持动态目录服务安装。
+++此功能由 LDAP 插件提供支持，在您的实例中可能尚未安装该插件。
Unix 用户/组数据库
该模式利用 Unix 操作系统级别的身份认证代理对运行于 Unix 系统上的 Jenkins 主节点进行认证处理，并允许重复使用 Unix 组来进行权限识别操作。
例如可以设定“developmentpers 组中的所有成员都具有管理员权限”。为了实现这一功能,需要借助 PAM (Pluggable Authentication Modules) 技术,这可能涉及到在 Jenkins 运行环境之外进行额外配置。
值得注意的是,Unix 允许用户和组拥有相同的名称标识,为避免混淆,建议使用 @ 符号作为前缀来明确表示组名,如 @dev 表示 dev 组而非 dev 用户。
此外还有其他插件能够提供更多种类的安全范围定义选项,这对于将 Jenkin 集成进现有识别系统非常有帮助：
- 活动目录 (https://plugins.jenkins.io/active-directory))
- GitHub 身份认证 (https://plugins.jenkins.io/github-oauth))
- AtlassianCrowd 2 (https://plugins.jenkins.io/crowd2)
身份验证
安全域或称作身份验证机制决定了哪些人可以进入 Jenkin 环境；而另一个重要环节是授权机制，则用于界定他们在环境中能够接触到的内容范围。
默认情况下,Jenkin 支持几种不同的身份验证选项:
-
任何人可做任何事情（Anyone can do anything）
每个人都可以获得 Jenkin 的全部控制权,包括未登录状态下的匿名用户也具备完全权限。
注意:请勿在生产环境中的 Jenkin 主节点上启用此设置。 -
继承模式
该模式下,Jenkin 的行为完全一致。
换句话说,如果某个用户被赋予了"管理员"(admin) 角色,则他将获得对整个系统的全部权限；而对于其他人员(包括匿名访客),他们只能获得只读权限。
除非是在本地测试环境中,Jenkin 主节点上也不建议启用这个设置。 -
登录用户拥有所有权限
在此模式下每个成功登录的用户都将获得完整的 Jenkin 控制权。
依据一个高级选项的不同设置情况,匿名访客可以获得只读权限或者完全无任何权限。
这种模式有助于强制要求所有操作必须经过登录才能执行从而实现对用户行为的有效审计追踪。 -
基于矩阵的安全配置
这种授权模型允许对特定用户的访问行为实施细致入微的管控(详情请参见下方截图) -
基于项目的矩阵授权策略
这是对矩阵安全模型的一种拓展形式,它允许为每个项目单独定义附加访问控制列表(ACLs)。
这样就可以授予特定个体或团体仅能访问某些特定项目而不能接触其它项目的权利。
采用基于项目矩阵授权策略所定义出的 ACLs 是附加性质的——它们会与全局安全界面中设定好的基础访问规则相结合
上述提到的各种矩阵型安全管理方案均来自于矩阵授权策略插件(MatrixAuthorization Strategy Plugin) ((https://plugins.jenkins.io/matrix-auth）提供的。jenkins可能不会自己安装。)
对于大多数 Jenkin 实施场景而言,"基于矩阵的安全"提供了最为全面且灵活的安全保障措施,
因此通常被视作构建成熟环境时的理想起点
图 1. 基于矩阵的安全（Matrix-based security）
上述所展示的表格具有广泛的适用性，因为每个表格用于表示Jenkins核心功能或插件所提供的某种权限。当鼠标悬停在权限上时，将显示与该权限相关的额外信息。
表格中的每一行对应一个用户或组（也被称为角色）。其中包括两个特殊的条目，分别名为“匿名”和“已认证”。“匿名”条目用于授权未经过身份验证的用户访问Jenkins环境，而“已认证”条目则用于授权所有已通过身份验证的用户访问Jenkins环境。
在矩阵中赋予的权限具有叠加性质。例如，如果用户kohsuke同时属于“开发”组和“管理员”组，那么他实际获得的权限将包括其个人被授予的权限、“开发组”的权限、“管理员组”的权限、“匿名”的权限以及“已认证”的权限这五类权限的综合。
Markup格式
Jenkins允许用户输入多种配置域和文本域，这可能导致用户无意或故意插入不安全的HTML或JavaScript代码片段。
默认情况下，Markup格式化器配置为一组流式文本内容，以防止出现不安全字符，如‘<’和“&”等符号，并将其转换为对应的字符实体形式。
使用安全的HTML标记格式化器可以允许用户及管理员在项目描述及其他位置插入具有实用价值且包含信息内容的HTML代码片段。
跨域请求伪造攻击（CSRF）
跨域请求伪造是一种攻击手段，它使未经授权验证的第三方能够执行请求操作，并导致应用程序无法被合法授权用户正常访问。在Jenkins的具体应用环境中，CSRF攻击可能使恶意攻击者删除项目、修改构建任务计划或更改Jenkins系统的配置信息。为防范此类漏洞问题，自Jenkins 2.0版本起，默认开启了CSRF防护配置。
启用该选项后，Jenkins将对所有可能修改其环境数据的请求进行CSRF令牌或面包屑验证，这涵盖各类表单提交及远程API调用，包括采用基础认证的方式。
强烈建议在所有场景下保持此选项的启用状态，无论是私有网络还是完全信任的环境中。
警告
CSRF防护机制可能会对Jenkins的一些高级操作带来潜在影响，例如：
. 部分Jenkins功能（如远程API），在开启该选项后使用将变得更加复杂。建议查阅相关文档以了解远程API调用的具体细节。
. 若通过配置不完善的反向代理访问Jenkins，可能导致CSRF相关的HTTP头部信息丢失，从而使得防护机制失效。
. 一些未经过CSRF保护选项测试的老版本插件，在该选项未启用时可能无法正常运行。
若想了解更多关于CSRF攻击的信息，请访问OWASP官网（https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)））。
代理/属主访问控制
从概念上来看，Jenkins中的属主与代理可视为一个分布式系统，能够跨多个独立进程和机器执行任务。这一机制允许代理节点向属主进程请求更多相关信息，如文件内容等。
对于规模较大且较为成熟的Jenkins部署环境而言，仅依赖单一的代理/属主信任模式已难以满足需求。因此，引入了代理/属主访问控制系统以支持管理员定义更精细的授权策略，在Jenkins属主与相关代理之间实施更严格的访问控制措施。
在jenkins2.0系统中，该子系统的功能默认处于启用状态。
定制访问权限
针对高级用户及普通用户而言，他们或许期望能够设定特定的从代理至jenkins属主的访问方式。为此，jenkins平台提供了相应的机制，使管理员能够在内置的访问控制规则中，为特定从代理设置例外权限。
【通过追踪上图中被高亮显示的框，管理员能够对代理/属主访问控制规则所涉及的命令及访问文件进行编辑操作。
命令
在Jenkins系统中，命令与插件内的“命令”是依据其完整的限定名称来进行区分的。这些命令大部分是代理向属主发起执行请求的内容。不过也存在部分命令是由属主向代理发出执行请求的。
目前在子系统内部尚未完成更新的插件中，其包含的命令尚无法被归入到相应的分类之中。因此，当代理尝试请求属主执行一个未被明确授权的命令时，Jenkins将基于安全原则进行错误提示，并拒绝该命令的执行。
在此类情况下，Jenkins管理员可通过设定“白名单”机制，将特定命令纳入其中，从而允许属主对白名单内的命令进行执行操作。
_
_**
_
_
**_
高级用法
系统管理员还能够借助生成带有.conf扩展名的文件，对白名单中的条目进行分类管理。此类文件应放置于 JENKINS_HOME/secrets/whitelisted-callables.d/ 路径下。每一个.conf格式的文件中，可按行输入不同的命令名称，以此实现对允许执行命令的明确列举。default.conf
**目录中的所有.conf文件中的内容将会被jenkins读取，并且这些内容中已被确认为是安全的命令会合并创建一个新的default.conf文件。创建的**default.conf在当前目录下。**** **每次 Jenkins boots启动的时候，**default.conf文件将被新的内容所替代。
Jenkins同样会管理位于whitelisted-callables.d目录下，名为gui.conf的文件。该文件中的命令是通过网页界面进行输入的。
为避免Jenkins管理员利用网页界面修改白名单内容，建议将目录中的gui.conf文件内容清空，并确保Jenkins所运行的宿主机系统用户对该文件不具备写入权限。
文件访问规则
文件访问规则用于验证代理访问是否属于合法请求。每个规则由一个三元组构成，且必须包含以下三个要素。
1.允许/拒绝
若后续两个参数与当前请求相匹配，则允许条目将使请求通过，而拒绝条目则会阻止请求继续处理，无论后续是否存在其他条目。
2.操作
表示请求的操作类型。共有六种可选的操作类型值。操作也可通过逗号分隔的方式组合使用。所有以逗号分隔的操作值要么全部被允许，要么全部被拒绝。
1.读（read）：读取文件内容或目录信息
2.写（write）：写入文件内容
3.创建目录（mkdir）：新建一个目录（文件夹）
4.创建（create）：在已有目录中新建一个文件
5.删除（delete）：删除文件或目录（文件夹）
6.状态（stat）：获取文件或目录的元数据信息，例如时间戳、大小及访问权限等
- 文件路径
匹配路径的正则表达式规则。除了支持基本的正则表达式语法外，还支持以下符号：
a.<JENKINS_HOME>可用于匹配<JENKINS_HOME>主目录路径前缀
b./var/lib/jenkins/job/foo/builds/2014-10-17_12-34-56
c.2014-10-17_12-34-56
规则具有顺序性，并按照设定顺序依次应用（即上述第1、2、3项的顺序）。首先匹配成功的规则即为生效规则。例如，以下配置将允许访问Jenkins主目录下的所有文件，但排除secret目录。
为了避免Windows系统中使用'/'时可能出现的转义问题，在Windows平台上也可以使用''作为替代。
deny all <JENKINS_HOME>/secrets/.*
allow all <JENKINS_HOME>/.*
allow all <JENKINS_HOME>/.*
deny all <JENKINS_HOME>/secrets/.*
AI实现代码编写功能的AI代码生成技术
高级配置方式
系统管理员可在JENKINS_HOME/secrets/filepath-filters.d/目录中添加后缀为.conf的扩展配置文件，以定义额外的访问控制策略。Jenkins在启动过程中会自动在该目录下生成30-default.conf文件，其中预置了兼顾安全与性能的默认访问规则。若需禁用该默认配置文件，可将其替换为空文件，并确保该文件对Jenkins运行所依赖的操作系统账户具有不可写权限。
每次Jenkins服务启动时，系统将按照字典顺序读取filepath-filters.d目录下所有以.conf为后缀的配置文件。因此，采用具有明确加载顺序指示作用的命名规范是一种良好的实践方式。
Jenkins还会管理 filepath-filters/目录下的50-gui.conf文件，此文件中的访问权限设置可通过Web界面进行修改。为了防止管理员通过图形界面更改相关权限设置，建议将50-gui.conf文件内容清空，并调整其访问权限，确保Jenkins运行账户对该文件无写入权限。
禁用功能说明
尽管不推荐使用此方法，但在特定情况下，如果Jenkins环境中所有代理节点与主节点具有相同的权限信任等级，则可以考虑禁用代理/主节点的控制功能。
此外，在Jenkins环境中所有用户应当具备与已配置项目一致的访问权限级别。
管理员可通过Web界面中Configure Global Security页面取消勾选相关复选框的方式禁用代理/主节点的访问控制策略。
或者，在JENKINS_HOME / secrets目录下创建名为slave -to-master- securi- kill- switch的配置文件，并在其中写入true和重启Jenkins的内容以实现相同效果。
随着系统运行时间的增长，大多数Jenkins环境中的信任模型也需要随之演进。建议定期执行“检查”操作，确认是否需要重新启用之前被禁用的安全设置。
1.www.owasp.org/index.php/Cross-Site_Request_Forgery
2. 自版本1.587及1.580.1开始发布