Docker安全特性

Docker 平臺還引入了大量自有安全技術。Swarm 模式基于 TLS 構建，并且配置上極其簡單靈活。安全掃描對鏡像進行二進制源碼級別掃描，并提供已知缺陷的詳細報告。

Docker 內容信任允許用戶對內容進行簽名和認證，密鑰目前也是 Docker 中的一等公民。Docker 為這些安全技術設定了合理的默認值，但是用戶也可以自行修改配置，或者禁用這些安全技術。

Swarm 模式

Swarm 模式是 Docker 未來的趨勢。Swarm 模式支持用戶集群化管理多個 Docker 主機，同時還能通過聲明式的方式部署應用。

每個 Swarm 都由管理者和工作者節點構成，節點可以是 Linux 或者 Windows。管理者節點構成了集群中的控制層，并負責集群配置以及工作負載的分配。工作者節點就是運行應用代碼的容器。

正如所預期的，Swarm 模式包括很多開箱即用的安全特性，同時還設置了合理的默認值。這些安全特性包括以下幾點。

? 加密節點 ID。

? 基于 TLS 的認證機制。

? 安全準入令牌。

? 支持周期性證書自動更新的 CA 配置。

? 加密集群存儲(配置 DB)。

? 加密網絡。

接下來將詳細介紹如何構建安全的 Swarm，以及如何進行安全相關的配置。

為了完成下面的內容，需要至少 3 個 Docker 主機，每個都運行 1.13 或者更高版本的 Docker。示例中 3 個 Docker 主機分別叫作“mgr1”“mgr2”“wrk1”。

每臺主機上都安裝 Ubuntu 16.04，其上運行了 Docker 18.01.0-ce。同時還有一個網絡負責聯通 3 臺主機，并且主機之間可以通過名稱互相 ping 通。安裝完成后如下圖所示。

配置安全的 Swarm 集群

可以在其 Swarm 集群管理者節點上運行下面的命令。在本例中，命令運行于“mgr1”節點之上。

$ docker swarm init
Swarm initialized: current node (7xam...662z) is now a manager.

To add a worker to this swarm, run the following command:

docker swarm join --token \
SWMTKN-1-1dmtwu...r17stb-ehp8g...hw738q 172.31.5.251:2377

To add a manager to this swarm, run 'docker swarm join-token manager'
and follow the instructions.

上面的命令就是配置安全 Swarm 集群所要做的全部工作!

“mgr1”被配置為 Swarm 集群中的第一個管理節點，也是根 CA 節點。Swarm 集群已經被賦予了加密 Swarm ID，同時“mgr1”節點為自己發布了一個客戶端認證信息，標明自己是Swarm集群管理者。

證書的更新周期默認設置為 90 天，集群配置數據庫也已經配置完成并且處于加密狀態。安全令牌也已經成功創建，允許新的管理者和工作者節點加入到 Swarm 集群中。

實驗環境如下圖所示。

現在將“mgr2”節點加入到集群中，作為額外的管理者節點。

將新的管理者節點加入到 Swarm 需要兩步。第一步，需要提取加入管理者到集群中所需的令牌;第二步，在“mgr2”節點上執行 docker swarm join 命令。只要將管理者準入令牌作為 docker swarm join 命令的一部分，“mgr2”就作為管理者節點加入 Swarm。

在“mgr1”上運行下面的命令獲取管理者準入令牌。

$ docker swarm join-token manager
To add a manager to this swarm, run the following command:

docker swarm join --token \
SWMTKN-1-1dmtwu...r17stb-2axi5...8p7glz \
172.31.5.251:2377

命令輸出內容給出了管理者加入 Swarm 所需運行的準確命令。準入令牌和 IP 地址在讀者自己的實驗環境中是不一樣的。

復制該命令并在“mgr2”節點上運行。

$ docker swarm join --token SWMTKN-1-1dmtwu...r17stb-2axi5...8p7glz \
> 172.31.5.251:2377

This node joined a swarm as a manager.

mgr2”現在已經作為另一個管理者加入 Swarm。

join 命令的格式是 docker swarm join --token <manager-join-token> <ip-of-existing-manager>:<swarm-port>。

可以通過在任意管理者節點上運行 docker node ls 命令來確認上述操作。

$ docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS
7xamk...ge662z mgr1 Ready Active Leader
i0ue4...zcjm7f * mgr2 Ready Active Reachable

上述輸出內容中顯示“mgr1”和“mgr2”都加入了 Swarm，并且都是 Swarm 管理者。最新的配置如下圖所示。

