docker安全特性有：1、加密節點ID；2、基于TLS的認證機制；3、安全準入令牌；4、支持周期性證書自動更新的CA配置；5、加密集群存儲；6、加密網絡；7、Docker安全掃描；8、Docker內容信任；9、Docker密鑰等等。
本教程操作環境：linux5.9.8系統、docker-1.13.1版、Dell G3電腦。
Docker?平臺還引入了大量自有安全技術。Swarm 模式基于 TLS 構建，并且配置上極其簡單靈活。安全掃描對鏡像進行二進制源碼級別掃描，并提供已知缺陷的詳細報告。
Docker 內容信任允許用戶對內容進行簽名和認證，密鑰目前也是 Docker 中的一等公民。Docker 為這些安全技術設定了合理的默認值，但是用戶也可以自行修改配置，或者禁用這些安全技術。
Swarm 模式
Swarm 模式是 Docker 未來的趨勢。Swarm 模式支持用戶集群化管理多個 Docker 主機，同時還能通過聲明式的方式部署應用。
每個 Swarm 都由管理者和工作者節點構成，節點可以是 Linux 或者 windows。管理者節點構成了集群中的控制層，并負責集群配置以及工作負載的分配。工作者節點就是運行應用代碼的容器。
正如所預期的，Swarm 模式包括很多開箱即用的安全特性，同時還設置了合理的默認值。這些安全特性包括以下幾點。
-
加密節點 ID。
-
基于 TLS 的認證機制。
-
安全準入令牌。
-
支持周期性證書自動更新的 CA 配置。
-
加密集群存儲（配置 DB）。
-
加密網絡。
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 界面中，也有專門的地方來創建和管理密鑰。
在后臺，密鑰在創建后以及傳輸中都是加密的，使用時被掛載到內存文件系統，并且只對那些已經被授權了的服務開放訪問。這確實是一種綜合性的端到端解決方案。
下圖展示了其總體流程。
下面依次介紹上圖中所示工作流的每一步。
1) 密鑰被創建，并且發送到 Swarm。
2) 密鑰存放在集群存儲當中，并且是加密的（每個管理者節點都能訪問集群存儲）。
3) B 服務被創建，并且使用了該密鑰。
4) 密鑰傳輸到 B 服務的任務節點（容器）的過程是加密的。
5) B 服務的容器將密鑰解密并掛載到路徑 /run/secrets 下。這是一個臨時的內存文件系統（在 Windows Docker 中該步驟有所不同，因為 Windows 中沒有內存文件系統這個概念）。
6) 一旦容器（服務任務）完成，內存文件系統關閉，密鑰也隨之刪除。
7) A 服務中的容器不能訪問該密鑰。
用戶可以通過 docker secret 子命令來管理密鑰，可以通過在運行 docker service create 命令時附加 –secret，從而為某個服務指定密鑰。
推薦學習：《docker視頻教程》
