jenkins用户手册-10-管理之安全管理

安全管理

从企业内网的工作站到连接入开放网络的高性能服务器都可以使用jenkins。为了安全地支持这么广范围的安全和敏感配置的传播，jenkins提供了很多可供选择的配置选项，来授权，编辑，禁用各种安全特性。

对于jenkins的2.0版，很多安全选项是默认开启的，用来保证jenkins环境安全，除非管理员特意禁用特定的保护功能。

这一节将会介绍各种jenkins管理员可用的安全选项，解释提供的保护，和禁用这些选项的利弊权衡。

Web界面上可用的安全选项允许管理员开启，配置或者禁用关键的适用于jenkins所有环境的安全特性。

全局配置

 

JNLP TCP Port（JNLP TCP 端口）

Jenkins使用一个TCP 协议端口来和通过JNLP协议启动的agent进行通讯，例如基于windows的agents。Jenkins的2.0版，默认这个端口是禁用的。

对于想要使用基于JNLP 的agents的管理员而言，两个可选的端口是：

1.      随机的：JNLP端口选用随机方式以避免与jenkins属主（master）的冲突。JNLP随机端口的弊端是它们是在Jenkins 属主（master）的引导下选择的，这使得管理防火墙允许JNLP通过变得困难。

2.      固定的： JNLP端口是由jenkins管理员选择的，重启jenkins属主之后是保持不变的。这使得防火墙允许基于JNLP的agents连接属主的规则变得简单。

访问控制

访问控制是防范未授权使用jenkins环境的主要机制。在jenkins中配置访问控制有两方面主要的配置：

1.      一个安全区，它告诉Jenkins环境如何以及在何处使用来拉取用户(或身份)信息表格。也通常成为“身份验证”。

2.      授权配置，它告诉Jenkins环境，用户和/或组可以访问Jenkins的哪些方面，以及什么访问到程度。

在jenkins内，同时使用安全区和授权配置可以配置非常松散或非常严格的鉴定和授权方案。

另外，一些插件，例如基于角色的授权策略插件，可以扩展访问控制能力，来支持细粒度的鉴权和授权方案。

安全领域

默认情况下，jenkins支持包含一些不同的安全领域。

Servlet容器代理

对于运行jenkins属主servlet容器代理-如jetty-来的身份验证。如果使用这个选项，请查阅servlet容器身份验证文档。

Jenkins自带的用户数据库

使用jenkins自带的内置用户数据存储来验证而不是委托给外部系统。这个在jenkins2.0往后的安装版本中是默认开启的，这也适用于更小的环境中。

Ldap

将所有身份验证委托给配置的LDAP服务器，包括用户和组两种。这个选项在更大的安装组织结构中，已经配置了一个外置的身份提供者，例如LDAP.这个也支持动态目录安装。

 +++这个特性是ldap插件提供的，可能在你的实例中还没有安装。

Unix用户/组数据库

Jenkins属主上的以基于unix的操作系统级身份验证代理。这个模式将也允许重用unix组来进行身份验证。例如jenkins可以配置诸如“everyone in the developmentpers group has administrator access”。为了支持这个特性，jenkins依赖pam，这可能需要配置jenkins环境之外的内容。

 Unix允许用户和组拥有相同的名字。为了消除歧义，使用@符号前缀来强制名字表示为组。例如，@dev将代表dev组，而非dev用户。

插件可以提供额外的安全范围，这可能对于jenkins合并到现有识别系统很有用，例如

