当要围绕jenkins的功能来具体实现一个小团队的ci&cd系统时,需要从整体需求来设计这一套系统要实现的功能以及具体的实现形式。
首先考虑用户,系统给谁用,权限需不需要控制,权限如何隔离;
其次会涉及多少个环境,环境间如何隔离,不同环境间的信息如何同步;
综上,这里会介绍jenkins中两块内容,一是用户及权限的配置,另外一块与权限紧密联系的jenkins任务的组织方式,比如文件夹类型的任务。
这里选择用户系统,jenkins支持ldap用户认证,可以跟既有的用户体系打通方便进行统一管理。
授权策略可基于插件支持多种授权模式,这里总体会介绍以下几种: 安全矩阵、项目矩阵授权、基于目录授权和基于角色授权。
用户系统和授权策略可以自由组合,根据实际需要选择比较适合的一种组合方式。
用户系统使用jenkins专有用户数据库的时候,不需要进行额外的设置。
如上图所示,(需提前配置好ldap服务器)根据设置好的ldap服务信息填入所需信息.
server ldap的服务地址
rootdn ldap的根域
manager DN ldap的管理员帐号
manager Password ldap的管理密码
再下面是ldap里属性与jenkins用户的字段对应关系;
displayname 对应jenkins里用户所显示的名字
mail 对应jenkins用户的邮箱地址
cn={0} 确定用户认证时里cn作为搜索及认证关键字,对应jenkins用户名.
以下配置完成后,可测试配置是否正确。成功后即可通过ldap的用户登录jenkins系统,但此时登录后的用户,拥有什么样的权限是由“授权策略”部分的配置决定的。
参考上图, Add user 在安全矩阵中增加一个用户,然后根据所需在增加的用户对应的复选框内选择所需要的权限,从而实现对单个用户的权限控制。
注意这里的权限控制是对所有任务生效的,无法根据不同的任务分配不同的权限。
涉及到的权限说明:(其他类型的权限策略中所涉及到的权限与此类似)
分类 | 全部 | 凭据 | NODE(slave节点) | 任务 | 运行 | 视图 | SCM |
权限说明 | administer(管理员) | View(查看凭据的权限) | Disconnect(断开连接的权限-下线) | Build(job的构建权限) | Delete(删除job的运行记录) | Configure(配置视图的权限) | Tag(允许用户在代码库中给指定的构建创建新的标签) |
| Read (全部只读) | Update(更新权限) | Delete(删除从节点的权限) | Cancel(取消job的权限) | Replay(执行构建后的流水线权限) | Create(允许用户创建视图) |
|
|
| ManageDomains(管理域权限) | Create(创建从节点的权限) | Configure(配置任务的权限) | Update(允许用户修改一次构建的属性或参数信息) | Delete(删除视图) |
|
|
| Delete(删除凭据) | Connect(连接从节点的权限-上线) | Create(创建job的权限) |
| Read(视图的只读权限) |
|
|
| Create(创建凭据) | Configure(配置从节点的权限) | Delete(删除job的权限) |
|
|
|
|
|
| Build(从节点上任务的构建权限) | Discover(查找任务的权限) |
|
|
|
|
|
|
| Move(移动job的权限) |
|
|
|
|
|
|
| Read(job的只读权限) |
|
|
|
|
|
|
| Workspace(检查workspace的权限) |
|
|
|
这种授权方式对上面安全矩阵的功能强化,在整体权限控制的基础上,再增加对job粒度的权限控制。
参考上图在,项目矩阵中增加test用户,可以实现与安全矩阵同样的功能。
注: 此处应该给认证用户增加全局只读权限,否则只配置项目上的安全矩阵的话,会出现以下错误。
具体应用时选择一个job,进入配置界面,选择“启用项目安全”,可以看到弹出一个与“系统管理”中类似的权限矩阵。如下图增加用户,并选择所需的权限。
如上图,策略配置完成后,使用test用户登录jenkins,成功登录后,只能看到已分配的项目权限。
使用Folder-based Authorization Strategy插件支持基于文件目录的权限控制,使用前的话确认一下是否有这个插件,如果没有需要单独安装一下。
系统管理,启用基于文件目录的授权策略。
具体的策略配置,在系统配置中进入权限配置页面。
首先创建一个全局只读Role,避免授权之后的帐户登录后报错。
新增成功后在这里分配权限。
常规使用新建一个目录权限角色:
首先创建一个目录,并在这个目录下创建一个任务。
选择目录,支持对多个目录进行权限绑定,按住Ctrl单击即可实现。
Permissions支持多选,同样的操作方法。
注:基于文件目录的授权的缺点就是角色创建时,操作不太方便。已有权限的展示不太友好,角色在创建完给其他用户授权的时候无法清晰明了的看到整体的授权状态。
分配权限,参考上图,绑定对应的用户即可。
用test用户登录验证,只能看到testdir目录及目录下的任务。
基于目录权限策略的优点在于可以把一系列的任务放到一个目录下,并分配给指定的帐号,这个帐号可以在这个目录下,做任何操作还不会影响到其他的任务或配置,也无法读到其他的内容。在隔离上做的比较好。
同样安装插件Role-based Authorization Strategy后,在全局安全配置中启用策略。整体上看基于角色的授权策略灵活性及易用性相对平衡。
授权管理在系统管理下的"Manage and Assign Roles"页面,
首先,创建一个全局只读帐号
常规应用:新增一个普通授权角色
需要注意的是“Pattern”,这里支持正则表达式,配置符合当前规则的
用户权限矩阵:多个用户,多个授权角色的绑定。如下图,权限角色横向排列,用户纵向排列。
注:当用户过多或权限管理要求比较高,角色配置过多的话,配置操作也不是很方便。这种情况下,建议能过二次开发来扩展jenkins功能,或者自行研发cicd系统。
比如下面这种情况,管理权限的时候就不太方便 。
1以文件夹类型任务隔离开发测试环境以及不同项目的job
2.使用基于角色的的授权模式,权限分配时正则表达式匹配到指定的目录及目录下的所有job.
3.使用ldap作为用户系统, 分配权限到指定用户。