最小許可權的容器編排 | Linux 中國

Docker 平臺和容器已經成為打包、部署、和管理應用程式的標準。為了在一個叢集內協調跨節點的容器，必須有一個關鍵的能力：一個容器編排器。

container orchestrator

對於關鍵的叢集化以及計劃的任務，編排器是起重大作用的，比如：

不幸的是，在這種環境下，編排器的分散式特性和資源的短暫性使得確保編排器的安全是一個極具挑戰性的任務。在這篇文章中，我們將討論容器編排器安全模型中沒有考慮到的、但是很重要的這方面的詳細情況，以及 Docker 企業版中如何使用內建的編排效能、Swarm 樣式，去剋服這些問題。

誘因和威脅模型

使用 swarm 樣式的 Docker 企業版的其中一個主要標的是提供一個內建安全特性的編排器。為達到這個標的，我們部署了第一個在我們心目中認為的以最小許可權原則設計的容器編排器。

在電腦科學中，一個分散式系統所要求的最小許可權原則是，系統中的每個參與者僅僅能訪問它正當目的所需要的資訊和資源。不是更多，也不是更少。

“一個行程必須僅僅能去訪問它的正當目的所需要的資訊和資源”

最小許可權原則

在一個 Docker 企業版叢集中的每個節點分配的角色：既不是管理者（manager），也不是工人（worker）。這些角色為節點定義了一個很粗粒度的許可權級別：分別進行管理和任務執行。儘管如此，不用理會它的角色，透過使用加密的方式，來保證一個節點僅僅有執行它的任務所需要的資訊和資源。結果是，確保叢集安全變得更容易了，甚至可以防止大多數的有經驗的攻擊者樣式：攻擊者控制了底層通訊網路，或者甚至攻陷了叢集節點。

核心預設安全

這是一個很老的安全最大化狀態：如果它不是預設的，就沒人用它。Docker Swarm 樣式將預設安全這一概念融入了核心，並且使用這一機制去解決編排器生命週期中三個很難並且很重要的部分：

我們來分別看一下這三個部分：

可信引導和節點引入

確保叢集安全的第一步，沒有別的，就是嚴格控製成員和身份。管理員不能依賴它們節點的身份，並且在節點之間強制實行絕對的負載隔離。這意味著，未授權的節點不能允許加入到叢集中，並且，已經是叢集一部分的節點不能改變身份，突然去偽裝成另一個節點。

為解決這種情況，透過 Docker 企業版 Swarm 樣式管理的節點，維護了健壯的、不可改變的身份。期望的特性是，透過使用兩種關鍵的構建塊去保證加密：

加入 Swarm

要加入 Swarm，節點需要一份安全加入令牌Secure join token的副本。在叢集內的每個操作角色的令牌都是獨一無二的 —— 現在有兩種型別的節點：工人（workers）和管理者（managers）。由於這種區分，擁有一個工人令牌的節點將不允許以管理者角色加入到叢集。唯一得到這個特殊令牌的方式是透過 swarm 的管理 API 去向叢集管理者請求一個。

令牌是安全的並且是隨機生成的，它還有一個使得令牌洩露更容易被檢測到的特殊語法：一個可以在你的日誌和倉庫中很容易監視的特殊字首。幸運的是，即便發現一個洩露，令牌也可以很容易去更新，並且，推薦你經常去更新它們 —— 特別是，在一段時間中你的叢集不進行擴大的情況下。

Docker Swarm

引導信任

作為它的身份標識建立的一部分，一個新的節點將向任意一個網路管理者請求釋出一個新的身份。但是，在我們下麵的威脅模型中，所有的通訊可以被一個第三方攔截。這種請求存在的問題是：一個節點怎麼知道與它進行對話的對方是合法的管理者？

Docker Security

幸運的是，Docker 有一個內建機制可以避免這種情況。這個加入令牌被主機用於加入 Swarm，包含了一個根 CA 證書的雜湊串。所以，主機可以使用單向 TLS，並且使用這個雜湊串去驗證它加入的 Swarm 是否正確：如果管理者持有的證書沒有被正確的 CA 雜湊串簽名，節點就知道它不可信任。

節點身份釋出和管理

在一個 Swarm 中，身份標識是內嵌在每個節點都單獨持有的一個 x509 證書中。在一個最小許可權原則的表現形式中，證書的私鑰被絕對限制在主機的原始位置。尤其是，管理者不能訪問除了它自己的私鑰以外的任何一個私鑰。

身份釋出

要接收它們的證書而無需共享它們的私鑰，新的主機透過釋出一個證書簽名請求（CSR）來開始，管理者收到證書簽名請求之後，轉換成一個證書。這個證書成為這個新的主機的身份標識，使這個節點成為 Swarm 的一個完全合格成員！

當和安全引導機制一起使用時，發行身份標識的這個機制來加入節點是預設安全的：所有的通訊部分都是經過認證的、授權的，並且非敏感資訊從來都不會以明文方式進行交換。

身份標識延期

儘管如此，給一個 Swarm 中安全地加入節點，僅僅是 “故事” 的一部分。為降低證書的洩露或者失竊造成的影響，並且移除管理 CRL 串列的複雜性，Swarm 樣式為身份標識使用了較短存活週期的證書。這些證書預設情況下三個月後將過期，但是，也可以配置為一個小時後即刻過期！