兩個管理者這個數量，大概是最糟糕的一種情況了。但是這只是一個實驗環境，而不是什么核心業務生產環境，所以糟糕點也無所謂。

向 Swarm 中加入工作者也只需兩步。第一步需要獲取新工作者的準入令牌，第二步是在工作者節點上運行 docker swarm join 命令。

在任意管理者節點上運行下面的命令，獲取工作者準入令牌。

$ docker swarm join-token worker

To add a worker to this swarm, run the following command:

docker swarm join --token \
SWMTKN-1-1dmtw...17stb-ehp8g...w738q \
172.31.5.251:2377

可以在指定工作者的節點上運行該命令。準入令牌和 IP 地址會有所不同。

復制如下所示命令到“wrk1”上并且運行。

$ docker swarm join --token SWMTKN-1-1dmtw...17stb-ehp8g...w738q \
> 172.31.5.251:2377

This node joined a swarm as a worker.

在任意 Swarm 管理者上運行 docker node ls 命令。

$ docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS
7xamk...ge662z * mgr1 Ready Active Leader
ailrd...ofzv1u wrk1 Ready Active
i0ue4...zcjm7f mgr2 Ready Active Reachable

目前已經擁有包含兩個管理者和一個工作者的 Swarm 集群。管理者配置為高可用(HA)，并且復用集群存儲。最新的配置如下圖所示。

了解 Swarm 安全背后的原理

到目前為止，已經成功搭建了安全的 Swarm 集群。接下來一起花費幾分鐘了解一下這背后涉及的安全技術。

⒈ Swarm 準入令牌

向某個現存的 Swarm 中加入管理者和工作者所需的唯一憑證就是準入令牌。因此，保證準入令牌的安全十分關鍵!不要將其發布到公開的 Github 倉庫中。

每個 Swarm 都包含兩種不同準入令牌。管理者所需準入令牌和工作者所需準入令牌。

有必要理解 Swarm 準入令牌的格式。每個準入令牌都由 4 個不同的字段構成，中間采用虛線(-)連接。

PREFIX - VERSION - SWARM ID - TOKEN

PREFIX 永遠是“SWMTKN”，這樣允許工作者通過表達式匹配到該令牌，以避免意外將其發布到公共環境當中;VERSION 這一列則展示了 Swarm 的版本信息;SWARM ID 列是 Swarm 認證信息的一個哈希值;TOKEN 這一列的內容決定了該令牌是管理者還是工作者的準入令牌。

如下所示，對于指定 Swarm 的管理者和工作者準入令牌，除了最后 TOKEN 字段的內容之外沒有任何區別。

? 管理者：SWMTKN-1-1dmtwusdc...r17stb-2axi53zjbs45lqxykaw8p7glz。

? 工作者：SWMTKN-1-1dmtwusdc...r17stb-ehp8gltji64jbl45zl6hw738q。

如果用戶認為當前準入令牌存在風險，僅用一條命令就可以取消該準入令牌授權，同時發布新的準入令牌。在下面的示例中，取消了已經授權的管理者準入令牌，之后又發布了新的令牌。

$ docker swarm join-token --rotate manager

Successfully rotated manager join token.

To add a manager to this swarm, run the following command:

docker swarm join --token \
SWMTKN-1-1dmtwu...r17stb-1i7txlh6k3hb921z3yjtcjrc7 \
172.31.5.251:2377

需要注意的是，新舊令牌只有最后字段存在區別。SWARM ID 還是相同的。準入令牌保存在集群配置的數據庫中，默認是加密的。

⒉ TLS 和雙向認證

每個加入 Swarm 的管理者和工作者節點，都需要發布自己的客戶端證書。這個證書用于雙向認證。證書中定義了節點相關信息，包括從屬的 Swarm 集群以及該節點在集群中的身份(管理者還是工作者)。

在 Linux 主機上，可以指定使用下面的命令查看指定節點的客戶端證書。

$ sudo openssl x509 \
-in /var/lib/docker/swarm/certificates/swarm-node.crt \
-text

Certificate:
Data:
Version: 3 (0x2)
Serial Number:
80:2c:a7:b1:28...a8:af:89:a1:2a:51:89
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN=swarm-ca
Validity
Not Before: Jul 19 07:56:00 2017 GMT
Not After : Oct 17 08:56:00 2017 GMT
Subject: O=mfbkgjm2tlametbnfqt2zid8x, OU=swarm-manager,
CN=7xamk8w3hz9q5kgr7xyge662z
Subject Public Key Info:
<SNIP>

