)
云原生后端微服務(wù)【免費下載鏈接】classicswarmSwarm Classic: a container clustering system. Not to be confused with Docker Swarm which is at https://github.com/docker/swarmkit項目地址https://gitcode.com/gh_mirrors/cl/classicswarm點擊查看免費下載Docker SwarmClassic Swarm集群中的所有節(jié)點都必須在網(wǎng)絡(luò)上綁定 Docker daemon 端口這帶來顯而易見的安全風(fēng)險——當(dāng)網(wǎng)絡(luò)不可信如公網(wǎng)時風(fēng)險成倍放大。本文以docs/secure-swarm-tls.md與docs/configure-tls.md為主線系統(tǒng)講解 TLS 與 PKI 的基礎(chǔ)概念、三種證書簽發(fā)模式并給出從零搭建「CA 服務(wù)器 swarm manager 雙節(jié)點 遠程客戶端」五機 TLS 環(huán)境的完整九步實操同時結(jié)合本倉庫源碼cli/manage.go、api/server.go、cluster/httpclient.go 等說明 TLS 在 Swarm 內(nèi)部的真實作用路徑。讀完本文你將能夠獨立為 Docker Classic Swarm 集群配置雙向 TLS 認證并理解其底層實現(xiàn)原理。為什么 Swarm 集群需要 TLSDocker Classic Swarm 是一個容器集群系統(tǒng)它把多臺 Docker 主機的計算資源聚合成一個虛擬的、巨大的 Docker Engine。為此集群中的每一臺節(jié)點包括 swarm manager 與 swarm 節(jié)點都必須把 Docker daemon 綁定到網(wǎng)絡(luò)端口上接受來自網(wǎng)絡(luò)的命令。一旦端口暴露到不受信任的網(wǎng)絡(luò)例如互聯(lián)網(wǎng)攻擊者就可能直接向 daemon 發(fā)送惡意命令創(chuàng)建容器、拉取鏡像、讀寫數(shù)據(jù)卷實施中間人攻擊man-in-the-middle篡改客戶端與 daemon 之間的通信內(nèi)容。為了緩解這些風(fēng)險Docker Swarm 與 Docker Engine daemon 支持傳輸層安全協(xié)議Transport Layer SecurityTLS。TLS 是 SSLSecure Sockets Layer的繼任者兩者經(jīng)常被混用Docker 使用的是 TLS本文統(tǒng)一使用 TLS 一詞。生產(chǎn)規(guī)劃文檔 docs/plan-for-production.md 也明確指出所有節(jié)點都必須綁定網(wǎng)絡(luò)端口Swarm 與 Engine 通過 TLS 認證來緩解中間人攻擊等風(fēng)險并給出了 TLS 模式下的默認端口約定組件默認 TLS 端口Engine daemon2376/tcpSwarm manager3376/tcp非 TLS 模式下Engine 與 Swarm 的默認端口分別為2375/tcp與3375/tcp。先理解 TLS 與 PKI 的基本概念在動手配置之前先弄清 TLS 與公鑰基礎(chǔ)設(shè)施Public Key InfrastructurePKI的核心概念。PKI 是一套用于創(chuàng)建和管理數(shù)字證書的安全技術(shù)、策略與流程的組合這些證書與基礎(chǔ)設(shè)施通過認證authentication與加密encryption等機制保護數(shù)字通信。護照類比護照用于驗證一個人的身份包含持有人照片與生物特征信息還列出了簽發(fā)國家以及valid from生效日與valid to失效日日期。數(shù)字證書與此非常相似。下面是從一張數(shù)字證書中摘錄的內(nèi)容Certificate: Data: Version: 3 (0x2) Serial Number: 9590646456311914051 (0x8518d2237ad49e43) Signature Algorithm: sha256WithRSAEncryption Issuer: CUS, STCA, LSanfrancisco, ODocker Inc Validity Not Before: Jan 18 09:42:16 2016 GMT Not After : Jan 15 09:42:16 2026 GMT Subject: CNswarm這張證書標識的是一臺名為swarm的計算機有效期從 2016 年 1 月到 2026 年 1 月由位于美國加州舊金山的 Docker Inc. 簽發(fā)。正如護照在登機、過海關(guān)時認證個人身份數(shù)字證書在網(wǎng)絡(luò)上認證計算機的身份。PKI 則是在幕后支撐數(shù)字證書的技術(shù)、策略與流程組合主要包括安全地請求證書的服務(wù)認證證書請求實體身份的程序判斷實體是否有資格獲得證書的程序簽發(fā)證書的技術(shù)與流程吊銷證書的技術(shù)與流程。Docker Engine 如何利用 TLS 進行認證你可以同時配置 Docker Engine CLI 與 Docker Engine daemon 要求使用 TLS 進行認證。配置 TLS 意味著CLI 與 daemon 之間的所有通信都必須附帶并經(jīng)由受信任的數(shù)字證書簽名。Docker Engine CLI 必須先出示自己的數(shù)字證書daemon 才會接受它發(fā)來的命令。與此同時daemon 也必須信任 CLI 所使用的證書。這種信任通常經(jīng)由可信第三方建立——即圖中的 Certificate AuthorityCA證書頒發(fā)機構(gòu)服務(wù)器。圖中的可信第三方就是 CA 服務(wù)器。如同護照示例中的國家CA 負責(zé)創(chuàng)建、簽名、簽發(fā)和吊銷證書。信任的建立方式是在運行 Docker Engine daemon 的主機上安裝 CA 的根證書然后 Docker Engine CLI 向 CA 服務(wù)器請求自己的證書由 CA 簽名后簽發(fā)給它。工作流程如下Docker Engine CLI 在發(fā)出命令前先把證書發(fā)送給 Docker Engine daemondaemon 檢查證書——由于 daemon 信任該 CA它會自動信任任何由該 CA 簽名的證書假設(shè)證書有效未過期、未被吊銷等daemon 就接受來自這個可信 CLI 的命令。需要強調(diào)Docker Engine CLI 本質(zhì)上只是使用 Docker Engine API 與 daemon 通信的一個客戶端。任何使用 Docker Engine API 的客戶端都可以使用 TLS。例如 Docker Universal Control PlaneUCP內(nèi)置了 TLS 支持其他基于 Docker Engine API 的第三方產(chǎn)品也可以這樣配置。Docker 與 Swarm 的三種 TLS 配置模式根據(jù)承擔(dān) CA 角色的實體類型不同Docker Engine daemon 及其客戶端存在三種可能的 TLS 配置外部第三方 CAExternal 3rd party CA內(nèi)部企業(yè) CAInternal corporate CA自簽名證書Self-signed certificates外部第三方 CA外部 CA 是受信任的第三方公司提供創(chuàng)建、簽發(fā)、吊銷和管理證書的服務(wù)。說它們「受信任」是因為它們必須滿足特定條件、保持高水準的安全與商業(yè)實踐才能贏得你的業(yè)務(wù)同時你也需要安裝外部 CA 的根證書才能讓計算機和服務(wù)信任它們。使用外部第三方 CA 時證書的創(chuàng)建、簽名、簽發(fā)、吊銷與管理全部由它負責(zé)。這類服務(wù)通常收費但被公認為企業(yè)級、可擴展的解決方案能提供較高程度的信任。內(nèi)部企業(yè) CA許多組織選擇搭建自己的 CA 與 PKI常見實現(xiàn)包括 OpenSSL 和 Microsoft Active Directory。這種情況下你的公司自己就是 CA需要承擔(dān) CA 的全部工作。好處是作為自己的 CA你對 PKI 擁有更強的控制力。自建 CA 與 PKI 需要你自行提供外部第三方 CA 提供的全部服務(wù)包括創(chuàng)建、簽發(fā)、吊銷和管理證書。自己做這些事有相應(yīng)的成本與開銷但對大型企業(yè)而言與使用外部第三方服務(wù)相比仍可能降低成本。假設(shè)你的內(nèi)部 CA 與 PKI 運營管理得當(dāng)內(nèi)部企業(yè) CA 可以是一種高度可擴展、高度安全的選擇。自簽名證書顧名思義自簽名證書是用自己的私鑰簽名的證書而不是由受信任的 CA 簽名。這是低成本、易用的選擇。如果正確實現(xiàn)和管理自簽名證書它們比完全沒有證書要好。但由于自簽名證書缺少完整的 PKI擴展性差也缺少其他兩種方案提供的許多優(yōu)勢。一個明顯的缺點是自簽名證書無法吊銷。由于這一點及其他限制自簽名證書被認為是三種方案中最不安全的不建議在暴露于不受信任網(wǎng)絡(luò)的公網(wǎng)生產(chǎn)負載中使用。實戰(zhàn)為 Docker Swarm 集群配置 TLS九步全流程下面的流程將創(chuàng)建一個兩節(jié)點的 swarm 集群外加一個 Docker Engine CLI、一個 swarm manager 和一個 CA 服務(wù)器如圖所示。所有 Docker Engine 主機client、swarm、node1、node2都擁有 CA 證書副本以及由 CA 簽發(fā)的各自密鑰對。流程包含以下步驟Step 1: 準備前置條件Step 2: 創(chuàng)建 CA 服務(wù)器Step 3: 創(chuàng)建并簽發(fā)密鑰Step 4: 安裝密鑰Step 5: 為 Engine daemon 配置 TLSStep 6: 創(chuàng)建 swarm 集群Step 7: 使用 TLS 啟動 swarm managerStep 8: 測試 swarm manager 配置Step 9: 配置 Engine CLI 使用 TLS開始之前的重要提示下文包含使用 OpenSSL 自建 CA 的步驟這與運營內(nèi)部企業(yè) CA 和 PKI 類似。但絕不能把這里的步驟當(dāng)作搭建生產(chǎn)級內(nèi)部 CA 與 PKI 的指南。這些步驟僅用于演示目的——讓沒有現(xiàn)成 CA 和證書的讀者也能跟著操作完成 Swarm 的 TLS 配置。Step 1: 準備前置條件完成本流程需要準備 5 臺 Linux 服務(wù)器可以是物理機與虛擬機的任意組合可位于本地或公有云。各服務(wù)器的名稱與用途如下服務(wù)器名說明ca充當(dāng) Certificate AuthorityCA服務(wù)器swarm充當(dāng) swarm managernode1充當(dāng) swarm 節(jié)點node2充當(dāng) swarm 節(jié)點client充當(dāng)遠程 Docker Engine 客戶端確保你能通過 SSH 訪問全部 5 臺服務(wù)器且它們能通過 DNS 名稱解析相互通信。特別要注意在 swarm manager 與 swarm 節(jié)點之間開放 TCP 端口2376在 Docker Engine client 與 swarm manager 之間開放 TCP 端口3376。如果這些端口已被占用可以選擇其他端口但本示例假設(shè)使用這些端口。每臺服務(wù)器必須運行與 Docker Engine 兼容的操作系統(tǒng)為簡便起見后續(xù)步驟假設(shè)所有服務(wù)器都運行 Ubuntu 14.04 LTS。Step 2: 創(chuàng)建 CA 服務(wù)器注意如果你已經(jīng)擁有 CA 和證書且熟悉其使用可以跳過本步直接進入下一步。本步把一臺 Linux 服務(wù)器配置為 CA用它來創(chuàng)建和簽發(fā)密鑰。再次強調(diào)這只是為了讓沒有現(xiàn)成 CA 的讀者可以跟隨完成后續(xù)步驟不是生產(chǎn)級 CA 的部署范本。登錄 CA 服務(wù)器的終端并提升為 root$ sudo su為 CA 創(chuàng)建私鑰ca-priv-key.pem# openssl genrsa -out ca-priv-key.pem 2048 Generating RSA private key, 2048 bit long modulus ........................................................... ..... e is 65537 (0x10001)為 CA 創(chuàng)建公鑰ca.pem。公鑰基于上一步創(chuàng)建的私鑰# openssl req -config /usr/lib/ssl/openssl.cnf -new -key ca-priv-key.pem -x509 -days 1825 -out ca.pem You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter ., the field will be left blank. ----- Country Name (2 letter code) [AU]:US output truncated這里的-days 1825意味著 CA 證書有效期約為 5 年1825 天。至此你已配置好一個擁有公私鑰對的 CA 服務(wù)器?？梢詸z查每個密鑰的內(nèi)容用openssl rsa -in ca-priv-key.pem -noout -text檢查私鑰用openssl x509 -in ca.pem -noout -text檢查公鑰證書。下面是 CA 公鑰的部分內(nèi)容# openssl x509 -in ca.pem -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: 17432010264024107661 (0xf1eaf0f9f41eca8d) Signature Algorithm: sha256WithRSAEncryption Issuer: CUS, STCA, LSanfrancisco, ODocker Inc Validity Not Before: Jan 16 18:28:12 2016 GMT Not After : Jan 13 18:28:12 2026 GMT Subject: CUS, STCA, LSan Francisco, ODocker Inc Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:d1:fe:6e:55:d4:93:fc:c9:8a:04:07:2d:ba:f0: 55:97:c5:2c:f5:d7:1d:6a:9b:f0:f0:55:6c:5d:90: output truncated稍后你將用這張證書為基礎(chǔ)設(shè)施中的其他服務(wù)器簽發(fā)密鑰。Step 3: 創(chuàng)建并簽發(fā)密鑰現(xiàn)在 CA 已就緒你需要為 swarm manager、swarm 節(jié)點和遠程 Docker Engine client 創(chuàng)建密鑰對。所有服務(wù)器的密鑰對創(chuàng)建命令與流程完全相同。涉及的關(guān)鍵文件如下文件說明ca-priv-key.pemCA 的私鑰必須妥善保管。稍后用它為環(huán)境中其他節(jié)點簽發(fā)新密鑰。與ca.pem一起構(gòu)成 CA 的密鑰對。ca.pemCA 的公鑰即證書。安裝到環(huán)境中所有節(jié)點上使所有節(jié)點信任由該 CA 簽名的證書。與ca-priv-key.pem一起構(gòu)成 CA 的密鑰對。NODE_NAME.csr證書簽名請求CSR。CSR 本質(zhì)上是向 CA 申請為某個節(jié)點創(chuàng)建新密鑰對的申請單。CA 根據(jù) CSR 提供的信息生成該節(jié)點的公私鑰對。NODE_NAME-priv-key.pem由 CA 簽名的私鑰。節(jié)點用它向遠程 Docker Engine 認證自己的身份。與NODE_NAME-cert.pem一起構(gòu)成節(jié)點的密鑰對。NODE_NAME-cert.pem由 CA 簽名的證書。與NODE_NAME-priv-key.pem一起構(gòu)成節(jié)點的密鑰對。下面的命令演示如何為所有節(jié)點創(chuàng)建密鑰請在 CA 服務(wù)器上的一個工作目錄中執(zhí)行。登錄 CA 服務(wù)器終端并提升為 root$ sudo su為 swarm manager 創(chuàng)建私鑰swarm-priv-key.pem# openssl genrsa -out swarm-priv-key.pem 2048 Generating RSA private key, 2048 bit long modulus ............................................................ ........ e is 65537 (0x10001)用上一步創(chuàng)建的私鑰生成證書簽名請求CSRswarm.csr# openssl req -subj /CNswarm -new -key swarm-priv-key.pem -out swarm.csr注意這僅用于演示目的。真實生產(chǎn)環(huán)境中創(chuàng)建 CSR 的流程略有不同。這里-subj /CNswarm直接指定了證書的主體名Common Name為swarm即前面證書示例中Subject: CNswarm所對應(yīng)的身份?；谏弦徊絼?chuàng)建的 CSR 生成證書swarm-cert.pem# openssl x509 -req -days 1825 -in swarm.csr -CA ca.pem -CAkey ca-priv-key.pem -CAcreateserial -out swarm-cert.pem -extensions v3_req -extfile /usr/lib/ssl/openssl.cnf snip # openssl rsa -in swarm-priv-key.pem -out swarm-priv-key.pem至此你擁有了 swarm manager 的密鑰對。對其余節(jié)點node1、node2、client重復(fù)上述步驟。注意把swarm相關(guān)的取值替換為正在創(chuàng)建密鑰對的節(jié)點對應(yīng)的值服務(wù)器名私鑰CSR證書node1node1-priv-key.pemnode1.csrnode1-cert.pemnode2node2-priv-key.pemnode2.csrnode2-cert.pemclientclient-priv-key.pemclient.csrclient-cert.pem驗證工作目錄包含以下文件# ls -l total 64 -rw-r--r-- 1 root root 1679 Jan 16 18:27 ca-priv-key.pem -rw-r--r-- 1 root root 1229 Jan 16 18:28 ca.pem -rw-r--r-- 1 root root 17 Jan 18 09:56 ca.srl -rw-r--r-- 1 root root 1086 Jan 18 09:56 client-cert.pem -rw-r--r-- 1 root root 887 Jan 18 09:55 client.csr -rw-r--r-- 1 root root 1679 Jan 18 09:56 client-priv-key.pem -rw-r--r-- 1 root root 1082 Jan 18 09:44 node1-cert.pem -rw-r--r-- 1 root root 887 Jan 18 09:43 node1.csr -rw-r--r-- 1 root root 1675 Jan 18 09:44 node1-priv-key.pem -rw-r--r-- 1 root root 1082 Jan 18 09:49 node2-cert.pem -rw-r--r-- 1 root root 887 Jan 18 09:49 node2.csr -rw-r--r-- 1 root root 1675 Jan 18 09:49 node2-priv-key.pem -rw-r--r-- 1 root root 1082 Jan 18 09:42 swarm-cert.pem -rw-r--r-- 1 root root 887 Jan 18 09:41 swarm.csr -rw-r--r-- 1 root root 1679 Jan 18 09:42 swarm-priv-key.pemca.srl是 CA 自動生成的序列號文件由-CAcreateserial參數(shù)產(chǎn)生CA 用它記錄已簽發(fā)證書的序列號。你可以用openssl rsa -in key-name -noout -text檢查私鑰用openssl x509 -in key-name -noout -text檢查公鑰。下面是 swarm manager 公鑰swarm-cert.pem的部分內(nèi)容# openssl x509 -in ca.pem -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: 9590646456311914051 (0x8518d2237ad49e43) Signature Algorithm: sha256WithRSAEncryption Issuer: CUS, STCA, LSanfrancisco, ODocker Inc Validity Not Before: Jan 18 09:42:16 2016 GMT Not After : Jan 15 09:42:16 2026 GMT Subject: CNswarm output truncated可以看到Subject: CNswarm對應(yīng)前面openssl req -subj /CNswarm設(shè)定的主體名。Step 4: 安裝密鑰本步把密鑰安裝到基礎(chǔ)設(shè)施中對應(yīng)的服務(wù)器上。每臺服務(wù)器需要三個文件CA 公鑰的副本ca.pem自己的私鑰自己的公鑰證書下面的步驟演示如何用scp把這些文件從 CA 服務(wù)器復(fù)制到各服務(wù)器。復(fù)制時按如下規(guī)則重命名文件原文件名復(fù)制后文件名ca.pemca.pemserver-cert.pemcert.pemserver-priv-key.pemkey.pem登錄 CA 服務(wù)器終端并提升為 root$ sudo su在 swarm manager 上創(chuàng)建~/.certs目錄。這里假設(shè)用戶賬戶是 ubuntu$ ssh ubuntuswarm mkdir -p /home/ubuntu/.certs把密鑰從 CA 復(fù)制到 swarm manager 服務(wù)器$ scp ./ca.pem ubuntuswarm:/home/ubuntu/.certs/ca.pem $ scp ./swarm-cert.pem ubuntuswarm:/home/ubuntu/.certs/cert.pem $ scp ./swarm-priv-key.pem ubuntuswarm:/home/ubuntu/.certs/key.pem注意scp命令可能需要提供認證。例如 AWS EC2 實例使用基于證書的認證。要把文件復(fù)制到與公鑰nigel.pem關(guān)聯(lián)的 EC2 實例scp命令需修改為scp -i /path/to/nigel.pem ./ca.pem ubuntuswarm:/home/ubuntu/.certs/ca.pem。對其余每臺服務(wù)器重復(fù)步驟 2 與 3node1node2client驗證你的工作。復(fù)制完成后每臺機器都應(yīng)擁有以下密鑰基礎(chǔ)設(shè)施中的每個節(jié)點都應(yīng)在/home/ubuntu/.certs/目錄下?lián)碛幸韵挛募? ls -l /home/ubuntu/.certs/ total 16 -rw-r--r-- 1 ubuntu ubuntu 1229 Jan 18 10:03 ca.pem -rw-r--r-- 1 ubuntu ubuntu 1082 Jan 18 10:06 cert.pem -rw-r--r-- 1 ubuntu ubuntu 1679 Jan 18 10:06 key.pemStep 5: 為 Engine daemon 配置 TLS上一步你已在每個 swarm 節(jié)點上創(chuàng)建并安裝了必要密鑰。本步把它們配置為監(jiān)聽網(wǎng)絡(luò)且只接受 TLS 連接。完成后swarm 節(jié)點將監(jiān)聽 TCP 端口2376并且只接受使用 TLS 的連接。在node1和node2你的 swarm 節(jié)點上執(zhí)行以下操作打開node1的終端并提升為 root$ sudo su向/etc/docker/daemon.json添加以下配置鍵。如果文件不存在則創(chuàng)建它{ hosts: [tcp://0.0.0.0:2376], tlsverify: true, tlscacert: /home/ubuntu/.certs/ca.pem, tlscert: /home/ubuntu/.certs/cert.pem, tlskey: /home/ubuntu/.certs/key.pem }重啟 Docker 使配置生效。如果文件不是合法 JSONDocker 將啟動失敗并輸出錯誤。各配置鍵含義如下配置鍵含義hostsdaemon 監(jiān)聽的地址與端口tcp://0.0.0.0:2376表示在所有網(wǎng)卡上以 TLS 端口 2376 提供服務(wù)tlsverify置為true啟用 TLS 并強制驗證客戶端證書雙向認證tlscacertCA 根證書路徑daemon 用它驗證客戶端證書鏈tlscertdaemon 自己的證書路徑tlskeydaemon 自己的私鑰路徑在node2上重復(fù)上述過程。從這里可以看出 TLS 的「雙向」特征daemon 不僅要向客戶端證明自己出示cert.pem/key.pem還要通過tlsverify與ca.pem反過來校驗客戶端身份。這正是 cli/manage.go 中l(wèi)oadTLSConfig所體現(xiàn)的行為——verify為真時加載 CA 證書池并設(shè)置ClientAuth tls.RequireAndVerifyClientCert強制要求客戶端提供由該 CA 簽發(fā)的證書。Step 6: 創(chuàng)建 swarm 集群接下來創(chuàng)建 swarm 集群。本流程使用默認的hosted discovery托管發(fā)現(xiàn)后端創(chuàng)建一個兩節(jié)點 swarm 集群。默認的 hosted discovery 后端使用 Docker Hub不建議用于生產(chǎn)環(huán)境。登錄 swarm manager 節(jié)點的終端。創(chuàng)建集群并把它的唯一 ID 導(dǎo)出到TOKEN環(huán)境變量$ sudo export TOKEN$(docker run --rm swarm create) Unable to find image swarm:latest locally latest: Pulling from library/swarm d681c900c6e3: Pulling fs layer snip 986340ab62f0: Pull complete a9975e2cc0a3: Pull complete Digest: sha256:c21fd414b0488637b1f05f13a59b032a3f9da5d818d31da1a4ca98a84c0c781b Status: Downloaded newer image for swarm:latestswarm create子命令會生成一個集群 token所有節(jié)點通過token://$TOKEN接入同一個集群。把node1加入集群。務(wù)必指定 TCP 端口2376而不是2375$ sudo docker run -d swarm join --addrnode1:2376 token://$TOKEN 7bacc98536ed6b4200825ff6f4004940eb2cec891e1df71c6bbf20157c5f9761把node2加入集群$ sudo docker run -d swarm join --addrnode2:2376 token://$TOKEN db3f49d397bad957202e91f0679ff84f526e74d6c5bf1b6734d834f5edcbca6cStep 7: 使用 TLS 啟動 swarm manager啟動一個啟用 TLS 的新容器$ docker run -d -p 3376:3376 -v /home/ubuntu/.certs:/certs:ro swarm manage --tlsverify --tlscacert/certs/ca.pem --tlscert/certs/cert.pem --tlskey/certs/key.pem --host0.0.0.0:3376 token://$TOKEN這條命令基于swarm鏡像啟動一個新容器并把服務(wù)器上的端口3376映射到容器內(nèi)的端口3376。這個映射確保發(fā)送到主機端口3376的 Docker Engine 命令會被轉(zhuǎn)發(fā)到容器內(nèi)的端口3376。容器以--tlsverify、--tlscacert、--tlscert和--tlskey選項運行swarm manage進程——這些選項強制進行 TLS 驗證并指定 swarm manager TLS 密鑰的位置。證書目錄/home/ubuntu/.certs以只讀方式掛載為容器內(nèi)/certs/certs/*.pem路徑即對應(yīng)上述三個--tls*參數(shù)。運行docker ps驗證 swarm manager 容器已啟動并運行$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 035dbf57b26e swarm /swarm manage --tlsv 7 seconds ago Up 7 seconds 2375/tcp, 0.0.0.0:3376-3376/tcp compassionate_lovelace源碼印證manage命令在 cli/manage.go 中先檢查--tls/--tlsverify標志若指定了它們而未提供--tlscert/--tlskey則直接報錯退出指定--tlsverify而未提供--tlscacert同樣報錯反之若只提供了--tlscert/--tlskey/--tlscacert而沒開--tls/--tlsverify也會被拒絕因為這些參數(shù)將被忽略。隨后 loadTLSConfig 會調(diào)用tls.LoadX509KeyPair加載證書私鑰并把 TLS 最低版本設(shè)為 TLS 1.2MinVersion: tls.VersionTLS12。校驗啟用時還會把 CA 證書讀入證書池同時設(shè)置ClientAuth tls.RequireAndVerifyClientCert與ClientCAs實現(xiàn)雙向認證。生成的tlsConfig最終被傳給 api.NewServer見 cli/manage.go與 swarm.NewCluster。api.Server在 newListener 中檢測到tlsConfig ! nil時會設(shè)置NextProtos []string{http/1.1}并用tls.NewListener包裝監(jiān)聽器——也就是說Swarm 對外暴露的 HTTPS 端口正是由這份 TLS 配置支撐的。你的 swarm 集群現(xiàn)在已配置為使用 TLS。Step 8: 測試 swarm manager 配置集群已構(gòu)建并配置 TLS現(xiàn)在用 Docker Engine CLI 驗證它是否工作。打開client服務(wù)器的終端。執(zhí)行docker version命令。執(zhí)行時必須傳入客戶端證書的位置$ sudo docker --tlsverify --tlscacert/home/ubuntu/.certs/ca.pem --tlscert/home/ubuntu/.certs/cert.pem --tlskey/home/ubuntu/.certs/key.pem -H swarm:3376 version Client: Version: 1.9.1 API version: 1.21 Go version: go1.4.2 Git commit: a34a1d5 Built: Fri Nov 20 13:12:04 UTC 2015 OS/Arch: linux/amd64 Server: Version: swarm/1.0.1 API version: 1.21 Go version: go1.5.2 Git commit: 744e3a3 Built: OS/Arch: linux/amd64輸出中Server的版本顯示為 swarm/1.0.1說明命令已成功發(fā)往 swarm manager。驗證同一命令在不帶 TLS 時無法工作。這次不向 swarm manager 傳證書$ sudo docker -H swarm:3376 version : Version: 1.9.1 API version: 1.21 Go version: go1.4.2 Git commit: a34a1d5 Built: Fri Nov 20 13:12:04 UTC 2015 OS/Arch: linux/amd64 Get http://swarm:3376/v1.21/version: malformed HTTP response \x15\x03\x01\x00\x02\x02. * Are you trying to connect to a TLS-enabled daemon without TLS?輸出顯示命令被服務(wù)器拒絕。這是因為服務(wù)器swarm manager配置為只接受使用 TLS 的已認證客戶端的連接。malformed HTTP response正是 TLS 握手失敗的典型特征客戶端用明文 HTTP 請求打到了一個只講 TLS 的端口上。源碼印證manager 通過 api.Server 對外服務(wù)而 swarm manager 把來自客戶端的請求轉(zhuǎn)發(fā)給后端節(jié)點時同樣使用 TLS。在 cluster/engine.go 的Connect中NewHTTPClientTimeout(tcp://e.Addr, config, ...)會在配置了 TLS 時把 URL scheme 從http自動切換為https見 cluster/httpclient.go并把tlsConfig裝進http.Transport此后 api/utils.go 的proxyAsync通過engine.HTTPClientAndScheme()取回這個帶 TLS 的客戶端完成對節(jié)點的反向代理。也就是說無論manage是代理普通 API 調(diào)用如proxyContainer還是代理attach類長連接hijack見 api/handlers.go 中hijack(c.tlsConfig, ...)的調(diào)用TLS 配置都會貫穿 client → manager → node 的完整鏈路。Step 9: 配置 Engine CLI 使用 TLS你可以配置 Engine使每次執(zhí)行命令時無需再傳 TLS 參數(shù)。方法是在 Docker Engine 客戶端上把Docker Engine host與TLS設(shè)置配置為默認值。具體做法把客戶端的密鑰放入~/.docker配置目錄。如果系統(tǒng)上有其他用戶使用 Engine 命令行也要配置他們的~/.docker。下面以 Docker Engine 客戶端上的ubuntu用戶為例。打開client服務(wù)器的終端。如果不存在在ubuntu用戶主目錄創(chuàng)建.docker目錄$ mkdir /home/ubuntu/.docker把 Docker Engine 客戶端的密鑰從/home/ubuntu/.certs復(fù)制到/home/ubuntu/.docker$ cp /home/ubuntu/.certs/{ca,cert,key}.pem /home/ubuntu/.docker編輯該賬戶的~/.bash_profile。設(shè)置以下變量變量說明DOCKER_HOST設(shè)置所有 Engine 命令要發(fā)送到的 Docker 主機與 TCP 端口。DOCKER_TLS_VERIFY告訴 Engine 使用 TLS。DOCKER_CERT_PATH指定 TLS 密鑰的位置。例如export DOCKER_HOSTtcp://swarm:3376 export DOCKER_TLS_VERIFY1 export DOCKER_CERT_PATH/home/ubuntu/.docker/保存并關(guān)閉文件。用source加載文件以拾取新變量$ source ~/.bash_profile執(zhí)行docker version驗證配置生效$ docker version Client: Version: 1.9.1 API version: 1.21 Go version: go1.4.2 Git commit: a34a1d5 Built: Fri Nov 20 13:12:04 UTC 2015 OS/Arch: linux/amd64 Server: Version: swarm/1.0.1 API version: 1.21 Go version: go1.5.2 Git commit: 744e3a3 Built: OS/Arch: linux/amd64輸出中的服務(wù)器部分說明你的 Docker 客戶端正在向 swarm manager 發(fā)送命令并使用 TLS。至此你已經(jīng)成功配置了一個使用 TLS 的 Docker swarm 集群。深入理解TLS 配置在 Swarm 源碼中的完整路徑結(jié)合前文九步實操從源碼結(jié)構(gòu)可以梳理出 TLS 在 Docker Classic Swarm 中的完整作用鏈路參數(shù)解析與校驗swarm manage的 TLS 相關(guān)命令行參數(shù)在 cli/flags.go 中定義為--tls、--tlscacert、--tlscert、--tlskey、--tlsverify五個 flag。其中--tls的用法說明是「use TLS; implied by --tlsverifytrue」--tlscacert被描述為「僅信任由此處給定 CA 簽名的證書的遠端」。TLS 配置對象構(gòu)建manage函數(shù)在 cli/manage.go 完成上述校驗后調(diào)用loadTLSConfigcli/manage.go構(gòu)建*tls.Config加載cert/key密鑰對設(shè)置最低 TLS 版本為 TLS 1.2--tlsverify開啟時加載 CA 證書池并要求客戶端證書RequireAndVerifyClientCert未開啟校驗時則InsecureSkipVerify true。對外服務(wù)端manager 自身tlsConfig傳入 api.NewServerListenAndServe在 newListener 中用tls.NewListener包裝 TCP 監(jiān)聽器使 manager 對外只接受 TLS 連接如0.0.0.0:3376。對內(nèi)連接端manager → 節(jié)點同一份tlsConfig傳入 swarm.NewCluster存入Cluster.TLSConfig節(jié)點經(jīng)發(fā)現(xiàn)服務(wù)注冊后validatePendingEngine調(diào)用engine.Connect(c.TLSConfig)cluster/swarm/cluster.go。Connect中NewHTTPClientTimeout會根據(jù)tlsConfig是否存在把節(jié)點 URL 切換為httpscluster/httpclient.go隨后的所有 API 代理api/utils.go與 attach/hijack 長連接api/handlers.go、api/utils.go都復(fù)用這份 TLS 配置。由此可見一份tlsConfig同時支撐了「客戶端 → swarm manager」與「swarm manager → 節(jié)點 daemon」兩段加密鏈路這也是文檔要求同時在 manager 與節(jié)點上安裝ca.pem、cert.pem、key.pem三件套的根本原因。相關(guān)文檔Secure Docker Swarm with TLS本文理論基礎(chǔ)篇Configure Docker Swarm for TLS九步實操完整版Plan for Swarm in production生產(chǎn)環(huán)境端口規(guī)劃與網(wǎng)絡(luò)訪問控制贊分享云原生后端微服務(wù)【免費下載鏈接】classicswarmSwarm Classic: a container clustering system. Not to be confused with Docker Swarm which is at https://github.com/docker/swarmkit項目地址https://gitcode.com/gh_mirrors/cl/classicswarm點擊查看免費下載相關(guān)推薦Docker Classic Swarm 配置 TLS基于 OpenSSL 自建 CA 的集群安全加固實戰(zhàn)Docker Classic Swarm 配置 TLS基于 OpenSSL 自建 CA 的集群安全加固實戰(zhàn) 本篇基于 docs/configure tls.m云原生后端微服務(wù)終極Docker Swarm TLS安全配置指南構(gòu)建企業(yè)級安全集群的完整教程 終極Docker Swarm TLS安全配置指南構(gòu)建企業(yè)級安全集群的完整教程 Docker Swarm是Docker官方提供的原生容器編排工具而TLS云原生后端微服務(wù)Docker OpenLDAP 安全最佳實踐TLS配置與證書管理Docker OpenLDAP 安全最佳實踐TLS配置與證書管理 在當(dāng)今企業(yè)級應(yīng)用中Docker OpenLDAP 已成為輕量級目錄服務(wù)的首選解決方案。然而上一篇jina-embedding-s-en-v1在聚類任務(wù)中的應(yīng)用Arxiv論文主題自動分組實踐下一篇Foundation for Emails中的ZURB Stack技術(shù)棧解析創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 Docker Classic Swarm 的 TLS 安全配置：從證書體系到全集群實戰(zhàn)
云原生后端微服務(wù)【免費下載鏈接】classicswarmSwarm Classic: a container clustering system. Not to be confused with Docker Swarm which is at https://github.com/docker/swarmkit項目地址https://gitcode.com/gh_mirrors/cl/classicswarm點擊查看免費下載Docker SwarmClassic Swarm集群中的所有節(jié)點都必須在網(wǎng)絡(luò)上綁定 Docker daemon 端口這帶來顯而易見的安全風(fēng)險——當(dāng)網(wǎng)絡(luò)不可信如公網(wǎng)時風(fēng)險成倍放大。本文以docs/secure-swarm-tls.md與docs/configure-tls.md為主線系統(tǒng)講解 TLS 與 PKI 的基礎(chǔ)概念、三種證書簽發(fā)模式并給出從零搭建「CA 服務(wù)器 swarm manager 雙節(jié)點 遠程客戶端」五機 TLS 環(huán)境的完整九步實操同時結(jié)合本倉庫源碼cli/manage.go、api/server.go、cluster/httpclient.go 等說明 TLS 在 Swarm 內(nèi)部的真實作用路徑。讀完本文你將能夠獨立為 Docker Classic Swarm 集群配置雙向 TLS 認證并理解其底層實現(xiàn)原理。為什么 Swarm 集群需要 TLSDocker Classic Swarm 是一個容器集群系統(tǒng)它把多臺 Docker 主機的計算資源聚合成一個虛擬的、巨大的 Docker Engine。為此集群中的每一臺節(jié)點包括 swarm manager 與 swarm 節(jié)點都必須把 Docker daemon 綁定到網(wǎng)絡(luò)端口上接受來自網(wǎng)絡(luò)的命令。一旦端口暴露到不受信任的網(wǎng)絡(luò)例如互聯(lián)網(wǎng)攻擊者就可能直接向 daemon 發(fā)送惡意命令創(chuàng)建容器、拉取鏡像、讀寫數(shù)據(jù)卷實施中間人攻擊man-in-the-middle篡改客戶端與 daemon 之間的通信內(nèi)容。為了緩解這些風(fēng)險Docker Swarm 與 Docker Engine daemon 支持傳輸層安全協(xié)議Transport Layer SecurityTLS。TLS 是 SSLSecure Sockets Layer的繼任者兩者經(jīng)常被混用Docker 使用的是 TLS本文統(tǒng)一使用 TLS 一詞。生產(chǎn)規(guī)劃文檔 docs/plan-for-production.md 也明確指出所有節(jié)點都必須綁定網(wǎng)絡(luò)端口Swarm 與 Engine 通過 TLS 認證來緩解中間人攻擊等風(fēng)險并給出了 TLS 模式下的默認端口約定組件默認 TLS 端口Engine daemon2376/tcpSwarm manager3376/tcp非 TLS 模式下Engine 與 Swarm 的默認端口分別為2375/tcp與3375/tcp。先理解 TLS 與 PKI 的基本概念在動手配置之前先弄清 TLS 與公鑰基礎(chǔ)設(shè)施Public Key InfrastructurePKI的核心概念。PKI 是一套用于創(chuàng)建和管理數(shù)字證書的安全技術(shù)、策略與流程的組合這些證書與基礎(chǔ)設(shè)施通過認證authentication與加密encryption等機制保護數(shù)字通信。護照類比護照用于驗證一個人的身份包含持有人照片與生物特征信息還列出了簽發(fā)國家以及valid from生效日與valid to失效日日期。數(shù)字證書與此非常相似。下面是從一張數(shù)字證書中摘錄的內(nèi)容Certificate: Data: Version: 3 (0x2) Serial Number: 9590646456311914051 (0x8518d2237ad49e43) Signature Algorithm: sha256WithRSAEncryption Issuer: CUS, STCA, LSanfrancisco, ODocker Inc Validity Not Before: Jan 18 09:42:16 2016 GMT Not After : Jan 15 09:42:16 2026 GMT Subject: CNswarm這張證書標識的是一臺名為swarm的計算機有效期從 2016 年 1 月到 2026 年 1 月由位于美國加州舊金山的 Docker Inc. 簽發(fā)。正如護照在登機、過海關(guān)時認證個人身份數(shù)字證書在網(wǎng)絡(luò)上認證計算機的身份。PKI 則是在幕后支撐數(shù)字證書的技術(shù)、策略與流程組合主要包括安全地請求證書的服務(wù)認證證書請求實體身份的程序判斷實體是否有資格獲得證書的程序簽發(fā)證書的技術(shù)與流程吊銷證書的技術(shù)與流程。Docker Engine 如何利用 TLS 進行認證你可以同時配置 Docker Engine CLI 與 Docker Engine daemon 要求使用 TLS 進行認證。配置 TLS 意味著CLI 與 daemon 之間的所有通信都必須附帶并經(jīng)由受信任的數(shù)字證書簽名。Docker Engine CLI 必須先出示自己的數(shù)字證書daemon 才會接受它發(fā)來的命令。與此同時daemon 也必須信任 CLI 所使用的證書。這種信任通常經(jīng)由可信第三方建立——即圖中的 Certificate AuthorityCA證書頒發(fā)機構(gòu)服務(wù)器。圖中的可信第三方就是 CA 服務(wù)器。如同護照示例中的國家CA 負責(zé)創(chuàng)建、簽名、簽發(fā)和吊銷證書。信任的建立方式是在運行 Docker Engine daemon 的主機上安裝 CA 的根證書然后 Docker Engine CLI 向 CA 服務(wù)器請求自己的證書由 CA 簽名后簽發(fā)給它。工作流程如下Docker Engine CLI 在發(fā)出命令前先把證書發(fā)送給 Docker Engine daemondaemon 檢查證書——由于 daemon 信任該 CA它會自動信任任何由該 CA 簽名的證書假設(shè)證書有效未過期、未被吊銷等daemon 就接受來自這個可信 CLI 的命令。需要強調(diào)Docker Engine CLI 本質(zhì)上只是使用 Docker Engine API 與 daemon 通信的一個客戶端。任何使用 Docker Engine API 的客戶端都可以使用 TLS。例如 Docker Universal Control PlaneUCP內(nèi)置了 TLS 支持其他基于 Docker Engine API 的第三方產(chǎn)品也可以這樣配置。Docker 與 Swarm 的三種 TLS 配置模式根據(jù)承擔(dān) CA 角色的實體類型不同Docker Engine daemon 及其客戶端存在三種可能的 TLS 配置外部第三方 CAExternal 3rd party CA內(nèi)部企業(yè) CAInternal corporate CA自簽名證書Self-signed certificates外部第三方 CA外部 CA 是受信任的第三方公司提供創(chuàng)建、簽發(fā)、吊銷和管理證書的服務(wù)。說它們「受信任」是因為它們必須滿足特定條件、保持高水準的安全與商業(yè)實踐才能贏得你的業(yè)務(wù)同時你也需要安裝外部 CA 的根證書才能讓計算機和服務(wù)信任它們。使用外部第三方 CA 時證書的創(chuàng)建、簽名、簽發(fā)、吊銷與管理全部由它負責(zé)。這類服務(wù)通常收費但被公認為企業(yè)級、可擴展的解決方案能提供較高程度的信任。內(nèi)部企業(yè) CA許多組織選擇搭建自己的 CA 與 PKI常見實現(xiàn)包括 OpenSSL 和 Microsoft Active Directory。這種情況下你的公司自己就是 CA需要承擔(dān) CA 的全部工作。好處是作為自己的 CA你對 PKI 擁有更強的控制力。自建 CA 與 PKI 需要你自行提供外部第三方 CA 提供的全部服務(wù)包括創(chuàng)建、簽發(fā)、吊銷和管理證書。自己做這些事有相應(yīng)的成本與開銷但對大型企業(yè)而言與使用外部第三方服務(wù)相比仍可能降低成本。假設(shè)你的內(nèi)部 CA 與 PKI 運營管理得當(dāng)內(nèi)部企業(yè) CA 可以是一種高度可擴展、高度安全的選擇。自簽名證書顧名思義自簽名證書是用自己的私鑰簽名的證書而不是由受信任的 CA 簽名。這是低成本、易用的選擇。如果正確實現(xiàn)和管理自簽名證書它們比完全沒有證書要好。但由于自簽名證書缺少完整的 PKI擴展性差也缺少其他兩種方案提供的許多優(yōu)勢。一個明顯的缺點是自簽名證書無法吊銷。由于這一點及其他限制自簽名證書被認為是三種方案中最不安全的不建議在暴露于不受信任網(wǎng)絡(luò)的公網(wǎng)生產(chǎn)負載中使用。實戰(zhàn)為 Docker Swarm 集群配置 TLS九步全流程下面的流程將創(chuàng)建一個兩節(jié)點的 swarm 集群外加一個 Docker Engine CLI、一個 swarm manager 和一個 CA 服務(wù)器如圖所示。所有 Docker Engine 主機client、swarm、node1、node2都擁有 CA 證書副本以及由 CA 簽發(fā)的各自密鑰對。流程包含以下步驟Step 1: 準備前置條件Step 2: 創(chuàng)建 CA 服務(wù)器Step 3: 創(chuàng)建并簽發(fā)密鑰Step 4: 安裝密鑰Step 5: 為 Engine daemon 配置 TLSStep 6: 創(chuàng)建 swarm 集群Step 7: 使用 TLS 啟動 swarm managerStep 8: 測試 swarm manager 配置Step 9: 配置 Engine CLI 使用 TLS開始之前的重要提示下文包含使用 OpenSSL 自建 CA 的步驟這與運營內(nèi)部企業(yè) CA 和 PKI 類似。但絕不能把這里的步驟當(dāng)作搭建生產(chǎn)級內(nèi)部 CA 與 PKI 的指南。這些步驟僅用于演示目的——讓沒有現(xiàn)成 CA 和證書的讀者也能跟著操作完成 Swarm 的 TLS 配置。Step 1: 準備前置條件完成本流程需要準備 5 臺 Linux 服務(wù)器可以是物理機與虛擬機的任意組合可位于本地或公有云。各服務(wù)器的名稱與用途如下服務(wù)器名說明ca充當(dāng) Certificate AuthorityCA服務(wù)器swarm充當(dāng) swarm managernode1充當(dāng) swarm 節(jié)點node2充當(dāng) swarm 節(jié)點client充當(dāng)遠程 Docker Engine 客戶端確保你能通過 SSH 訪問全部 5 臺服務(wù)器且它們能通過 DNS 名稱解析相互通信。特別要注意在 swarm manager 與 swarm 節(jié)點之間開放 TCP 端口2376在 Docker Engine client 與 swarm manager 之間開放 TCP 端口3376。如果這些端口已被占用可以選擇其他端口但本示例假設(shè)使用這些端口。每臺服務(wù)器必須運行與 Docker Engine 兼容的操作系統(tǒng)為簡便起見后續(xù)步驟假設(shè)所有服務(wù)器都運行 Ubuntu 14.04 LTS。Step 2: 創(chuàng)建 CA 服務(wù)器注意如果你已經(jīng)擁有 CA 和證書且熟悉其使用可以跳過本步直接進入下一步。本步把一臺 Linux 服務(wù)器配置為 CA用它來創(chuàng)建和簽發(fā)密鑰。再次強調(diào)這只是為了讓沒有現(xiàn)成 CA 的讀者可以跟隨完成后續(xù)步驟不是生產(chǎn)級 CA 的部署范本。登錄 CA 服務(wù)器的終端并提升為 root$ sudo su為 CA 創(chuàng)建私鑰ca-priv-key.pem# openssl genrsa -out ca-priv-key.pem 2048 Generating RSA private key, 2048 bit long modulus ........................................................... ..... e is 65537 (0x10001)為 CA 創(chuàng)建公鑰ca.pem。公鑰基于上一步創(chuàng)建的私鑰# openssl req -config /usr/lib/ssl/openssl.cnf -new -key ca-priv-key.pem -x509 -days 1825 -out ca.pem You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter ., the field will be left blank. ----- Country Name (2 letter code) [AU]:US output truncated這里的-days 1825意味著 CA 證書有效期約為 5 年1825 天。至此你已配置好一個擁有公私鑰對的 CA 服務(wù)器?？梢詸z查每個密鑰的內(nèi)容用openssl rsa -in ca-priv-key.pem -noout -text檢查私鑰用openssl x509 -in ca.pem -noout -text檢查公鑰證書。下面是 CA 公鑰的部分內(nèi)容# openssl x509 -in ca.pem -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: 17432010264024107661 (0xf1eaf0f9f41eca8d) Signature Algorithm: sha256WithRSAEncryption Issuer: CUS, STCA, LSanfrancisco, ODocker Inc Validity Not Before: Jan 16 18:28:12 2016 GMT Not After : Jan 13 18:28:12 2026 GMT Subject: CUS, STCA, LSan Francisco, ODocker Inc Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:d1:fe:6e:55:d4:93:fc:c9:8a:04:07:2d:ba:f0: 55:97:c5:2c:f5:d7:1d:6a:9b:f0:f0:55:6c:5d:90: output truncated稍后你將用這張證書為基礎(chǔ)設(shè)施中的其他服務(wù)器簽發(fā)密鑰。Step 3: 創(chuàng)建并簽發(fā)密鑰現(xiàn)在 CA 已就緒你需要為 swarm manager、swarm 節(jié)點和遠程 Docker Engine client 創(chuàng)建密鑰對。所有服務(wù)器的密鑰對創(chuàng)建命令與流程完全相同。涉及的關(guān)鍵文件如下文件說明ca-priv-key.pemCA 的私鑰必須妥善保管。稍后用它為環(huán)境中其他節(jié)點簽發(fā)新密鑰。與ca.pem一起構(gòu)成 CA 的密鑰對。ca.pemCA 的公鑰即證書。安裝到環(huán)境中所有節(jié)點上使所有節(jié)點信任由該 CA 簽名的證書。與ca-priv-key.pem一起構(gòu)成 CA 的密鑰對。NODE_NAME.csr證書簽名請求CSR。CSR 本質(zhì)上是向 CA 申請為某個節(jié)點創(chuàng)建新密鑰對的申請單。CA 根據(jù) CSR 提供的信息生成該節(jié)點的公私鑰對。NODE_NAME-priv-key.pem由 CA 簽名的私鑰。節(jié)點用它向遠程 Docker Engine 認證自己的身份。與NODE_NAME-cert.pem一起構(gòu)成節(jié)點的密鑰對。NODE_NAME-cert.pem由 CA 簽名的證書。與NODE_NAME-priv-key.pem一起構(gòu)成節(jié)點的密鑰對。下面的命令演示如何為所有節(jié)點創(chuàng)建密鑰請在 CA 服務(wù)器上的一個工作目錄中執(zhí)行。登錄 CA 服務(wù)器終端并提升為 root$ sudo su為 swarm manager 創(chuàng)建私鑰swarm-priv-key.pem# openssl genrsa -out swarm-priv-key.pem 2048 Generating RSA private key, 2048 bit long modulus ............................................................ ........ e is 65537 (0x10001)用上一步創(chuàng)建的私鑰生成證書簽名請求CSRswarm.csr# openssl req -subj /CNswarm -new -key swarm-priv-key.pem -out swarm.csr注意這僅用于演示目的。真實生產(chǎn)環(huán)境中創(chuàng)建 CSR 的流程略有不同。這里-subj /CNswarm直接指定了證書的主體名Common Name為swarm即前面證書示例中Subject: CNswarm所對應(yīng)的身份?；谏弦徊絼?chuàng)建的 CSR 生成證書swarm-cert.pem# openssl x509 -req -days 1825 -in swarm.csr -CA ca.pem -CAkey ca-priv-key.pem -CAcreateserial -out swarm-cert.pem -extensions v3_req -extfile /usr/lib/ssl/openssl.cnf snip # openssl rsa -in swarm-priv-key.pem -out swarm-priv-key.pem至此你擁有了 swarm manager 的密鑰對。對其余節(jié)點node1、node2、client重復(fù)上述步驟。注意把swarm相關(guān)的取值替換為正在創(chuàng)建密鑰對的節(jié)點對應(yīng)的值服務(wù)器名私鑰CSR證書node1node1-priv-key.pemnode1.csrnode1-cert.pemnode2node2-priv-key.pemnode2.csrnode2-cert.pemclientclient-priv-key.pemclient.csrclient-cert.pem驗證工作目錄包含以下文件# ls -l total 64 -rw-r--r-- 1 root root 1679 Jan 16 18:27 ca-priv-key.pem -rw-r--r-- 1 root root 1229 Jan 16 18:28 ca.pem -rw-r--r-- 1 root root 17 Jan 18 09:56 ca.srl -rw-r--r-- 1 root root 1086 Jan 18 09:56 client-cert.pem -rw-r--r-- 1 root root 887 Jan 18 09:55 client.csr -rw-r--r-- 1 root root 1679 Jan 18 09:56 client-priv-key.pem -rw-r--r-- 1 root root 1082 Jan 18 09:44 node1-cert.pem -rw-r--r-- 1 root root 887 Jan 18 09:43 node1.csr -rw-r--r-- 1 root root 1675 Jan 18 09:44 node1-priv-key.pem -rw-r--r-- 1 root root 1082 Jan 18 09:49 node2-cert.pem -rw-r--r-- 1 root root 887 Jan 18 09:49 node2.csr -rw-r--r-- 1 root root 1675 Jan 18 09:49 node2-priv-key.pem -rw-r--r-- 1 root root 1082 Jan 18 09:42 swarm-cert.pem -rw-r--r-- 1 root root 887 Jan 18 09:41 swarm.csr -rw-r--r-- 1 root root 1679 Jan 18 09:42 swarm-priv-key.pemca.srl是 CA 自動生成的序列號文件由-CAcreateserial參數(shù)產(chǎn)生CA 用它記錄已簽發(fā)證書的序列號。你可以用openssl rsa -in key-name -noout -text檢查私鑰用openssl x509 -in key-name -noout -text檢查公鑰。下面是 swarm manager 公鑰swarm-cert.pem的部分內(nèi)容# openssl x509 -in ca.pem -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: 9590646456311914051 (0x8518d2237ad49e43) Signature Algorithm: sha256WithRSAEncryption Issuer: CUS, STCA, LSanfrancisco, ODocker Inc Validity Not Before: Jan 18 09:42:16 2016 GMT Not After : Jan 15 09:42:16 2026 GMT Subject: CNswarm output truncated可以看到Subject: CNswarm對應(yīng)前面openssl req -subj /CNswarm設(shè)定的主體名。Step 4: 安裝密鑰本步把密鑰安裝到基礎(chǔ)設(shè)施中對應(yīng)的服務(wù)器上。每臺服務(wù)器需要三個文件CA 公鑰的副本ca.pem自己的私鑰自己的公鑰證書下面的步驟演示如何用scp把這些文件從 CA 服務(wù)器復(fù)制到各服務(wù)器。復(fù)制時按如下規(guī)則重命名文件原文件名復(fù)制后文件名ca.pemca.pemserver-cert.pemcert.pemserver-priv-key.pemkey.pem登錄 CA 服務(wù)器終端并提升為 root$ sudo su在 swarm manager 上創(chuàng)建~/.certs目錄。這里假設(shè)用戶賬戶是 ubuntu$ ssh ubuntuswarm mkdir -p /home/ubuntu/.certs把密鑰從 CA 復(fù)制到 swarm manager 服務(wù)器$ scp ./ca.pem ubuntuswarm:/home/ubuntu/.certs/ca.pem $ scp ./swarm-cert.pem ubuntuswarm:/home/ubuntu/.certs/cert.pem $ scp ./swarm-priv-key.pem ubuntuswarm:/home/ubuntu/.certs/key.pem注意scp命令可能需要提供認證。例如 AWS EC2 實例使用基于證書的認證。要把文件復(fù)制到與公鑰nigel.pem關(guān)聯(lián)的 EC2 實例scp命令需修改為scp -i /path/to/nigel.pem ./ca.pem ubuntuswarm:/home/ubuntu/.certs/ca.pem。對其余每臺服務(wù)器重復(fù)步驟 2 與 3node1node2client驗證你的工作。復(fù)制完成后每臺機器都應(yīng)擁有以下密鑰基礎(chǔ)設(shè)施中的每個節(jié)點都應(yīng)在/home/ubuntu/.certs/目錄下?lián)碛幸韵挛募? ls -l /home/ubuntu/.certs/ total 16 -rw-r--r-- 1 ubuntu ubuntu 1229 Jan 18 10:03 ca.pem -rw-r--r-- 1 ubuntu ubuntu 1082 Jan 18 10:06 cert.pem -rw-r--r-- 1 ubuntu ubuntu 1679 Jan 18 10:06 key.pemStep 5: 為 Engine daemon 配置 TLS上一步你已在每個 swarm 節(jié)點上創(chuàng)建并安裝了必要密鑰。本步把它們配置為監(jiān)聽網(wǎng)絡(luò)且只接受 TLS 連接。完成后swarm 節(jié)點將監(jiān)聽 TCP 端口2376并且只接受使用 TLS 的連接。在node1和node2你的 swarm 節(jié)點上執(zhí)行以下操作打開node1的終端并提升為 root$ sudo su向/etc/docker/daemon.json添加以下配置鍵。如果文件不存在則創(chuàng)建它{ hosts: [tcp://0.0.0.0:2376], tlsverify: true, tlscacert: /home/ubuntu/.certs/ca.pem, tlscert: /home/ubuntu/.certs/cert.pem, tlskey: /home/ubuntu/.certs/key.pem }重啟 Docker 使配置生效。如果文件不是合法 JSONDocker 將啟動失敗并輸出錯誤。各配置鍵含義如下配置鍵含義hostsdaemon 監(jiān)聽的地址與端口tcp://0.0.0.0:2376表示在所有網(wǎng)卡上以 TLS 端口 2376 提供服務(wù)tlsverify置為true啟用 TLS 并強制驗證客戶端證書雙向認證tlscacertCA 根證書路徑daemon 用它驗證客戶端證書鏈tlscertdaemon 自己的證書路徑tlskeydaemon 自己的私鑰路徑在node2上重復(fù)上述過程。從這里可以看出 TLS 的「雙向」特征daemon 不僅要向客戶端證明自己出示cert.pem/key.pem還要通過tlsverify與ca.pem反過來校驗客戶端身份。這正是 cli/manage.go 中l(wèi)oadTLSConfig所體現(xiàn)的行為——verify為真時加載 CA 證書池并設(shè)置ClientAuth tls.RequireAndVerifyClientCert強制要求客戶端提供由該 CA 簽發(fā)的證書。Step 6: 創(chuàng)建 swarm 集群接下來創(chuàng)建 swarm 集群。本流程使用默認的hosted discovery托管發(fā)現(xiàn)后端創(chuàng)建一個兩節(jié)點 swarm 集群。默認的 hosted discovery 后端使用 Docker Hub不建議用于生產(chǎn)環(huán)境。登錄 swarm manager 節(jié)點的終端。創(chuàng)建集群并把它的唯一 ID 導(dǎo)出到TOKEN環(huán)境變量$ sudo export TOKEN$(docker run --rm swarm create) Unable to find image swarm:latest locally latest: Pulling from library/swarm d681c900c6e3: Pulling fs layer snip 986340ab62f0: Pull complete a9975e2cc0a3: Pull complete Digest: sha256:c21fd414b0488637b1f05f13a59b032a3f9da5d818d31da1a4ca98a84c0c781b Status: Downloaded newer image for swarm:latestswarm create子命令會生成一個集群 token所有節(jié)點通過token://$TOKEN接入同一個集群。把node1加入集群。務(wù)必指定 TCP 端口2376而不是2375$ sudo docker run -d swarm join --addrnode1:2376 token://$TOKEN 7bacc98536ed6b4200825ff6f4004940eb2cec891e1df71c6bbf20157c5f9761把node2加入集群$ sudo docker run -d swarm join --addrnode2:2376 token://$TOKEN db3f49d397bad957202e91f0679ff84f526e74d6c5bf1b6734d834f5edcbca6cStep 7: 使用 TLS 啟動 swarm manager啟動一個啟用 TLS 的新容器$ docker run -d -p 3376:3376 -v /home/ubuntu/.certs:/certs:ro swarm manage --tlsverify --tlscacert/certs/ca.pem --tlscert/certs/cert.pem --tlskey/certs/key.pem --host0.0.0.0:3376 token://$TOKEN這條命令基于swarm鏡像啟動一個新容器并把服務(wù)器上的端口3376映射到容器內(nèi)的端口3376。這個映射確保發(fā)送到主機端口3376的 Docker Engine 命令會被轉(zhuǎn)發(fā)到容器內(nèi)的端口3376。容器以--tlsverify、--tlscacert、--tlscert和--tlskey選項運行swarm manage進程——這些選項強制進行 TLS 驗證并指定 swarm manager TLS 密鑰的位置。證書目錄/home/ubuntu/.certs以只讀方式掛載為容器內(nèi)/certs/certs/*.pem路徑即對應(yīng)上述三個--tls*參數(shù)。運行docker ps驗證 swarm manager 容器已啟動并運行$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 035dbf57b26e swarm /swarm manage --tlsv 7 seconds ago Up 7 seconds 2375/tcp, 0.0.0.0:3376-3376/tcp compassionate_lovelace源碼印證manage命令在 cli/manage.go 中先檢查--tls/--tlsverify標志若指定了它們而未提供--tlscert/--tlskey則直接報錯退出指定--tlsverify而未提供--tlscacert同樣報錯反之若只提供了--tlscert/--tlskey/--tlscacert而沒開--tls/--tlsverify也會被拒絕因為這些參數(shù)將被忽略。隨后 loadTLSConfig 會調(diào)用tls.LoadX509KeyPair加載證書私鑰并把 TLS 最低版本設(shè)為 TLS 1.2MinVersion: tls.VersionTLS12。校驗啟用時還會把 CA 證書讀入證書池同時設(shè)置ClientAuth tls.RequireAndVerifyClientCert與ClientCAs實現(xiàn)雙向認證。生成的tlsConfig最終被傳給 api.NewServer見 cli/manage.go與 swarm.NewCluster。api.Server在 newListener 中檢測到tlsConfig ! nil時會設(shè)置NextProtos []string{http/1.1}并用tls.NewListener包裝監(jiān)聽器——也就是說Swarm 對外暴露的 HTTPS 端口正是由這份 TLS 配置支撐的。你的 swarm 集群現(xiàn)在已配置為使用 TLS。Step 8: 測試 swarm manager 配置集群已構(gòu)建并配置 TLS現(xiàn)在用 Docker Engine CLI 驗證它是否工作。打開client服務(wù)器的終端。執(zhí)行docker version命令。執(zhí)行時必須傳入客戶端證書的位置$ sudo docker --tlsverify --tlscacert/home/ubuntu/.certs/ca.pem --tlscert/home/ubuntu/.certs/cert.pem --tlskey/home/ubuntu/.certs/key.pem -H swarm:3376 version Client: Version: 1.9.1 API version: 1.21 Go version: go1.4.2 Git commit: a34a1d5 Built: Fri Nov 20 13:12:04 UTC 2015 OS/Arch: linux/amd64 Server: Version: swarm/1.0.1 API version: 1.21 Go version: go1.5.2 Git commit: 744e3a3 Built: OS/Arch: linux/amd64輸出中Server的版本顯示為 swarm/1.0.1說明命令已成功發(fā)往 swarm manager。驗證同一命令在不帶 TLS 時無法工作。這次不向 swarm manager 傳證書$ sudo docker -H swarm:3376 version : Version: 1.9.1 API version: 1.21 Go version: go1.4.2 Git commit: a34a1d5 Built: Fri Nov 20 13:12:04 UTC 2015 OS/Arch: linux/amd64 Get http://swarm:3376/v1.21/version: malformed HTTP response \x15\x03\x01\x00\x02\x02. * Are you trying to connect to a TLS-enabled daemon without TLS?輸出顯示命令被服務(wù)器拒絕。這是因為服務(wù)器swarm manager配置為只接受使用 TLS 的已認證客戶端的連接。malformed HTTP response正是 TLS 握手失敗的典型特征客戶端用明文 HTTP 請求打到了一個只講 TLS 的端口上。源碼印證manager 通過 api.Server 對外服務(wù)而 swarm manager 把來自客戶端的請求轉(zhuǎn)發(fā)給后端節(jié)點時同樣使用 TLS。在 cluster/engine.go 的Connect中NewHTTPClientTimeout(tcp://e.Addr, config, ...)會在配置了 TLS 時把 URL scheme 從http自動切換為https見 cluster/httpclient.go并把tlsConfig裝進http.Transport此后 api/utils.go 的proxyAsync通過engine.HTTPClientAndScheme()取回這個帶 TLS 的客戶端完成對節(jié)點的反向代理。也就是說無論manage是代理普通 API 調(diào)用如proxyContainer還是代理attach類長連接hijack見 api/handlers.go 中hijack(c.tlsConfig, ...)的調(diào)用TLS 配置都會貫穿 client → manager → node 的完整鏈路。Step 9: 配置 Engine CLI 使用 TLS你可以配置 Engine使每次執(zhí)行命令時無需再傳 TLS 參數(shù)。方法是在 Docker Engine 客戶端上把Docker Engine host與TLS設(shè)置配置為默認值。具體做法把客戶端的密鑰放入~/.docker配置目錄。如果系統(tǒng)上有其他用戶使用 Engine 命令行也要配置他們的~/.docker。下面以 Docker Engine 客戶端上的ubuntu用戶為例。打開client服務(wù)器的終端。如果不存在在ubuntu用戶主目錄創(chuàng)建.docker目錄$ mkdir /home/ubuntu/.docker把 Docker Engine 客戶端的密鑰從/home/ubuntu/.certs復(fù)制到/home/ubuntu/.docker$ cp /home/ubuntu/.certs/{ca,cert,key}.pem /home/ubuntu/.docker編輯該賬戶的~/.bash_profile。設(shè)置以下變量變量說明DOCKER_HOST設(shè)置所有 Engine 命令要發(fā)送到的 Docker 主機與 TCP 端口。DOCKER_TLS_VERIFY告訴 Engine 使用 TLS。DOCKER_CERT_PATH指定 TLS 密鑰的位置。例如export DOCKER_HOSTtcp://swarm:3376 export DOCKER_TLS_VERIFY1 export DOCKER_CERT_PATH/home/ubuntu/.docker/保存并關(guān)閉文件。用source加載文件以拾取新變量$ source ~/.bash_profile執(zhí)行docker version驗證配置生效$ docker version Client: Version: 1.9.1 API version: 1.21 Go version: go1.4.2 Git commit: a34a1d5 Built: Fri Nov 20 13:12:04 UTC 2015 OS/Arch: linux/amd64 Server: Version: swarm/1.0.1 API version: 1.21 Go version: go1.5.2 Git commit: 744e3a3 Built: OS/Arch: linux/amd64輸出中的服務(wù)器部分說明你的 Docker 客戶端正在向 swarm manager 發(fā)送命令并使用 TLS。至此你已經(jīng)成功配置了一個使用 TLS 的 Docker swarm 集群。深入理解TLS 配置在 Swarm 源碼中的完整路徑結(jié)合前文九步實操從源碼結(jié)構(gòu)可以梳理出 TLS 在 Docker Classic Swarm 中的完整作用鏈路參數(shù)解析與校驗swarm manage的 TLS 相關(guān)命令行參數(shù)在 cli/flags.go 中定義為--tls、--tlscacert、--tlscert、--tlskey、--tlsverify五個 flag。其中--tls的用法說明是「use TLS; implied by --tlsverifytrue」--tlscacert被描述為「僅信任由此處給定 CA 簽名的證書的遠端」。TLS 配置對象構(gòu)建manage函數(shù)在 cli/manage.go 完成上述校驗后調(diào)用loadTLSConfigcli/manage.go構(gòu)建*tls.Config加載cert/key密鑰對設(shè)置最低 TLS 版本為 TLS 1.2--tlsverify開啟時加載 CA 證書池并要求客戶端證書RequireAndVerifyClientCert未開啟校驗時則InsecureSkipVerify true。對外服務(wù)端manager 自身tlsConfig傳入 api.NewServerListenAndServe在 newListener 中用tls.NewListener包裝 TCP 監(jiān)聽器使 manager 對外只接受 TLS 連接如0.0.0.0:3376。對內(nèi)連接端manager → 節(jié)點同一份tlsConfig傳入 swarm.NewCluster存入Cluster.TLSConfig節(jié)點經(jīng)發(fā)現(xiàn)服務(wù)注冊后validatePendingEngine調(diào)用engine.Connect(c.TLSConfig)cluster/swarm/cluster.go。Connect中NewHTTPClientTimeout會根據(jù)tlsConfig是否存在把節(jié)點 URL 切換為httpscluster/httpclient.go隨后的所有 API 代理api/utils.go與 attach/hijack 長連接api/handlers.go、api/utils.go都復(fù)用這份 TLS 配置。由此可見一份tlsConfig同時支撐了「客戶端 → swarm manager」與「swarm manager → 節(jié)點 daemon」兩段加密鏈路這也是文檔要求同時在 manager 與節(jié)點上安裝ca.pem、cert.pem、key.pem三件套的根本原因。相關(guān)文檔Secure Docker Swarm with TLS本文理論基礎(chǔ)篇Configure Docker Swarm for TLS九步實操完整版Plan for Swarm in production生產(chǎn)環(huán)境端口規(guī)劃與網(wǎng)絡(luò)訪問控制贊分享云原生后端微服務(wù)【免費下載鏈接】classicswarmSwarm Classic: a container clustering system. Not to be confused with Docker Swarm which is at https://github.com/docker/swarmkit項目地址https://gitcode.com/gh_mirrors/cl/classicswarm點擊查看免費下載相關(guān)推薦Docker Classic Swarm 配置 TLS基于 OpenSSL 自建 CA 的集群安全加固實戰(zhàn)Docker Classic Swarm 配置 TLS基于 OpenSSL 自建 CA 的集群安全加固實戰(zhàn) 本篇基于 docs/configure tls.m云原生后端微服務(wù)終極Docker Swarm TLS安全配置指南構(gòu)建企業(yè)級安全集群的完整教程 終極Docker Swarm TLS安全配置指南構(gòu)建企業(yè)級安全集群的完整教程 Docker Swarm是Docker官方提供的原生容器編排工具而TLS云原生后端微服務(wù)Docker OpenLDAP 安全最佳實踐TLS配置與證書管理Docker OpenLDAP 安全最佳實踐TLS配置與證書管理 在當(dāng)今企業(yè)級應(yīng)用中Docker OpenLDAP 已成為輕量級目錄服務(wù)的首選解決方案。然而上一篇jina-embedding-s-en-v1在聚類任務(wù)中的應(yīng)用Arxiv論文主題自動分組實踐下一篇Foundation for Emails中的ZURB Stack技術(shù)棧解析創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考