作者：顧宇 thoughtworks高階諮詢師

背景

最近臨時接手了一個客戶測試環境和產品環境的維護工作。接手的客戶資產裡包含：程式碼庫，生產環境主機，測試環境主機以及搭建在測試環境主機上的CI（基於Jenkins）。這個CI可以用來部署測試環境和生產環境的應用。

不久，接到了客戶的一個維護請求：把最新的生產環境資料同步到測試環境裡。

這個維護工作需要通過SSH登入到測試環境主機上進行操作。測試主機是通過authorized_keys進行 SSH 認證的，因此沒有使用者名稱和密碼。這樣有兩個好處：一方面無需生產環境使用者名稱密碼。一方面可以按需吊銷不再用的客戶端。這樣可以避免密碼洩露。所以我需要把自己的ssh public key

悲劇的是，管理員告訴我他的 key 因為更換電腦的關係沒有及時更新。所以，他也登入不上去了。而且之前所有的管理員的 key 都失效了。我手上只有CI的管理員的使用者名稱和密碼，於是一個邪惡的想法就誕生了：

既然 CI 可以執行指令碼，那麼我是否可以通過CI把我的key注入進去？

於是我用Execute Shell的Job變成了我的命令列，通過CI執行日誌得知了宿主使用者的檔案目錄資訊。然後把自己的ssh public key加到了登入列表裡（此處省略敏感資訊）：

sudo sh -c “cp ~/.ssh/authorized_keys ~/.ssh/authorized_keys.bak”

sudo sh -c “echo ‘{你的ssh public key}’ >> ~/.ssh/authorized_keys”

It works !

我成功的登入了機器，但這卻暴露了一個問題：CI 有可能會成為一個安全隱患。

首先，CI 可以執行程式碼。這就意味著它有可能執行有害程式碼。

其次，CI 缺乏足夠的使用者鑑權，這很有可能導致未授權使用者訪問。

那麼，如何構建一個更安全的CI伺服器？

rootless原則

“神操縱著萬物，你感覺得到他，但永遠看不見他。” ——《聖經·希伯來書11:27》

在伺服器的世界裡，root使用者就是神，具有至高的權力和力量。如果有人獲得了”神力“，後果可能不堪設想。

無論是Web伺服器，還是CI伺服器。都是這個世界裡的二等公民，許可權和力量都應該受到約束。執行的時候應該“

此外，應該極力避免sudo的濫用，尤其是對那些從外部訪問的使用者。很多情況下，為了操作方便，很多使用者都有sudo的許可權。但這恰恰造成了低許可權使用者提升自己的訪問許可權進行有害操作。

在上述的故事裡，因為沒有對Jenkins的主機使用者做有效的隔離，導致了我可以用sudo注入自己的key獲得機器的訪問許可權。

沙盒隔離原則

因為CI會執行指令碼或執行程式，而這些程式和指令碼極有可能是不安全的。所以，CI任務應該在隔離的安全沙盒中執行，例如：受限的使用者，受限的許可權，受限的空間。

在上述的故事裡，我就通過CI執行了一段不安全的指令碼成功獲得了登入主機的許可權。

如果這些任務執行在隔離並受控的Docker容器裡，那麼會安全得多。

也可以考慮採用TravisCI這樣的第三方CI服務來保證安全性。

備份和備份核查原則

在上述的故事裡，因為缺乏有效的備份機制，導致了所有人都失去了對主機的訪問。此外，我在修改authorized_keys的時候先進行了備份。這樣，如果我注入失敗，還可以還原。

這裡的備份，不光是對配置，資料的備份，還有崗位的備份。

如果有備份的管理員，完全不會出現這種事情。

如果有備份QA伺服器，完全可以不需要當前的QA伺服器。

在做任何變更前，都應該做好備份以及還原的準備。因為任何變更都會帶來“蝴蝶效應”。

但是，光備份是不夠的。如果備份不能有效還原，那和沒有備份沒有什麼區別。所以，要定時的進行備份恢復測試。確保備份在各種情況下可用。

多重要素身份驗證原則

上述的CI是暴露在網際網路中的，任何一個人訪問到這個站點，通過一定程度的密碼破解，就可以獲得這個CI的訪問控制權限。從而可以做出上述的操作。

所以，有了使用者名稱和密碼，並不一定是可信使用者。所以需要通過更多的手段，諸如手機簡訊驗證碼或者第三方認證整合來驗證使用者的身份。

關鍵操作手動驗證原則

試想一下，如果上述的例子我並沒有伺服器的訪問許可權。而是通過提交未經審查的程式碼自動執行測試指令碼。實際上也會造成同樣的效果。

有時候我們會為了方便，讓CI自動觸發測試。但是，恰恰是這種“方便”，卻帶來了額外的安全隱患。而這樣的方便，不光方便了自己，也方便了惡意入侵者。

所以，不能為了方便而留下安全隱患。在關鍵操作上設定為手動操作，並通過一定的機制保證關鍵操作的可靠性才是最佳實踐。

構建安全CI 的幾個實踐

採用Sibling的方式在Docker裡執行CI任務。

賬戶密碼管理統一採用LDAP認證，如果過期則從外部修改。

CI的登入許可權和其它的認證方式（比如GItHub，Okta等）整合起來。並用組限制登入。

對於生產環境的CI，通過更加細粒度的許可權限制來隔離一些危險操作。

官方的安全指南

不少CI軟體的官方都提供了最佳實踐以及安全指南幫助我們更好的構建CI伺服器。請務必在構建CI前閱讀並理解這些安全實踐和措施，並遵照安全最佳實踐構建CI伺服器：

Jenkins最佳實踐：https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+Best+Practices

Jenkins官方安全指南：https://wiki.jenkins-ci.org/display/JENKINS/Securing+Jenkins

如果沒有這些如果

上面提到了太多的如果。如果這些“如果”能發生在事前，這些問題就不會產生。CI本身是開發的最佳實踐，但如果缺乏安全的意識，一味的追求方便和高效，則會帶來很大的安全隱患。技通過一些簡單而基礎的措施和手段，我們就能大大的減少安全隱患。