上述輸出中，Subject 中用到了 O、OU 以及 CN 字段分別表示 Swarm ID、節點角色以及節點 ID 信息。

組織字段 O 保存的是 Swarm ID。組織單元字段 OU 保存的是節點在 Swarm 中的角色。規范名稱字段 CN 保存的是節點的加密 ID。如下圖所示。

在 Validity 中，還可以直接看到證書的更新周期。

上述信息可以在 docker system info 命令的輸出中得到驗證。

<< Relates to the CN field Is<< Relates to the OU field<< Relates to the O field ...<< Relates to Validity field

⒊ 配置一些 CA 信息

通過 docker swarm update 命令可以配置 Swarm 證書的更新周期。下面的示例中，將 Swarm 的證書更新周期修改為 30 天。

$ docker swarm update --cert-expiry 720h

Swarm 允許節點在證書過期前重新創建證書，這樣可以保證 Swarm 中全部節點不會在同一時間嘗試更新自己的證書信息。

可以在創建 Swarm 的時候，通過在 docker swarm init 命令中增加 --external-ca 參數來指定外部的 CA。docker swarm ca 命令可以用于管理 CA 相關配置?？梢栽谶\行該命令時指定 --help 來查看命令功能。

$ docker swarm ca --help

Usage: docker swarm ca [OPTIONS]

Manage root CA

Options:
--ca-cert pem-file Path to the PEM-formatted root CA
certificate to use for the new cluster Path
--ca-key pem-file to the PEM-formatted root CA
key to use for the new cluster
--cert-expiry duration Validity period for node certificates
(ns|us|ms|s|m|h) (default 2160h0m0s)
-d, --detach Exit immediately instead of waiting for the
root rotation to converge Specifications of
--external-ca external-ca one or more certificate signing endpoints
Print usage
--help Suppress progress output
-q, --quiet Rotate the swarm CA - if no certificate
--rotate or key are provided, new ones will be gene\

⒋ 集群存儲

集群存儲是 Swarm 的大腦，保存了集群配置和狀態數據。存儲目前是基于 etcd 的某種實現，并且會在 Swarm 內所有管理者之間自動復制。存儲默認也是加密的。

集群存儲正逐漸成為很多 Docker 平臺的關鍵技術。例如，Docker 網絡和 Docker 密鑰都用到了集群存儲。

Docker 平臺的很多部分都已經用到了集群存儲，未來對集群存儲的利用會更多，而這也是 Swarm 模式在 Docker 規劃中占據重要地位的原因之一。這還意味著，如果不使用 Swarm 模式運行 Docker，很多 Docker 特性就無法使用。

集群存儲的日常維護由 Docker 自動完成。但是，在生產環境中，需要為集群存儲提供完整的備份和恢復方案。

Swarm 模式安全部分的內容到此為止。

Docker 安全掃描

快速發現代碼缺陷的能力至關重要。Docker 安全掃描功能使得對 Docker 鏡像中已知缺陷的檢測工作變得簡單。

Docker 安全掃描已經可以用于 Docker Hub 上私有倉庫的鏡像了。同時該技術還可以作為 Docker 可信服務本地化部署解決方案的一部分。最后，所有官方 Docker 鏡像都經過了安全掃描，掃描報告在其倉庫中可以查閱。

Docker 安全掃描對 Docker 鏡像進行二進制代碼級別的掃描，對其中的軟件根據已知缺陷數據庫(CVE 數據庫)進行檢查。在掃描執行完成后，會生成一份詳細報告。

打開瀏覽器訪問 Docker Hub，并搜索 Alpine 倉庫。下圖展示了官方 Alpine 倉庫的 Tags 標簽頁。

Alpine 倉庫是官方倉庫，這意味著該倉庫會自動掃描并生成對應報告?？梢钥吹?，鏡像標簽為 edge、lates 以及 3.6 的鏡像都通過了已知缺陷的檢查。但是 alpine:3.5 鏡像存在已知缺陷(標紅)。

如果打開 alpine:3.5 鏡像，可以發現如下圖所示的詳細信息。

這是發現自己軟件中已知缺陷詳情的一種簡單方式。

Docker 可信鏡像倉庫服務(Docker Trusted Registry, DTR)，屬于 Docker 企業版中本地化鏡像倉庫服務的一部分內容，提供了相同的 Capability，同時還允許用戶自行控制其鏡像掃描時機以及掃描方式。

