1. Overview
Jenkins API can be authenticated by username + password or username + Token, this article with specific examples to illustrate the specific use.
2, Jenkins environment
This article is based on the Jenkins 2.452.3 version of the demonstration, the details of the environment to build can be referred to theCentos7 under the installation and configuration of the latest version of Jenkins (2.452.3)" This blog post.
3, Jenkins API user authentication methods
In theHow Jenkins Defends Against CSRF Attacks with CrumbIssuerIn the in-depth discussion , we not only analyze the Jenkins cross-site request forgery protection mechanism , but also a practical demonstration of the username combined with a password and a username combined with a Token two ways to call the Jenkins API . In order to further deepen the understanding, this article will be the two authentication methods - that is, the use of usernames and passwords, as well as usernames and Token way - for a more detailed description and illustration.
3.1 Incoming user name and password
Before calling the interface, make sure that the username and user password passed to the calling interface are correct.
Take the curl client as an example, use the -u method to pass in a username and password to get the current user's Crumb.
curl -s -u zmc:123456 http://10.20.31.153:8080/jenkins/crumbIssuer/api/json {"_class":"","crumb":"1fc9fb418bb0f908903593c06981ec9881d69eec3202190813de724cbf77451e","crumbRequestField":"Jenkins-Crumb"}%
3.2 User name + password method (URL)
The same effect can be achieved by embedding the username and password in the URL in the format username:password@JenkinsURL.
curl -s http://zmc:[email protected]:8080/jenkins/crumbIssuer/api/json {"_class":"","crumb":"a91a4cec96c751651abb1350164dca3ab0b87444f588f0d06ba51e1813c96c69","crumbRequestField":"Jenkins-Crumb"}%
3.3 Passing in Username and Token
Users can only issue API Token for themselves, for example, if the logged in user is admin, it cannot issue API Token for other users.
The user logs into the Jenkins UI interface and performs API Token issuance.
Different Token can be issued for different applications, and the issued Token can be deleted.
Can only see Token when creating!!!! Can't see the Token value after refreshing the page.
Take the curl client as an example, use the -u method to pass in the username and Token, and get the current user's Crumb.
curl -s -u zmc:1126edb3c4127702f5a754a4d53065b56e http://10.20.31.153:8080/jenkins/crumbIssuer/api/json {"_class":"","crumb":"c4641813237a41c1d6e26e3d1afecfcbc1eebc019cf169b45994a9d2c947d438","crumbRequestField":"Jenkins-Crumb"}%
It is important to note that Token is not a unique feature of the Jenkins API, and it is important to ensure that Token is both secure and flexible in its use.
-
Granularity: Different applications use different tokens, which has the advantage of not affecting other applications when recovering permissions at the application level.
-
Get: Token information can only be seen once at the time of creation, forgetting Token information is the same as forgetting the password, it is not recommended to provide the ability to view specific information about the Token, because it is the same as having a privilege to view all the user's Token, and once the user's privilege is lost, it is the same as all the user's Token information is lost, and the user itself cannot notice. If this user privilege is lost, all users' Token information is at risk of being lost, and the users themselves cannot notice it. Once forgotten, delete the Token and regenerate it for use.
-
Update: It is more secure to update the Token periodically (e.g., every six months, depending on the actual security requirements), and the Token is managed over a period of time.
-
Protection: A Token is the equivalent of a user's password. Obtaining a Token grants you the ability to operate as the user to whom it belongs, so naturally you should be as careful with your Token as you are with your password.
-
Recycling: It is recommended to recycle tokens that are no longer in use to prevent security risks.
4. Summary
This blog post provides an in-depth look at the two main methods of user authentication for the Jenkins API: using a username and password and using a username and Token.Recommended API Authentication Using a Username and Token.
(1) Security aspects:
-
-
Reduce the risk of password leakage: The combination of username and password is widely used in multiple systems and applications, and once the password is leaked, it may affect the security of multiple systems.Token, on the other hand, is generated exclusively for a specific application or service, and even if it is compromised, its scope of influence is relatively small.
-
Revocability: If a Token is compromised or no longer needed, it can be easily removed or disabled without changing the user's password.
-
(2) Ease of use:
-
-
One-time configuration: Users only need to generate the Token once in the Jenkins UI and use it where needed. No need to enter or manage passwords frequently.
-
Reduced Errors: Since Token is usually long and complex, when used programmatically (e.g., scripts or automated tools), authentication failures due to incorrect password entry can be reduced.
-
(3) Application scenarios:
-
- For automation scripts or tools that require frequent calls to the Jenkins API, it is more appropriate to use Token for authentication. This not only improves security, but also makes it easy to manage permissions and the lifecycle of Token.
- If Jenkins API calls are limited to a few trusted systems or users that are already authenticated by other means (e.g., IP whitelisting, VPNs, etc.), it is feasible to authenticate using usernames with passwords, but be sure to ensure that the passwords are complex and stored securely.
In summary, it is recommended to use username and Token for Jenkins API authentication. This approach not only improves security, but also facilitates the management of Token. Of course, in the actual application, it is also necessary to weigh and choose according to the specific circumstances.