背景

最近臨時交接了一個客戶測試環境和產品環境的維護工作。交接的客戶資產包含：代碼庫、生產環境主機、測試環境主機、搭建在測試環境主機上的持續集成服務器以及對應的賬號密碼。這個持續集成服務器采用Jenkins搭建，并且可以用來部署測試環境和生產環境的應用。

[[198613]]

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

這個維護任務需要通過SSH登錄到測試環境主機上進行操作。測試主機是通過authorized_keys進行SSH認證的，只要你自己的ssh-key被添加到了主機上，就可以實現無密碼登錄。

這樣有兩個好處：一方面維護人員無需使用密碼，避免了生產環境密碼的泄露。另一方面可以按需吊銷不再使用的客戶端，及時回收權限。所以我需要把自己的sshpublickey交給管理員，讓他把我的key加到可訪問列表里。

悲劇的是，前管理員告訴我，他的key因為更換電腦的關系沒有及時更新。所以，他也無法登錄主機。而且之前參與維護的其它管理員的key也都失效了，這意味著我們失去了對主機的控制。此時，我手上只有登錄Jenkins的的用戶名和密碼，于是一個邪惡的想法就誕生了：

既然Jenkins可以執行腳本，那么我是否可以通過Jenkins把我的key注入進去?

[[198614]]

于是我把ExecuteShell的Job變成了我的命令行，通過運行日志得知了宿主用戶的文件目錄信息。然后把自己的sshpublickey加到了登錄列表里(此處省略敏感信息)：

sudo sh -c“cp~/.ssh/authorized_keys~/.ssh/authorized_keys.bak” 
 
sudo sh -c"echo‘{我的sshpublickey}’>>~/.ssh/authorized_keys" 

It works !

我成功的登錄了機器，但這卻暴露了一個問題：持續集成服務器成為了一個安全隱患。

首先，持續集成服務器可以執行代碼。這就意味著它有可能執行有害代碼。

其次，持續集成服務器缺乏足夠的用戶鑒權，這很有可能導致未授權用戶訪問。

無權限控制的服務器+可以執行代碼=裸奔的肉雞

那么，如何構建一個更安全的持續集成服務器?

rootless原則

在服務器的世界里，root用戶就是神，擁有至高的權力和力量。如果有人獲得了“神之力”，后果可能不堪設想。

[[198615]]

無論是Web服務器、數據庫服務器還是持續集成服務器。都是這個世界里的二等公民，權限和力量都應該受到約束。執行的時候應該受到控制。

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

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

沙盒隔離原則

因為持續集成服務器會執行腳本或運行程序，而這些程序和腳本有可能是存在惡意代碼的。所以，對應的任務應該在隔離的安全沙盒中執行，例如：受限的用戶，受限的權限，受限的空間。

在上述的故事里，我就通過CI執行了一段不安全的腳本成功獲得了登錄主機的權限。

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

當然，也可以考慮采用TravisCI這樣的第三方持續集成服務來保證安全性。

備份和備份核查原則

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

[[198616]]

這里的備份，不光是對配置、數據的備份，還有崗位的備份。

如果管理員有備份，完全不會出現無法登陸的事情。

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

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

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

多重要素身份驗證原則

上述的持續集成服務器是暴露在互聯網中的，任何一個人訪問到這個站點，通過一定程度的密碼破解，就可以獲得這個持續集成服務器的訪問控制權限。從而可以做出上述的操作。

所以，有了用戶名和密碼，并不一定是可信用戶。還需要通過更多的手段，諸如手機短信驗證碼或者第三方認證集成來驗證用戶的身份。

關鍵操作手動驗證原則

試想一下，如果在上述的例子中我并沒有服務器的訪問權限。而是通過提交未經審查的代碼自動運行測試腳本。實際上也會造成同樣的效果。

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

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

[[198617]]

構建安全CI的幾個實踐：

采用Sibling的方式在Docker里運行任務。

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

CI的登錄權限和其它的認證方式(比如GitHub、Okta等)集成起來。并用組限制登錄。

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

官方的安全指南

不少持續集成工具的官方都提供了最佳實踐以及安全指南幫助我們構建持續集成服務器。請務必在構建持續集成服務器前閱讀并理解這些安全實踐和措施，并遵照安全最佳實踐構建持續集成服務器：

• Jenkins最佳實踐
• Jenkins官方安全指南

如果沒有這些如果

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

【本文是51CTO專欄作者“ThoughtWorks”的原創稿件，微信公眾號：思特沃克，轉載請聯系原作者】

戳這里，看該作者更多好文