JNLP TCP Port

Jekins使用一个TCP端口同通过JNLP协议启动的代代理通信。

如果管理员希望使用基于JNLP的代理，选择使用端口有两咱方案：

  • Random： 端口随机，以避免同Jenkins主服务端口冲突。缺陷是随机分配JNLP端口发生在Jenkins主服务引导期间，使得很难设置有效的防火墙规则以允许JNLP端口的通过。
  • Fixed:由管理员指定，可避免Random方案中的缺陷，但需小心端口的冲突。

Access Control

访问控制是安全隔离Jenkins非授权使用的重要机制，在Jenkins中，如下两方面配置是很有必要配置于访问配置的：

  • Security Realm：配置用户来源。
  • Authorization:配置某个用户可以访问哪些内容。

另外，一些插件比如插件：role-strategy[Role-based Authorization Strategy]插件可以扩展Jenkins的访问控制扩展功能。

Security Realm

Jenkins默认支持的Security Realms:

  • Delegate to servlet container:委托运行Jenkins主服务的servlet容器认证，比如Jetty.如果使用此选项，请参阅servlet容器的认证文档。
  • Jenkins’s own user database:此模式在Jenkins2.0及之后版本为默认。自身验证，不委托外部系统。适用于小量情景。
  • LDAP：委托所有的认证给配置的LDAP服务器，包括所有的用户和所有的组。适用于大量情景，此功能由插件:ldap[LDAP plugin]插件扩展。
  • Unix User/group database:委托给运行Jenkins服务的Unix系统的用户数据库。此种模式允许重用unix系统组。
  • 其他一些可用插件：
  • plugin:active-directory[Active Directory]
  • plugin:github-oauth[GitHub Authentication]
  • plugin:crowd2[Atlassian Crowd2]

Authorization

Security Realm搞定了谁可以访问Jenkins环境，而Authorization则搞定了用户在Jenkins环境中可以访问的内容。默认情况下，Jenkins支持的授权选项：

  • Anyone can do anything:也就是任意人可干任何事，即所有人都有Jenkins的全部权限，包括尚未登录的匿名用户。那义乌如果不是本地内部测试，不要使用此选项。
  • Legacy mode:管理员角色的用户拥有全部的权限，其他用户包括匿名用户只有Read访问权限。同样非本地内部测试，不推荐使用。
  • Logged in users can do anything:即登录的用户可以干任意事。即只要登录就有所有的权限。使用一个高级选项，可以使匿名登录用户只有Read访问权限或者没有访问权限，可以强制用户在操作前先登录，以便于追踪用户操作。
  • Matrix-based security:此方案允许细粒度的控制哪些用户和组在Jenkins中可以执行哪些操作。
  • Project-based Matrix Authorization Strategy:是矩阵安全方案的扩展方案，允许定义每个项目的的权限访问列表，这就使得分配特定用户和组只能访问指定项目成为现实。

注：Matrix-based security和Project-based Matrix Authorization Strategy由插件:matrix-auth[Matrix Authorization Strategy Plugin]提供。

注：强列推荐Prevent Cross Site Request Forgery exploits（阻止跨域请求模仿）保持启用。

Agent -> Master Access Control

Jenkins主服务在关于客户端可以发送什么样的命令是非常严格的。很不幸，这使得一些插件功能无法正常工作，因为那插件没有指定哪些命令可以运行，哪些不能。伴随着插件开发对于此的修改，管理员可以标记一些可以被客户端发送的命令（白名单）。

管理员也可以通过在JENKINS_HOME/secrets/whitelisted.d/目录下创建.conf结尾的文件设置白名单。白名单中命令名称需单行显示。

Jenkins会读取此目录下所有.conf结尾的文件并合并后创建一个包含所有安全命令的default.conf的文件，default.conf文件在每次Jenkins启动时都被重写。

Jenkins也管理着whitelisted-callables.d目录下的一个叫做gui.conf的文件，是通过Web UI写入的白各命令存储文件，如果要标用可将些文件置空，设置Jenkins不可写权限。

File Access Rules

文件访问规则用于验证文件访问请求，每个规则都由以下三部分组成：

  • allow/deny:如果现有请求匹配下面两个参数，那么allow表示允许，deny表示拒绝。
  • operation:请求的操作类型，可以是一个也可以是多个由逗号分隔的如下类型值(或者以all表示以下所有)：
  • read:读取文件内容或者查看目录列表。
  • write:写入文件内容
  • mkdirs:创建文件目录
  • create:在已存在目录中创建文件
  • delete:删除文件或者目录
  • stat:读取文件或者目录的元数据，如时间戳、长度、文件访问模型等
  • file path:文件路径，正则匹配，同时支持如下映射：
  • ：可用做匹配主服务的JENKINS_HOME目录。
  • :可用做匹配构建记录目录，如/var/lib/jenkins/job/foo/builds/2014-10-17_12-34-56
  • ：匹配构建ID，时间戳格式，像2014-10-17_12-34-56

文件访问规则是有序的，优先匹配，最先匹配到的执行，比如如下规则表示允许访问JENKINS_HOME目录下的除secrets目录外的秘有文件：

deny all <JENKINS_HOME>/secrets/.*
allow all <JENKINS_HOME>/.*

顺序很重要，如下第二条规则将永远都不会执行：

allow all <JENKINS_HOME>/.*
deny all <JENKINS_HOME>/secrets/.*

另外管理员也可以通过在JENKINS_HOME/secrets/filepath-filters.d/目录下创建以.conf结尾的文件来添加文件访问规则，Jenkins自身生成的默认规则存储在此目录下的名叫30-default.conf文件中，如果要禁用此默认设置的规则，可清空则文件，设置些文件为Jenkins启动用户Jenkins不可写。

每次启动，Jenkins都会按字母顺序读取filepath-filters.d目录下所有的.conf文件，因此在以某种规则命名.conf文件来预示他们的加载顺序是一种非常好的选择。

filepath-filters目录下还有个被Jenkins管理的文件叫50-gui.conf，是通过Web UI写入的文件访问规则存储地。如果要限制管理员通过Web UI改变文件访问规则，可以在此目录下放一个空的50-gui.conf文件，同样设置些文件为Jenkins启动用户Jenkins不可写。

注：管理员可以通过Web UI的Configure Global Security页面禁用Agent/Master Access Control，也可以在JENKINS_HOME/secrets目录中创建一个叫slave-to-master-security-kill-switch的文件，添加内容true，然后重启以禁用Agent/Master Access Control.