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

　　Docker 平臺和容器已經(jīng)成為打包、部署、和管理應用程序的標準。為了在一個集群內(nèi)協(xié)調(diào)跨節(jié)點的容器，必須有一個關鍵的能力：一個容器編排器。

container orchestrator

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

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

　　·支持服務發(fā)現(xiàn)和無縫的應用程序部署。

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

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

　　誘因和威脅模型

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

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

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

　　最小權限原則

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

　　內(nèi)核缺省安全

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

　　1.可信引導和節(jié)點引入。

　　2.節(jié)點身份發(fā)布和管理。

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

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

　　可信引導和節(jié)點引入

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

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

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

　　2.從一個集中化的認證機構發(fā)行的內(nèi)嵌唯一身份的證書。

　　加入 Swarm

　　要加入 Swarm，節(jié)點需要一份安全加入令牌的副本。在集群內(nèi)的每個操作角色的令牌都是獨一無二的 —— 現(xiàn)在有兩種類型的節(jié)點：工人(workers)和管理者(managers)。由于這種區(qū)分，擁有一個工人令牌的節(jié)點將不允許以管理者角色加入到集群。唯一得到這個特殊令牌的方式是通過 swarm 的管理 API 去向集群管理者請求一個。

　　令牌是安全的并且是隨機生成的，它還有一個使得令牌泄露更容易被檢測到的特殊語法：一個可以在你的日志和倉庫中很容易監(jiān)視的特殊前綴。幸運的是，即便發(fā)現(xiàn)一個泄露，令牌也可以很容易去更新，并且，推薦你經(jīng)常去更新它們 —— 特別是，在一段時間中你的集群不進行擴大的情況下。

Docker Swarm

　　引導信任

　　作為它的身份標識創(chuàng)建的一部分，一個新的節(jié)點將向任意一個網(wǎng)絡管理者請求發(fā)布一個新的身份。但是，在我們下面的威脅模型中，所有的通訊可以被一個第三方攔截。這種請求存在的問題是：一個節(jié)點怎么知道與它進行對話的對方是合法的管理者?

Docker Security

　　幸運的是，Docker 有一個內(nèi)置機制可以避免這種情況。這個加入令牌被主機用于加入 Swarm，包含了一個根 CA 證書的哈希串。所以，主機可以使用單向 TLS，并且使用這個哈希串去驗證它加入的 Swarm 是否正確：如果管理者持有的證書沒有被正確的 CA 哈希串簽名，節(jié)點就知道它不可信任。

　　節(jié)點身份發(fā)布和管理

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

　　身份發(fā)布

　　要接收它們的證書而無需共享它們的私鑰，新的主機通過發(fā)布一個證書簽名請求(CSR)來開始，管理者收到證書簽名請求之后，轉(zhuǎn)換成一個證書。這個證書成為這個新的主機的身份標識，使這個節(jié)點成為 Swarm 的一個完全合格成員!

　　當和安全引導機制一起使用時，發(fā)行身份標識的這個機制來加入節(jié)點是缺省安全的：所有的通訊部分都是經(jīng)過認證的、授權的，并且非敏感信息從來都不會以明文方式進行交換。

　　身份標識延期

　　盡管如此，給一個 Swarm 中安全地加入節(jié)點，僅僅是 “故事” 的一部分。為降低證書的泄露或者失竊造成的影響，并且移除管理 CRL 列表的復雜性，Swarm 模式為身份標識使用了較短存活周期的證書。這些證書缺省情況下三個月后將過期，但是，也可以配置為一個小時后即刻過期!

Docker secrets

　　較短的證書過期時間意味著不能手動去處理證書更新，所以，通常會使用一個 PKI 系統(tǒng)。對于 Swarm，所有的證書是以一種不中斷的方式進行自動更新的。這個過程很簡單：使用一個相互認證的 TLS 連接去證明一個特定身份標識的所有者，一個 Swarm 節(jié)點定期生成一個新的公鑰/私鑰密鑰對，并且用相關的 CSR 去簽名發(fā)送，創(chuàng)建一個維持相同身份標識的完整的新證書。

　　經(jīng)過認證、授權、和加密的信息存儲和傳播。

　　在一個正常的 Swarm 的操作中，關于任務的信息被發(fā)送給去運行的工人(worker)節(jié)點。這里不僅僅包含將被一個節(jié)點運行的容器的信息;也包含那個容器運行所必需的資源的所有信息，包括敏感的機密信息，比如，私鑰、密碼和 API 令牌。

　　傳輸安全

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

Swarm Mode

　　關于 Swarm 模式的一個有趣的細節(jié)是，本質(zhì)上它是使用了一個推送模式：僅管理者被允許去發(fā)送信息到工人們(workers)—— 顯著降低了暴露在低權限的工人節(jié)點面前的管理者節(jié)點的攻擊面。

　　將負載嚴格隔離進安全區(qū)域

　　管理者節(jié)點的其中一個責任是，去決定發(fā)送到每個工人(worker)節(jié)點的任務是什么。管理者節(jié)點使用多種策略去做這個決定;根據(jù)每個節(jié)點和每個負載的特性，去跨 Swarm 去安排負載。

　　在使用 Swarm 模式的 Docker 企業(yè)版中，管理者節(jié)點通過使用附加到每個單個節(jié)點標識上的安全標簽，去影響這些安排決定。這些標簽允許管理者將節(jié)點組與不同的安全區(qū)域連接到一起，以限制敏感負載暴露，以及使相關機密信息更安全。

Docker Swarm Security

　　安全分發(fā)機密

　　除了加快身份標識發(fā)布過程之外，管理者節(jié)點還有存儲和分發(fā)工人節(jié)點所需要的任何資源的任務。機密信息像任何其它類型的資源一樣處理，并且基于安全的 mTLS 連接，從管理者推送到工人節(jié)點。

Docker Secrets

　　在主機上，Docker 企業(yè)版能確保機密僅提供給它們指定的容器。在同一個主機上的其它容器并不能訪問它們。Docker 以一個臨時文件系統(tǒng)的方式顯露機密給一個容器，確保機密總是保存在內(nèi)存中，并且從不寫入到磁盤。這種方式比其它競爭的替代者更加安全，比如，在環(huán)境變量中存儲它們。一旦這個任務完成，這個機密將永遠消失。

　　存儲機密

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

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

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

　　當一個節(jié)點被攻陷后發(fā)生了什么?

Docker Secrets

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

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

　　結(jié)論

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

　　·加入集群。阻止惡意節(jié)點加入到集群。

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

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

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

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

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

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

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

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

　　本文由 LCTT 原創(chuàng)編譯，Linux中國 榮譽推出