1、概述
Jenkins的API可以通过用户名+密码或者用户名+Token的方式来进行认证,这篇文章以具体示例来说明具体的使用方式。
2、Jenkins环境
本文示例基于Jenkins 2.452.3版本进行演示,详细的环境构建可参考《Centos7下安装配置最新版本Jenkins(2.452.3)》这篇博文。
3、Jenkins API用户认证方式
在《Jenkins如何使用CrumbIssuer防御CSRF攻击》的深入探讨中,我们不仅详细剖析了Jenkins的跨站请求伪造防护机制,还实际演示了通过用户名结合密码以及用户名结合Token两种方式来进行Jenkins API的调用。为了进一步加深理解,本文将对这两种认证方法------即使用用户名加密码,以及用户名加Token的方式------进行更为详尽的阐述与说明。
3.1 传入用户名和密码
调用接口前,先确保调用接口传递的用户名及用户密码的正确性。
以curl客户端为例,使用-u方式传入用户名和密码, 获取当前用户的Crumb。
curl -s -u zmc:123456 http://10.20.31.153:8080/jenkins/crumbIssuer/api/json
{"_class":"hudson.security.csrf.DefaultCrumbIssuer","crumb":"1fc9fb418bb0f908903593c06981ec9881d69eec3202190813de724cbf77451e","crumbRequestField":"Jenkins-Crumb"}%
3.2 用户名+密码方式(URL)
URL中将用户名和密码嵌入其中,格式为用户名:密码@JenkinsURL,也可以实现相同效果。
curl -s http://zmc:123456@10.20.31.153:8080/jenkins/crumbIssuer/api/json
{"_class":"hudson.security.csrf.DefaultCrumbIssuer","crumb":"a91a4cec96c751651abb1350164dca3ab0b87444f588f0d06ba51e1813c96c69","crumbRequestField":"Jenkins-Crumb"}%
3.3 传入用户名和Token
用户只能为自己颁发API Token,比如现在登陆用户是admin,它是不能为其他用户颁发API Token。
用户登陆Jenkins UI界面,并进行API Token颁发。
可以为不同应用颁发不同Token,可以对颁发Token进行删除操作。
只有创建时候能看到Token!!!刷新页面后看不到Token值。
以curl客户端为例,使用-u方式传入用户名和Token, 获取当前用户的Crumb。
curl -s -u zmc:1126edb3c4127702f5a754a4d53065b56e http://10.20.31.153:8080/jenkins/crumbIssuer/api/json
{"_class":"hudson.security.csrf.DefaultCrumbIssuer","crumb":"c4641813237a41c1d6e26e3d1afecfcbc1eebc019cf169b45994a9d2c947d438","crumbRequestField":"Jenkins-Crumb"}%
一定要注意,Token 并不是 Jenkins 的 API 所独特提供的功能,在使用中一定要保证 Token 的安全性与灵活性:
-
粒度: 不同的应用使用不同的 Token,这样的好处在于对于应用级别的权限进行回收等需求的时候不至于影响到其他应用。
-
获取: Token 的信息只有在创建的时候才能看到一次,忘记了 Token 的信息等于忘记了密码,不建议提供查看 Token 具体信息的功能,因为这样相当于有一个权限可以查看到所有用户的 Token,此用户权限一旦丢失,相当于所有用户的 Token 信息都存在丢失的风险,而且用户本身无法察觉。一旦忘记,删除此 Token,重新生成 Token 进行使用。
-
更新: 定期的更新Token(比如每半年,需要根据实际的安全需求) ,Token 在使用期限上进行管理,这种方式会更加安全。
-
保护: Token 就等同于用户的密码,获得 Token 就获得了以所属用户身份进行操作的权限,自然对于 Token 的保护也要像您的密码一样谨慎。
-
回收: 对于不再使用的 Token,建议及时地回收,可以预防安全上的风险。
4、总结
本博文深入探讨了Jenkins API的两种主要用户认证方式:使用用户名与密码以及使用用户名与Token。推荐使用用户名与Token进行API认证:
(1)安全性方面:
-
-
减少密码泄露风险:用户名与密码的组合方式在多个系统和应用中广泛使用,一旦密码泄露,可能会影响到多个系统的安全。而Token是专门为特定应用或服务生成的,即使泄露,其影响范围也相对较小。
-
可撤销性:如果Token泄露或不再需要,可以轻松地将其删除或禁用,而无需更改用户的密码。
-
(2)易用性方面:
-
-
一次性配置:用户只需在Jenkins UI中生成一次Token,并在需要的地方使用即可。无需频繁地输入或管理密码。
-
减少错误:由于Token通常较长且复杂,通过编程方式(如脚本或自动化工具)使用时,可以减少因密码输入错误而导致的认证失败。
-
(3)应用场景方面:
-
- 对于需要频繁调用Jenkins API的自动化脚本或工具,使用Token进行认证更为合适。这不仅可以提高安全性,还可以方便地管理权限和Token的生命周期。
- 如果Jenkins API的调用仅限于少数几个受信任的系统或用户,并且这些系统或用户已经通过其他方式进行了身份验证(如IP白名单、VPN等),那么使用用户名与密码进行认证也是可行的,但务必确保密码的复杂性和存储的安全性。
综上所述,推荐使用用户名与Token进行Jenkins API认证。这种方式不仅提高了安全性,还便于Token的管理。当然,在实际应用中,还需要根据具体情况进行权衡和选择。