Jenkins奇技淫巧 — 安装篇(mac)
Jenkins奇技淫巧 — 配置篇
Jenkins奇技淫巧 — 安全篇
Jenkins奇技淫巧 — 发送邮件篇
Jenkins奇技淫巧 — 全局变量篇
Jenkins奇技淫巧 — 新建任务篇
Jenkins奇技淫巧 — 插件篇
Jenkins奇技淫巧 — 问题篇
Jenkins奇技淫巧 — 命令篇
Jenkins奇技淫巧 — 环境配置篇(Android自动化构建)
Jenkins奇技淫巧 — 参数化构建篇(Android自动化构建)
Jenkins奇技淫巧 — 第一次实战篇(Android自动化构建)
Jenkins奇技淫巧 — Python打包篇(Android自动化构建)
Jenkins奇技淫巧 — Python发送邮件和上传蒲公英(Android自动化构建)
Jenkins奇技淫巧 — 乐固,多渠道打包篇(Android自动化构建)
Jenkins奇技淫巧 — 节点管理篇
Jenkins奇技淫巧 — 优秀文章篇
管理用户(系统管理 -> 管理用户)
在第一篇文章Jenkins奇技淫巧 — 安装篇(mac)里,安装成功后,第一次访问Jenkins,会让我们选择是直接用admin作为管理员登陆Jenkins,还是自己新创建一个管理员账户,如果选择的是直接使用admin进入,那么在用户列表里面就会显示admin账户,由于admin默认的密码很长,很难记忆,所以我们可以重新创建一个管理员账户,当然也可以修改admin的密码和账户名。
- 创建用户
管理员账户默认拥有所有的权限,可以进入“系统管理”,配置Jenkins相关数据,管理员再创建管理员,当前管理员可以删除其它管理员账户,管理员可以设置是否允许注册Jenkins登陆账号等,在用户列表,点击左侧新建用户即可创建新的管理员账户。
全局安全配置(系统管理 -> 全局安全配置)
Jenkins官方文档 [https://jenkins.io/zh/doc/book/managing/security/]
访问控制是保护Jenkins环境免受未经授权使用的主要机制。在Jenkins中配置访问控制 是必要的:
- 访问控制
-
安全域
告诉Jenkins环境如何以及从何处获取用户(或身份)信息。 也称为 "认证"。这里我们用“Jenkins专有用户数据库”,其它安全域请自行查看官方文档-
Jenkins专有用户数据库
使用Jenkins自己内置的用户数据存储来进行身份验证,而不是委托给外部系统。 这是Jenkins 2.0或后来安装的Jenkins默认启用的,适用于小环境。允许用户注册 保存后系统管理中就出现管理用户的选项。页面右上角也会出现“登录/注册”的选项。注册后,可以使用Jenkins相关功能。
-
-
授权策略
告诉 Jenkins 环境, 配置用户和/或组可以访问Jenkins的哪些功能和文件。Role-Based Strategy
使用插件方式,更加细粒度度控制权限任何用户可以做任何事(没有任何限制)
每个人都能完全控制Jenkins, 包括没有登陆的匿名用户。 最好不要使用这种配置,除非在本地测试Jenkins主机,当然,我们肯定不希望通过注册的用户也拥有像管理员一样的权限。遗留模式(Legacy mode)
与Jenkins <1.164的行为完全相同。也就是说, 如果一个用户拥有 "admin" 角色, 就会被授予对系统的完全控制, 负责 (包括匿名用户) 只会拥有读访问权限。 除了在本地测试Jenkins主机,最好不要使用这种配置。登录用户可以做任何事(Logged in users can do anything)
在该模式下, 每个登陆的用户对Jenkins完全控制。根据一个高级选项, 匿名用户获取Jenkins的访问权限, 或者根本无法访问。该模式有助于强制用户在操作前进行登录, 以便于对用户的行为进行审计跟踪。安全矩阵(Matrix-based security)
该授权方案对允许用户和组在Jenkins环境下能够进行哪些操作进行细粒度控制
-
将鼠标放在对应的权限上面,会有说明,英文的可以自行谷歌翻译。
匿名用户(Anonymous Users)
这里没有给匿名用户任何权限,所以根本无法进入Jenkins首页-
认证用户(Authenticated Users)
比如注册过的用户,就属于该组,当在认证用户栏勾选了权限,同时又给单个用户配置了权限,那么该注册用户的权限是认证用户组的权限和给予用户的权限的并集。点击“add user or group...”添加用户或者用户组,名字是账户名,在用户列表里面展示的。比如这里的pds,test账户。- 项目矩阵授权策略(Project-based Matrix Authorization Strategy) 此授权方案是基于矩阵的安全性的扩展, 它允许为在项目配置屏幕中的 *each project*分别定义额外的访问控制列表 (ACL)。它允许特定的用户和组访问特定的项目, 而不是Jenkins 环境中的所有项目。 基于项目的矩阵授权定义的ACL是附加的,在配置全局安全屏幕中定义的访问授权将与 指定项目的ACL相结合。
安全矩阵和项目矩阵授权策略的配置是一模一样的,唯一的区别是项目矩阵授权策略支持在Job的配置页面再次配置授权策略。
基于矩阵的安全性和基于项目的矩阵授权策略由 Matrix Authorization Strategy Plugin插件提供,它可能不会安装在你的Jenkins中。
如果不进行权限控制,你发现注册用户可以修改你Jenkins的配置,所以你可以在认证用户组配置相应权限,而管理员拥有全部权限,或者不允许注册,管理员直接创建用户并设置权限。
凭据配置(系统管理 -> 凭据配置)
凭据是什么,可以理解成账户和密码,在需要使用的时候,可以直接选择需要使用的凭据就可以了,不用输入账户和密码。
讲解凭据配置之前我们来看看,怎么创建凭据,在Jenkins左边又个凭据选项,点击进入。
图片的上面展示的是我们创建的凭据,里面写明了提供者,域,id等,下面是提供者,以及提供者包含了哪些域。默认有一个全局的域
- 将鼠标放到提供者名字上面,会出现一个下拉箭头,然后可以添加域,当然你可以点击左边的系统(即默认的提供者),然后添加域。
-
点击对应提供者列表下的域,进入域所包含的凭据列表,点击添加凭据。
- 类型:
- Secret text - 例如 API token(例如 GitHub 的个人 access token)
- Username and password - 可以作为单独的组件处理,也可以作为
username:password
格式的冒号分隔字符串来处理 - Secret file - 实际上是文件中的秘密内容
- SSH Username with private key - 一个 [SSH 密钥对]
- Certificate - 指定证书和可选的密码。上传 PKCS#12 证书。
- Docker Host Certificate Authentication - 主机证书身份验证凭证.
- 范围:该凭据能够使用的范围,比如只能本节点能够使用,其它节点不能使用
- ID:添加凭据后,系统生成的
-
添加凭据后
-
那现在我们来看,凭据配置界面
- 提供者:就是使用哪些提供者提供的凭据,如果全部不使用,你会发现,左边的凭据选项会消失。
- 类型:在我们创建凭据的时候,我们所用的类型,比如用户名和密码。
- 限制:即提供者和类型。
管理员密码忘记
这个自行百度,不同的Jenkins版本可能有些不同。