例如，DTR 允許用戶選擇鏡像是在推送時自動觸發掃描，還是只能手工觸發。同時 DTR 還允許用戶手動更新 CVE 數據庫，這對于 DTL 無法進行聯網來自動更新 CVE 數據的場景來說，是一種理想的解決方案。

這就是 Docker 安全掃描，一種深入檢測 Docker 鏡像是否存在已知安全缺陷的好方式。當然，能力越大責任越大，當用戶發現缺陷后，就需要承擔解決相應缺陷的責任了。

Docker 內容信任

Dockr 內容信任(Docker Content Trust，DCT)使得用戶很容易就能確認所下載鏡像的完整性以及其發布者。在不可信任的網絡環境中下載鏡像時，這一點很重要。

從更高層面來看，DCT 允許開發者對發布到 Docker Hub 或者 Docker 可信服務的鏡像進行簽名。當這些鏡像被拉取的時候，會自動確認簽名狀態。下圖展示了這一過程。

DCT 還可以提供關鍵上下文，如鏡像是否已被簽名從而可用于生產環境，鏡像是否被新版本取代而過時等。

DTC 提供的上下文還在初期，配置起來相當復雜。在 Docker 主機上啟用 DCT 功能，所要做的只是在環境中將 DOCKER_CONTENT_TRUST 變量設置為 1。

$ export DOCKER_CONTENT_TRUST=1

在實際環境中，用戶可能希望在系統中默認開啟該特性。

如果使用 Docker 統一配置層(Docker 企業版的一部分)，需要勾選下圖所示 Run Only Signed Images 復選項。這樣會強制所有在 UCP 集群中的節點只運行已簽名鏡像。

由上圖中可知，UCP 在 DCT 的基礎上進行進一步封裝，提供了已簽名鏡像的安全首選項信息。例如，用戶可能有這樣的需求：在生產環境中只能使用由 secops 簽名的鏡像。

一旦 DCT 功能開啟，就不能獲取并使用未簽名鏡像了。下圖展示了開啟 DCT 之后，如果再次嘗試通過 Docker CLI 或者 UCP Web UI 界面拉取未簽名鏡像時所報的錯誤(兩個示例都嘗試拉取標簽為“unsigned”的鏡像)。

下圖展示了 DCT 是如何阻止 Docker 客戶端拉取一個被篡改的鏡像的。

下圖展示了 DCT 如何阻止客戶端拉取舊鏡像。

Docker 內容信任是一種很重要的技術，能幫助用戶檢查從 Docker 服務中拉取的鏡像。該技術的基礎模式配置起來非常簡單，但是類似上下文等一些高級特性，現階段配置起來還是非常復雜的。

Docker 密鑰

很多應用都需要密鑰。比如密碼、TLS 證書、SSH key 等。

在 Docker1.13 版本之前，沒有一種標準且安全的方式能讓密鑰在應用間實現共享。常見的方式是開發人員將密鑰以文本的方式寫入環境變量。這與理想狀態差距甚遠。

Docker1.13 引入了 Docker 密鑰，將密鑰變成 Docker 生態系統中的一等公民。例如，增加了一個新的子命令 docker secret 來管理密鑰。在 Docker 的 UCP 界面中，也有專門的地方來創建和管理密鑰。

在后臺，密鑰在創建后以及傳輸中都是加密的，使用時被掛載到內存文件系統，并且只對那些已經被授權了的服務開放訪問。這確實是一種綜合性的端到端解決方案。

下圖展示了其總體流程。

下面依次介紹上圖中所示工作流的每一步。

⒈ 密鑰被創建，并且發送到 Swarm。

⒉ 密鑰存放在集群存儲當中，并且是加密的(每個管理者節點都能訪問集群存儲)。

⒊ B 服務被創建，并且使用了該密鑰。

⒋ 密鑰傳輸到 B 服務的任務節點(容器)的過程是加密的。

⒌ B 服務的容器將密鑰解密并掛載到路徑 /run/secrets 下。這是一個臨時的內存文件系統(在 Windows Docker 中該步驟有所不同，因為 Windows 中沒有內存文件系統這個概念)。

⒍ 一旦容器(服務任務)完成，內存文件系統關閉，密鑰也隨之刪除。

⒎ A 服務中的容器不能訪問該密鑰。

用戶可以通過 docker secret 子命令來管理密鑰，可以通過在運行 docker service create 命令時附加 --secret，從而為某個服務指定密鑰。