基於 Jenkins 的 DevOps 平臺應該如何設計憑證管理

背景

瞭解到行業內有些團隊是基於 Jenkins 開發 DevOps 平臺。而基於 Jenkins 實現的 DevOps 平臺，就不得不考慮憑證的管理問題。
本文就此問題進行討論，嘗試找出相對合理的管理憑證的方案。
一開始咱們想到的方案多是這樣的：用戶在 DevOps 平臺增長憑證後，DevOps 再將憑證同步到 Jenkins 上。Jenkins 任務在使用憑證時，使用的是存儲在 Jenkins 上的憑證，而不是 DevOps 平臺上的。
可是，仔細想一想，這樣作會存在如下問題：
Jenkins 與 DevOps 平臺之間的憑證數據會存在不一致問題。
存在必定的安全隱患。經過 Jenkins 腳本命令行很容易就把全部密碼的明文拿到。哪天 Jenkins 被注入了，全部的憑證一會兒就被扒走。
沒法實現 Jenkins 高可用，由於憑證存在 Jenkins master 機器上。
那麼，有沒有更好的辦法呢？

指望實現的目標

先定咱們以爲更合理的目標，而後討論如何實現。如下是筆者以爲合理的目標：
用戶仍是在 DevOps 管理本身的憑證。可是 DevOps 不須要將本身憑證同步到 Jenkins 上。Jenkins 任務在使用憑證時，從 DevOps 上取。

實現方式

Jenkins 有一個 Credentials Binding Plugin 插件，在 Jenkins pipeline 中的用法以下：

withCredentials([usernameColonPassword(credentialsId: 'mylogin', variable: 'USERPASS')]) {
sh '''
  curl -u "$USERPASS" https://private.server/ > output
'''
}

withCredentials 方法作的事情就是從 Jenkins 的憑證列表中取出 id 爲 mylogin 的憑證，並將值賦到變量名爲 USERPASS 的變量中。接下來，你就能夠在閉包中使用該變量了。
說到這裏，不知道讀者朋友是否已經有思路了？
思路就是實現一個和 Credentials Binding Plugin 插件相似功能的方法，好比叫 zWithCredentials（後文還會提到）。與 withCredentials 不一樣的是，zWithCredentials 根據憑證 id 獲取憑證時，不是從 Jenkins 上獲取，而是從 DevOps 平臺獲取。

會遇到的坑

須要適配只認 Jenkins 憑證的插件
withCredentials 方法是將憑證的內容存到變量中，這能夠知足一大部分場景。可是有一種場景是沒法知足的。就是某些 Jenkins 插件的步驟接收參數時，參數值必須是 Jenkins 憑證管理系統中的 id。好比 git 步驟中 credentialsId 參數：

git branch: 'master',
credentialsId: '12345-1234-4696-af25-123455',
url: 'ssh://git@bitbucket.org:company/repo.git'

這種狀況，咱們不可能修改現有的插件。由於那樣作的成本過高了。
那怎麼辦呢？
筆者想到的辦法是在 zWithCredentials 中作一些 hack 操做。也就是 zWithCredentials 除了從 DevOps 平臺獲取憑證，還在 Jenkins 中建立一個 Jenkins 憑證。在 Jenkins 任務執行完成後，再將這個臨時憑證刪除。這樣就能夠適配那些只認 Jenkins 憑證 id 的插件了。
對憑證自己的加密
DevOps 平臺在存儲憑證、傳輸憑證給 Jenkins 時，都須要對憑證進行加密。至於使用何種加密方式，交給讀者思考了。

小結

以上解決方案對 Jenkins 自己的改造幾乎沒有，咱們只經過一個插件就解耦了 Jenkins 的憑證管理和 DevOps 平臺的憑證管理。
思路已經有了。具體怎麼實現，因爲一些緣由不能開源，雖然實現起來不算難。還請讀者見諒。
最後，但願能和遇到一樣問題的同窗進行交流。看看是否還能夠有更好的設計思路。

本文轉載自微信公衆號 jenkins 做者：翟志軍