.活动目录(https://plugins.jenkins.io/active-directory)

.GitHub身份验证(https://plugins.jenkins.io/github-oauth)

.AtlassianCrowd 2(https://plugins.jenkins.io/crowd2)

身份验证

安全范围，或者身份验证，标志着谁可以访问jenkins环境。另一个难题是授权，标志着他们在jenkins环境中可以访问到什么。默认jenkins支持一些不同的身份验证选项：

。任何人可做任何事情（Anyone can do anything）

 每个人都可以获取jenkins的所有控制权，包括没有登录的匿名用户。Jenkins属主上不要使用这个设置。

。继承模式

与jenkins的行为完全相同。换句话说，如果用户有“管理员”（admin）角色，他们讲被授予控制整个系统的所有权限，其他的（包括匿名用户）将只有只读权限。除了本地测试环境的jenkins属主不要使用这个设置。

。登录用户拥有所有权限

这种模式下，每个登录用户获取jenkins的所有控制权。取决于一个高级选项，匿名用户获取jenkins的只读权限，或者没有任何权限。这种模式有助于在采取行动之前强制用户登录，这样就有了对用户行为的审计跟踪。

。基于矩阵的安全配置

这种授权模式允许粒度控制哪个用户或组可以有哪些在jenkins环境的事件的行为（查看下面的截屏）

。基于项目的矩阵授权策略

这种授权模式是对矩阵安全模式的扩展，它允许额外的访问控制列表（ACLs）,ACLs是在项目配置界面中为每个项目独立定义的。这允许授予特定的用户或组仅访问特定的项目，而不是jenkins环境中的所有项目。使用基于项目矩阵授权模式的ACLs是附加的，在配置全局安全界面中定义的访问授权定义将与特定于项目的acl相结合

基于矩阵的安全和基于项目的矩阵安全策略是矩阵授权策略插件（MatrixAuthorization Strategy Plugin）（https://plugins.jenkins.io/matrix-auth）提供的。jenkins可能不会自己安装。

对于大部分的jenkins环境，基于矩阵的安全提供了最安全也最灵活的保证，因此这被认为是“成品”环境的起点。

图 1.基于矩阵的安全（Matrix-based security）

上面展示的表格能够得到相当广泛，因为每一个表格表示jenkins核心或插件提供的一项权限。鼠标悬浮到权限的上面讲会展示该权限的更多信息。

表格的每一行表示一个用户或者组（也被成为角色）。这包括特殊的名叫“匿名”和“已认证”的条目。“匿名”的条目表示所有授权给没有被授权的用户访问jenkins环境。然而，“已认证”的可以用于授权给所有认证的用户访问jenkins环境。

在矩阵中授予的权限是叠加的。例如，如果用户kohsuke是在“开发”组角色和“管理员”组角色中，那么实际kohsuke被授予的权限将是授予给kohsuke的权限，“开发组”角色的权限，“管理员”组角色的权限，“匿名”的权限，“已认证”的权限五种权限组的合集。

markup 格式

jenkins允许用户输入一系列不同的配置域和文本域。这可能导致用户无意地或蓄意地插入不安全的html或js代码片段。

默认的markup formatter配置是一组流式文本，这可以避免不安全的字符，例如 ‘<’和“&”各自对应的字符实体。

使用安全的html标记格式化器允许用户和管理员注入有用的和携带信息的html代码片段到项目描述和其他地方。

跨域请求伪造攻击（CSRF ）

跨域请求伪造是一种攻击方式，它导致一个未经授权验证的第三方执行请求，使一个应用不能被其他授权的用户正常访问。在jenkins的上下文环境中，CSRF 攻击可以允许一个恶意的执行者，删除项目，修改构建计划，或者更改jenkins系统配置。为了保护对抗这类缺陷，jenkins从2.0版本开始默认开启CSRF配置。 

当这个选项开启，jenkins将会检查任何可能修改jenkins环境中数据的请求上的csrf口令或者面包屑。这包含任何类型的form表单提交和远程api调用，包括使用基础认证的 那些。

强烈建议这个选项留下为启用，包括私有的和完全信任网络上的操作实例。

警告

CSRF 保护可能更多jenkins高级使用上的风险，例如：

.有些jenkins特性，像远程api，当这个选项开启，将会更难使用。查阅远程api调用获取更多信息。

.通过未经充分配置的反向代理访问jenkins可能导致csrf的http访问头被剥夺了访问请求，导致保护动作失效。

.过期的插件，未经csrf保护选项开启情况下测试过的，可能功能能不正确。

更多csrf攻击的信息，可以到OWASP WEBSITE网站访问（https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)）

代理/属主  访问控制

从概念上讲，jenkins属主和代理可以理解为一个聚合的系统，它可以横跨在多个独立的进程和机器上执行。这允许代理询问属主进程更多关于它的可用的信息，例如文件内容等。

对于更大的和成熟的jenkins环境，，一个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的文件。这个文件中的命令是通过web页面写入的。

为了防止jenkins管理员通过web界面改变白名单，请将目录中gui.conf的文件清空，并设置jenkins所在宿主机的系统用户对该文件不可写。

文件访问规则

文件访问规则被用于校验代理访问属主访问请求是否有效。每个文件访问规则是一个三元组。必须包含下面的每个元素。

1.允许/拒绝 如果下面两个参数符合当前的请求，一个允许的条目将会允许请求通过，一个拒绝的条目将会拒绝请求通过，不管后面的条目说的是什么。

2.操作 请求的操作类型。存在下面的6个操作类型值。操作也可以用逗号分隔来组合。逗号分隔的所有的操作值所代表的操作要么全被允许要么全被拒绝。

       1.读（read）：读文件内容或者文件的目录条件

       2.写(write)：写文件内容

       3.创建目录（文件夹）(mkdir)：创建新的目录（文件夹）

       4.创建（create）:在已经存在的目录下创建新的文件

       5.删除（delete）：删除文件或文件夹（目录）

       6.状态（stat）:访问文件或文件夹的元数据，例如时间戳，文件大小，文件访问模式

3.文件路径