Docker secrets

較短的證書過期時間意味著不能手動去處理證書更新，所以，通常會使用一個 PKI 系統。對於 Swarm，所有的證書是以一種不中斷的方式進行自動更新的。這個過程很簡單：使用一個相互認證的 TLS 連線去證明一個特定身份標識的所有者，一個 Swarm 節點定期生成一個新的公鑰/私鑰金鑰對，並且用相關的 CSR 去簽名傳送，建立一個維持相同身份標識的完整的新證書。

經過認證、授權、和加密的資訊儲存和傳播。

在一個正常的 Swarm 的操作中，關於任務的資訊被髮送給去執行的工人（worker）節點。這裡不僅僅包含將被一個節點執行的容器的資訊；也包含那個容器執行所必需的資源的所有資訊，包括敏感的機密資訊，比如，私鑰、密碼和 API 令牌。

傳輸安全

事實上，參與 Swarm 的每個節點都擁有一個獨一無二的 X509 格式的證書，因此，節點之間的通訊安全是沒有問題的：節點使用它們各自的證書，與另一個連線方進行相互認證、繼承機密、真實性、和 TLS 的完整性。

Swarm Mode

關於 Swarm 樣式的一個有趣的細節是，本質上它是使用了一個推送樣式：僅管理者被允許去傳送資訊到工人們（workers）—— 顯著降低了暴露在低許可權的工人節點面前的管理者節點的攻擊面。

將負載嚴格隔離進安全區域

管理者節點的其中一個責任是，去決定傳送到每個工人（worker）節點的任務是什麼。管理者節點使用多種策略去做這個決定；根據每個節點和每個負載的特性，去跨 Swarm 去安排負載。

在使用 Swarm 樣式的 Docker 企業版中，管理者節點透過使用附加到每個單個節點標識上的安全標簽，去影響這些安排決定。這些標簽允許管理者將節點組與不同的安全區域連線到一起，以限制敏感負載暴露，以及使相關機密資訊更安全。

Docker Swarm Security

安全分發機密

除了加快身份標識釋出過程之外，管理者節點還有儲存和分發工人節點所需要的任何資源的任務。機密資訊像任何其它型別的資源一樣處理，並且基於安全的 mTLS 連線，從管理者推送到工人節點。

Docker Secrets

在主機上，Docker 企業版能確保機密僅提供給它們指定的容器。在同一個主機上的其它容器並不能訪問它們。Docker 以一個臨時檔案系統的方式顯露機密給一個容器，確保機密總是儲存在記憶體中，並且從不寫入到磁碟。這種方式比其它競爭的替代者更加安全，比如，在環境變數中儲存它們[1]。一旦這個任務完成，這個機密將永遠消失。

儲存機密

在管理者主機上的機密總是保持加密的。預設情況下，加密這些機密的金鑰（被稱為資料加密金鑰，DEK）是以明文的方式儲存在硬碟上的。這使得那些對安全性要求較低的人可以輕鬆地去使用 Docker Swarm 樣式。

但是，如果你執行一個生產叢集，我們推薦你啟用自動鎖定樣式。當自動鎖定樣式啟用後，一個重新更新過的 DEK 被一個獨立的加密金鑰的金鑰（KEK）所加密。這個金鑰從不被儲存在叢集中；管理者有責任將它儲存在一個安全可靠的地方，並且當叢集啟動的時候可以提供它。這就是所謂的 “解鎖” Swarm。

根據 Raft 故障容錯一致性演演算法，Swarm 樣式支援多個管理者。在這個場景中，無縫擴充套件了機密儲存的安全性。每個管理者主機除了共享金鑰之外，還有一個唯一的磁碟加密金鑰。幸運的是，Raft 日誌在磁碟上也是加密的，並且，在自動鎖定樣式下，沒有 KEK 同樣是不可訪問的。

當一個節點被攻陷後發生了什麼？

Docker Secrets

在傳統的編排器中，輓回一臺被攻陷的主機是一個緩慢而複雜的過程。使用 Swarm 樣式，恢復它就像執行一個 Docker 節點的 rm 命令一樣容易。這是從叢集中刪除一個受影響的節點，而 Docker 將去處理剩下的事情，即，重新均衡負載，並且確保其它的主機已經知道，而不會去與受影響的節點通訊。

正如我們看到的那樣，感謝最小許可權的編排器，甚至是，如果攻擊者在主機上持續活動，它們將被從剩餘的網路上切斷。主機的證書 —— 它的身份標識 —— 被列入黑名單，因此，管理者也不能有效訪問它。

結論

使用 Swarm 樣式的 Docker 企業版，在預設情況下確保了編排器的所有關鍵區域的安全：

因為 Swarm 樣式的持續改進，Docker 團隊正在努力將最小許可權原則進一步推進。我們正在處理的一個任務是：如果一個管理者被攻陷了，怎麼去保證剩下的節點的安全？路線圖已經有了，其中一些功能已經可以使用，比如，白名單功能，僅允許特定的 Docker 映象，阻止管理者隨意執行負載。這是透過 Docker 可信內容來實現的。

via: https://blog.docker.com/2017/10/least-privilege-container-orchestration/

作者：Diogo Mónica[3] 譯者：qhwdw 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出