Jenkins API使用者認證方式

人艰不拆_zmc發表於2024-08-04
JenkinsAPI

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的管理。當然，在實際應用中，還需要根據具體情況進行權衡和選擇。

相關文章