最小權限的容器編排：編排器的使用方法探討

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

container orchestrator

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

　　·管理容器計劃和資源分配。

　　·支持服務發現和無縫的應用程序部署。

　　·分配應用程序運行必需的資源。

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

　　誘因和威脅模型

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

　　在計算機科學中，一個分布式系統所要求的最小權限原則是，系統中的每個參與者僅僅能訪問它正當目的所需要的信息和資源。不是更多，也不是更少。

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

　　最小權限原則

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

　　內核缺省安全

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

　　1.可信引導和節點引入。

　　2.節點身份發布和管理。

　　3.認證、授權和加密的信息存儲和傳播。

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

　　可信引導和節點引入

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

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

　　1.為集群成員使用安全加入令牌（Secure join token）。

　　2.從一個集中化的認證機構發行的內嵌唯一身份的證書。

　　加入 Swarm

　　要加入 Swarm，節點需要一份安全加入令牌的副本。在集群內的每個操作角色的令牌都是獨一無二的 —— 現在有兩種類型的節點：工人(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 以一個臨時文件系統的方式顯露機密給一個容器，確保機密總是保存在內存中，并且從不寫入到磁盤。這種方式比其它競爭的替代者更加安全，比如，在環境變量中存儲它們。一旦這個任務完成，這個機密將永遠消失。

　　存儲機密

　　在管理者主機上的機密總是保持加密的。缺省情況下，加密這些機密的密鑰(被稱為數據加密密鑰，DEK)是以明文的方式存儲在硬盤上的。這使得那些對安全性要求較低的人可以輕松地去使用 Docker Swarm 模式。

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

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

　　當一個節點被攻陷后發生了什么?

Docker Secrets

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

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

　　結論

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

　　·加入集群。阻止惡意節點加入到集群。

　　·把主機分組為安全區域。阻止攻擊者的橫向移動。

　　·安排任務。任務將僅被委派到允許的節點。

　　·分配資源。惡意節點不能 “盜取” 其它的負載或者資源。

　　·存儲機密。從不明文保存并且從不寫入到工人節點的磁盤上。

　　·與工人節點的通訊。使用相互認證的 TLS 加密。

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

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

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

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